[ { "hash": "dfa34a79638600346b06aab7d157db855d22a1ba", "msg": "fixed catalog test so that it would work if mutliple people were testing at same time or if /tmp/test_catalog could not be written.", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-04T00:45:20+00:00", "author_timezone": 0, "committer_date": "2002-01-04T00:45:20+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "b4f5c98a78a4ed3ac50bae14c7d06c90b7a88a99" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 1, "insertions": 1, "lines": 2, "files": 1, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": "weave/tests/test_catalog.py", "new_path": "weave/tests/test_catalog.py", "filename": "test_catalog.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -80,7 +80,7 @@ def get_test_dir(self,erase = 0):\n # make sure tempdir catalog doesn't exist\n import tempfile\n temp = tempfile.gettempdir()\n- pardir = os.path.join(temp,'catalog_test')\n+ pardir = os.path.join(temp,'catalog_test'+tempfile.gettempprefix())\n if not os.path.exists(pardir):\n os.mkdir(pardir)\n catalog_file = os.path.join(pardir,os_dependent_catalog_name()+'.dat')\n", "added_lines": 1, "deleted_lines": 1, "source_code": "import unittest\nimport sys, os\n\n\nfrom scipy_distutils.misc_util import add_grandparent_to_path, restore_path\nfrom scipy_distutils.misc_util import add_local_to_path\n\nadd_grandparent_to_path(__name__)\nfrom catalog import *\n# not sure why, but was having problems with which catalog was being called.\nimport catalog\n#catalog = catalog.catalog\nrestore_path()\n\nadd_local_to_path(__name__)\nfrom weave_test_utils import *\nrestore_path()\n\n\nclass test_default_dir(unittest.TestCase):\n def check_is_writable(self):\n path = default_dir()\n name = os.path.join(path,'dummy_catalog')\n test_file = open(name,'w')\n try:\n test_file.write('making sure default location is writable\\n')\n finally:\n test_file.close()\n os.remove(name)\n\nclass test_os_dependent_catalog_name(unittest.TestCase): \n pass\n \nclass test_catalog_path(unittest.TestCase): \n def check_default(self):\n in_path = default_dir()\n path = catalog_path(in_path)\n d,f = os.path.split(path)\n assert(d == in_path)\n assert(f == os_dependent_catalog_name())\n def check_current(self):\n in_path = '.'\n path = catalog_path(in_path)\n d,f = os.path.split(path)\n assert(d == os.path.abspath(in_path)) \n assert(f == os_dependent_catalog_name()) \n def check_user(path):\n if sys.platform != 'win32':\n in_path = '~'\n path = catalog_path(in_path)\n d,f = os.path.split(path)\n assert(d == os.path.expanduser(in_path)) \n assert(f == os_dependent_catalog_name())\n def check_module(self):\n # hand it a module and see if it uses the parent directory\n # of the module.\n path = catalog_path(os.__file__)\n d,f = os.path.split(os.__file__)\n d2,f = os.path.split(path)\n assert (d2 == d)\n def check_path(self):\n # use os.__file__ to get a usable directory.\n in_path,f = os.path.split(os.__file__)\n path = catalog_path(in_path)\n d,f = os.path.split(path)\n assert (d == in_path)\n def check_bad_path(self):\n # stupid_path_name\n in_path = 'stupid_path_name'\n path = catalog_path(in_path)\n assert (path is None)\n\nclass test_get_catalog(unittest.TestCase):\n \"\"\" This only tests whether new catalogs are created correctly.\n And whether non-existent return None correctly with read mode.\n Putting catalogs in the right place is all tested with\n catalog_dir tests.\n \"\"\"\n def get_test_dir(self,erase = 0):\n # make sure tempdir catalog doesn't exist\n import tempfile\n temp = tempfile.gettempdir()\n pardir = os.path.join(temp,'catalog_test'+tempfile.gettempprefix())\n if not os.path.exists(pardir):\n os.mkdir(pardir)\n catalog_file = os.path.join(pardir,os_dependent_catalog_name()+'.dat')\n if os.path.exists(catalog_file) and erase:\n os.remove(catalog_file)\n catalog_file = os.path.join(pardir,os_dependent_catalog_name()+'.dir')\n if os.path.exists(catalog_file) and erase:\n os.remove(catalog_file)\n catalog_file = os.path.join(pardir,os_dependent_catalog_name())\n if os.path.exists(catalog_file) and erase:\n os.remove(catalog_file)\n return pardir\n def check_nonexistent_catalog_is_none(self):\n pardir = self.get_test_dir(erase=1)\n catalog = get_catalog(pardir)\n assert(catalog is None)\n def check_create_catalog(self):\n pardir = self.get_test_dir(erase=1)\n catalog = get_catalog(pardir,'cr')\n assert(catalog is not None)\n\nclass test_catalog(unittest.TestCase):\n\n def clear_environ(self):\n if os.environ.has_key('PYTHONCOMPILED'):\n self.old_PYTHONCOMPILED = os.environ['PYTHONCOMPILED']\n del os.environ['PYTHONCOMPILED']\n else: \n self.old_PYTHONCOMPILED = None\n def reset_environ(self):\n if self.old_PYTHONCOMPILED:\n os.environ['PYTHONCOMPILED'] = self.old_PYTHONCOMPILED\n self.old_PYTHONCOMPILED = None\n def setUp(self):\n self.clear_environ() \n def tearDown(self):\n self.reset_environ()\n \n def check_set_module_directory(self):\n q = catalog.catalog()\n q.set_module_directory('bob')\n r = q.get_module_directory()\n assert (r == 'bob')\n def check_clear_module_directory(self):\n q = catalog.catalog()\n r = q.get_module_directory()\n assert (r == None)\n q.set_module_directory('bob')\n r = q.clear_module_directory()\n assert (r == None)\n def check_get_environ_path(self):\n if sys.platform == 'win32': sep = ';'\n else: sep = ':'\n os.environ['PYTHONCOMPILED'] = sep.join(('path1','path2','path3'))\n q = catalog.catalog()\n path = q.get_environ_path() \n assert(path == ['path1','path2','path3'])\n def check_build_search_order1(self): \n \"\"\" MODULE in search path should be replaced by module_dir.\n \"\"\" \n q = catalog.catalog(['first','MODULE','third'])\n q.set_module_directory('second')\n order = q.build_search_order()\n assert(order == ['first','second','third',default_dir()])\n def check_build_search_order2(self): \n \"\"\" MODULE in search path should be removed if module_dir==None.\n \"\"\" \n q = catalog.catalog(['first','MODULE','third'])\n order = q.build_search_order()\n assert(order == ['first','third',default_dir()]) \n def check_build_search_order3(self):\n \"\"\" If MODULE is absent, module_dir shouldn't be in search path.\n \"\"\" \n q = catalog.catalog(['first','second'])\n q.set_module_directory('third')\n order = q.build_search_order()\n assert(order == ['first','second',default_dir()])\n def check_build_search_order4(self):\n \"\"\" Make sure environment variable is getting used.\n \"\"\" \n q = catalog.catalog(['first','second'])\n if sys.platform == 'win32': sep = ';'\n else: sep = ':'\n os.environ['PYTHONCOMPILED'] = sep.join(('MODULE','fourth','fifth'))\n q.set_module_directory('third')\n order = q.build_search_order()\n assert(order == ['first','second','third','fourth','fifth',default_dir()])\n \n def check_catalog_files1(self):\n \"\"\" Be sure we get at least one file even without specifying the path.\n \"\"\"\n q = catalog.catalog()\n files = q.get_catalog_files()\n assert(len(files) == 1)\n\n def check_catalog_files2(self):\n \"\"\" Ignore bad paths in the path.\n \"\"\"\n q = catalog.catalog()\n os.environ['PYTHONCOMPILED'] = '_some_bad_path_'\n files = q.get_catalog_files()\n assert(len(files) == 1)\n \n def check_get_existing_files1(self):\n \"\"\" Shouldn't get any files when temp doesn't exist and no path set. \n \"\"\" \n clear_temp_catalog()\n q = catalog.catalog()\n files = q.get_existing_files()\n restore_temp_catalog()\n assert(len(files) == 0)\n def check_get_existing_files2(self):\n \"\"\" Shouldn't get a single file from the temp dir.\n \"\"\" \n clear_temp_catalog()\n q = catalog.catalog()\n # create a dummy file\n import os \n q.add_function('code', os.getpid)\n del q\n q = catalog.catalog()\n files = q.get_existing_files()\n restore_temp_catalog()\n assert(len(files) == 1)\n \n def check_access_writable_file(self):\n \"\"\" There should always be a writable file -- even if it is in temp\n \"\"\"\n q = catalog.catalog()\n file = q.get_writable_file()\n try:\n f = open(file,'w')\n f.write('bob')\n finally:\n f.close()\n os.remove(file) \n def check_writable_with_bad_path(self):\n \"\"\" There should always be a writable file -- even if search paths contain\n bad values.\n \"\"\"\n if sys.platform == 'win32': sep = ';'\n else: sep = ':' \n os.environ['PYTHONCOMPILED'] = sep.join(('_bad_path_name_'))\n q = catalog.catalog()\n file = q.get_writable_file()\n try:\n f = open(file,'w')\n f.write('bob')\n finally:\n f.close()\n os.remove(file) \n def check_writable_dir(self):\n \"\"\" Check that we can create a file in the writable directory\n \"\"\"\n q = catalog.catalog()\n d = q.get_writable_dir()\n file = os.path.join(d,'some_silly_file')\n try:\n f = open(file,'w')\n f.write('bob')\n finally:\n f.close()\n os.remove(file)\n def check_unique_module_name(self):\n \"\"\" Check that we can create a file in the writable directory\n \"\"\"\n q = catalog.catalog()\n file = q.unique_module_name('bob')\n cfile1 = file+'.cpp'\n assert(not os.path.exists(cfile1))\n #make sure it is writable\n try:\n f = open(cfile1,'w')\n f.write('bob')\n finally: \n f.close()\n # try again with same code fragment -- should get unique name\n file = q.unique_module_name('bob')\n cfile2 = file+'.cpp'\n assert(not os.path.exists(cfile2+'.cpp'))\n os.remove(cfile1)\n def check_add_function_persistent1(self):\n \"\"\" Test persisting a function in the default catalog\n \"\"\"\n clear_temp_catalog()\n q = catalog.catalog()\n mod_name = q.unique_module_name('bob')\n d,f = os.path.split(mod_name)\n module_name, funcs = simple_module(d,f,'f')\n for i in funcs:\n q.add_function_persistent('code',i)\n pfuncs = q.get_cataloged_functions('code') \n os.remove(module_name)\n # any way to clean modules???\n restore_temp_catalog()\n for i in funcs:\n assert(i in pfuncs) \n \n def not_sure_about_this_check_add_function_persistent2(self):\n \"\"\" Test ordering of persistent functions\n \"\"\"\n clear_temp_catalog()\n q = catalog.catalog() \n \n mod_name = q.unique_module_name('bob') \n d,f = os.path.split(mod_name)\n module_name1, funcs1 = simple_module(d,f,'f')\n for i in funcs1:\n q.add_function_persistent('code',i)\n \n d = empty_temp_dir()\n q = catalog(d) \n mod_name = q.unique_module_name('bob') \n d,f = os.path.split(mod_name)\n module_name2, funcs2 = simple_module(d,f,'f')\n for i in funcs2:\n q.add_function_persistent('code',i)\n pfuncs = q.get_cataloged_functions('code') \n \n os.remove(module_name1)\n os.remove(module_name2)\n cleanup_temp_dir(d)\n restore_temp_catalog()\n # any way to clean modules???\n for i in funcs1:\n assert(i in pfuncs) \n for i in funcs2:\n assert(i in pfuncs)\n # make sure functions occur in correct order for\n # lookup \n all_funcs = zip(funcs1,funcs2)\n print all_funcs\n for a,b in all_funcs:\n assert(pfuncs.index(a) > pfuncs.index(b))\n \n assert(len(pfuncs) == 4)\n\n def check_add_function_ordered(self):\n clear_temp_catalog()\n q = catalog.catalog()\n import string\n \n q.add_function('f',string.upper) \n q.add_function('f',string.lower)\n q.add_function('ff',string.find) \n q.add_function('ff',string.replace)\n q.add_function('fff',string.atof)\n q.add_function('fff',string.atoi)\n del q\n\n # now we're gonna make a new catalog with same code\n # but different functions in a specified module directory\n env_dir = empty_temp_dir()\n r = catalog.catalog(env_dir)\n r.add_function('ff',os.abort)\n r.add_function('ff',os.chdir)\n r.add_function('fff',os.access)\n r.add_function('fff',os.open)\n del r\n # now we're gonna make a new catalog with same code\n # but different functions in a user specified directory\n user_dir = empty_temp_dir()\n s = catalog.catalog(user_dir)\n import re\n s.add_function('fff',re.match)\n s.add_function('fff',re.purge)\n del s\n\n # open new catalog and make sure it retreives the functions\n # from d catalog instead of the temp catalog (made by q)\n os.environ['PYTHONCOMPILED'] = env_dir\n t = catalog.catalog(user_dir)\n funcs1 = t.get_functions('f')\n funcs2 = t.get_functions('ff')\n funcs3 = t.get_functions('fff')\n restore_temp_catalog()\n # make sure everything is read back in the correct order\n assert(funcs1 == [string.lower,string.upper])\n assert(funcs2 == [os.chdir,os.abort,string.replace,string.find])\n assert(funcs3 == [re.purge,re.match,os.open,\n os.access,string.atoi,string.atof])\n cleanup_temp_dir(user_dir)\n cleanup_temp_dir(env_dir)\n \n \ndef test_suite():\n suites = []\n suites.append( unittest.makeSuite(test_default_dir,'check_'))\n suites.append( unittest.makeSuite(test_os_dependent_catalog_name,'check_'))\n suites.append( unittest.makeSuite(test_catalog_path,'check_'))\n suites.append( unittest.makeSuite(test_get_catalog,'check_'))\n suites.append( unittest.makeSuite(test_catalog,'check_'))\n\n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\n\nif __name__ == '__main__':\n test()\n", "source_code_before": "import unittest\nimport sys, os\n\n\nfrom scipy_distutils.misc_util import add_grandparent_to_path, restore_path\nfrom scipy_distutils.misc_util import add_local_to_path\n\nadd_grandparent_to_path(__name__)\nfrom catalog import *\n# not sure why, but was having problems with which catalog was being called.\nimport catalog\n#catalog = catalog.catalog\nrestore_path()\n\nadd_local_to_path(__name__)\nfrom weave_test_utils import *\nrestore_path()\n\n\nclass test_default_dir(unittest.TestCase):\n def check_is_writable(self):\n path = default_dir()\n name = os.path.join(path,'dummy_catalog')\n test_file = open(name,'w')\n try:\n test_file.write('making sure default location is writable\\n')\n finally:\n test_file.close()\n os.remove(name)\n\nclass test_os_dependent_catalog_name(unittest.TestCase): \n pass\n \nclass test_catalog_path(unittest.TestCase): \n def check_default(self):\n in_path = default_dir()\n path = catalog_path(in_path)\n d,f = os.path.split(path)\n assert(d == in_path)\n assert(f == os_dependent_catalog_name())\n def check_current(self):\n in_path = '.'\n path = catalog_path(in_path)\n d,f = os.path.split(path)\n assert(d == os.path.abspath(in_path)) \n assert(f == os_dependent_catalog_name()) \n def check_user(path):\n if sys.platform != 'win32':\n in_path = '~'\n path = catalog_path(in_path)\n d,f = os.path.split(path)\n assert(d == os.path.expanduser(in_path)) \n assert(f == os_dependent_catalog_name())\n def check_module(self):\n # hand it a module and see if it uses the parent directory\n # of the module.\n path = catalog_path(os.__file__)\n d,f = os.path.split(os.__file__)\n d2,f = os.path.split(path)\n assert (d2 == d)\n def check_path(self):\n # use os.__file__ to get a usable directory.\n in_path,f = os.path.split(os.__file__)\n path = catalog_path(in_path)\n d,f = os.path.split(path)\n assert (d == in_path)\n def check_bad_path(self):\n # stupid_path_name\n in_path = 'stupid_path_name'\n path = catalog_path(in_path)\n assert (path is None)\n\nclass test_get_catalog(unittest.TestCase):\n \"\"\" This only tests whether new catalogs are created correctly.\n And whether non-existent return None correctly with read mode.\n Putting catalogs in the right place is all tested with\n catalog_dir tests.\n \"\"\"\n def get_test_dir(self,erase = 0):\n # make sure tempdir catalog doesn't exist\n import tempfile\n temp = tempfile.gettempdir()\n pardir = os.path.join(temp,'catalog_test')\n if not os.path.exists(pardir):\n os.mkdir(pardir)\n catalog_file = os.path.join(pardir,os_dependent_catalog_name()+'.dat')\n if os.path.exists(catalog_file) and erase:\n os.remove(catalog_file)\n catalog_file = os.path.join(pardir,os_dependent_catalog_name()+'.dir')\n if os.path.exists(catalog_file) and erase:\n os.remove(catalog_file)\n catalog_file = os.path.join(pardir,os_dependent_catalog_name())\n if os.path.exists(catalog_file) and erase:\n os.remove(catalog_file)\n return pardir\n def check_nonexistent_catalog_is_none(self):\n pardir = self.get_test_dir(erase=1)\n catalog = get_catalog(pardir)\n assert(catalog is None)\n def check_create_catalog(self):\n pardir = self.get_test_dir(erase=1)\n catalog = get_catalog(pardir,'cr')\n assert(catalog is not None)\n\nclass test_catalog(unittest.TestCase):\n\n def clear_environ(self):\n if os.environ.has_key('PYTHONCOMPILED'):\n self.old_PYTHONCOMPILED = os.environ['PYTHONCOMPILED']\n del os.environ['PYTHONCOMPILED']\n else: \n self.old_PYTHONCOMPILED = None\n def reset_environ(self):\n if self.old_PYTHONCOMPILED:\n os.environ['PYTHONCOMPILED'] = self.old_PYTHONCOMPILED\n self.old_PYTHONCOMPILED = None\n def setUp(self):\n self.clear_environ() \n def tearDown(self):\n self.reset_environ()\n \n def check_set_module_directory(self):\n q = catalog.catalog()\n q.set_module_directory('bob')\n r = q.get_module_directory()\n assert (r == 'bob')\n def check_clear_module_directory(self):\n q = catalog.catalog()\n r = q.get_module_directory()\n assert (r == None)\n q.set_module_directory('bob')\n r = q.clear_module_directory()\n assert (r == None)\n def check_get_environ_path(self):\n if sys.platform == 'win32': sep = ';'\n else: sep = ':'\n os.environ['PYTHONCOMPILED'] = sep.join(('path1','path2','path3'))\n q = catalog.catalog()\n path = q.get_environ_path() \n assert(path == ['path1','path2','path3'])\n def check_build_search_order1(self): \n \"\"\" MODULE in search path should be replaced by module_dir.\n \"\"\" \n q = catalog.catalog(['first','MODULE','third'])\n q.set_module_directory('second')\n order = q.build_search_order()\n assert(order == ['first','second','third',default_dir()])\n def check_build_search_order2(self): \n \"\"\" MODULE in search path should be removed if module_dir==None.\n \"\"\" \n q = catalog.catalog(['first','MODULE','third'])\n order = q.build_search_order()\n assert(order == ['first','third',default_dir()]) \n def check_build_search_order3(self):\n \"\"\" If MODULE is absent, module_dir shouldn't be in search path.\n \"\"\" \n q = catalog.catalog(['first','second'])\n q.set_module_directory('third')\n order = q.build_search_order()\n assert(order == ['first','second',default_dir()])\n def check_build_search_order4(self):\n \"\"\" Make sure environment variable is getting used.\n \"\"\" \n q = catalog.catalog(['first','second'])\n if sys.platform == 'win32': sep = ';'\n else: sep = ':'\n os.environ['PYTHONCOMPILED'] = sep.join(('MODULE','fourth','fifth'))\n q.set_module_directory('third')\n order = q.build_search_order()\n assert(order == ['first','second','third','fourth','fifth',default_dir()])\n \n def check_catalog_files1(self):\n \"\"\" Be sure we get at least one file even without specifying the path.\n \"\"\"\n q = catalog.catalog()\n files = q.get_catalog_files()\n assert(len(files) == 1)\n\n def check_catalog_files2(self):\n \"\"\" Ignore bad paths in the path.\n \"\"\"\n q = catalog.catalog()\n os.environ['PYTHONCOMPILED'] = '_some_bad_path_'\n files = q.get_catalog_files()\n assert(len(files) == 1)\n \n def check_get_existing_files1(self):\n \"\"\" Shouldn't get any files when temp doesn't exist and no path set. \n \"\"\" \n clear_temp_catalog()\n q = catalog.catalog()\n files = q.get_existing_files()\n restore_temp_catalog()\n assert(len(files) == 0)\n def check_get_existing_files2(self):\n \"\"\" Shouldn't get a single file from the temp dir.\n \"\"\" \n clear_temp_catalog()\n q = catalog.catalog()\n # create a dummy file\n import os \n q.add_function('code', os.getpid)\n del q\n q = catalog.catalog()\n files = q.get_existing_files()\n restore_temp_catalog()\n assert(len(files) == 1)\n \n def check_access_writable_file(self):\n \"\"\" There should always be a writable file -- even if it is in temp\n \"\"\"\n q = catalog.catalog()\n file = q.get_writable_file()\n try:\n f = open(file,'w')\n f.write('bob')\n finally:\n f.close()\n os.remove(file) \n def check_writable_with_bad_path(self):\n \"\"\" There should always be a writable file -- even if search paths contain\n bad values.\n \"\"\"\n if sys.platform == 'win32': sep = ';'\n else: sep = ':' \n os.environ['PYTHONCOMPILED'] = sep.join(('_bad_path_name_'))\n q = catalog.catalog()\n file = q.get_writable_file()\n try:\n f = open(file,'w')\n f.write('bob')\n finally:\n f.close()\n os.remove(file) \n def check_writable_dir(self):\n \"\"\" Check that we can create a file in the writable directory\n \"\"\"\n q = catalog.catalog()\n d = q.get_writable_dir()\n file = os.path.join(d,'some_silly_file')\n try:\n f = open(file,'w')\n f.write('bob')\n finally:\n f.close()\n os.remove(file)\n def check_unique_module_name(self):\n \"\"\" Check that we can create a file in the writable directory\n \"\"\"\n q = catalog.catalog()\n file = q.unique_module_name('bob')\n cfile1 = file+'.cpp'\n assert(not os.path.exists(cfile1))\n #make sure it is writable\n try:\n f = open(cfile1,'w')\n f.write('bob')\n finally: \n f.close()\n # try again with same code fragment -- should get unique name\n file = q.unique_module_name('bob')\n cfile2 = file+'.cpp'\n assert(not os.path.exists(cfile2+'.cpp'))\n os.remove(cfile1)\n def check_add_function_persistent1(self):\n \"\"\" Test persisting a function in the default catalog\n \"\"\"\n clear_temp_catalog()\n q = catalog.catalog()\n mod_name = q.unique_module_name('bob')\n d,f = os.path.split(mod_name)\n module_name, funcs = simple_module(d,f,'f')\n for i in funcs:\n q.add_function_persistent('code',i)\n pfuncs = q.get_cataloged_functions('code') \n os.remove(module_name)\n # any way to clean modules???\n restore_temp_catalog()\n for i in funcs:\n assert(i in pfuncs) \n \n def not_sure_about_this_check_add_function_persistent2(self):\n \"\"\" Test ordering of persistent functions\n \"\"\"\n clear_temp_catalog()\n q = catalog.catalog() \n \n mod_name = q.unique_module_name('bob') \n d,f = os.path.split(mod_name)\n module_name1, funcs1 = simple_module(d,f,'f')\n for i in funcs1:\n q.add_function_persistent('code',i)\n \n d = empty_temp_dir()\n q = catalog(d) \n mod_name = q.unique_module_name('bob') \n d,f = os.path.split(mod_name)\n module_name2, funcs2 = simple_module(d,f,'f')\n for i in funcs2:\n q.add_function_persistent('code',i)\n pfuncs = q.get_cataloged_functions('code') \n \n os.remove(module_name1)\n os.remove(module_name2)\n cleanup_temp_dir(d)\n restore_temp_catalog()\n # any way to clean modules???\n for i in funcs1:\n assert(i in pfuncs) \n for i in funcs2:\n assert(i in pfuncs)\n # make sure functions occur in correct order for\n # lookup \n all_funcs = zip(funcs1,funcs2)\n print all_funcs\n for a,b in all_funcs:\n assert(pfuncs.index(a) > pfuncs.index(b))\n \n assert(len(pfuncs) == 4)\n\n def check_add_function_ordered(self):\n clear_temp_catalog()\n q = catalog.catalog()\n import string\n \n q.add_function('f',string.upper) \n q.add_function('f',string.lower)\n q.add_function('ff',string.find) \n q.add_function('ff',string.replace)\n q.add_function('fff',string.atof)\n q.add_function('fff',string.atoi)\n del q\n\n # now we're gonna make a new catalog with same code\n # but different functions in a specified module directory\n env_dir = empty_temp_dir()\n r = catalog.catalog(env_dir)\n r.add_function('ff',os.abort)\n r.add_function('ff',os.chdir)\n r.add_function('fff',os.access)\n r.add_function('fff',os.open)\n del r\n # now we're gonna make a new catalog with same code\n # but different functions in a user specified directory\n user_dir = empty_temp_dir()\n s = catalog.catalog(user_dir)\n import re\n s.add_function('fff',re.match)\n s.add_function('fff',re.purge)\n del s\n\n # open new catalog and make sure it retreives the functions\n # from d catalog instead of the temp catalog (made by q)\n os.environ['PYTHONCOMPILED'] = env_dir\n t = catalog.catalog(user_dir)\n funcs1 = t.get_functions('f')\n funcs2 = t.get_functions('ff')\n funcs3 = t.get_functions('fff')\n restore_temp_catalog()\n # make sure everything is read back in the correct order\n assert(funcs1 == [string.lower,string.upper])\n assert(funcs2 == [os.chdir,os.abort,string.replace,string.find])\n assert(funcs3 == [re.purge,re.match,os.open,\n os.access,string.atoi,string.atof])\n cleanup_temp_dir(user_dir)\n cleanup_temp_dir(env_dir)\n \n \ndef test_suite():\n suites = []\n suites.append( unittest.makeSuite(test_default_dir,'check_'))\n suites.append( unittest.makeSuite(test_os_dependent_catalog_name,'check_'))\n suites.append( unittest.makeSuite(test_catalog_path,'check_'))\n suites.append( unittest.makeSuite(test_get_catalog,'check_'))\n suites.append( unittest.makeSuite(test_catalog,'check_'))\n\n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\n\nif __name__ == '__main__':\n test()\n", "methods": [ { "name": "check_is_writable", "long_name": "check_is_writable( self )", "filename": "test_catalog.py", "nloc": 9, "complexity": 2, "token_count": 51, "parameters": [ "self" ], "start_line": 21, "end_line": 29, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "check_default", "long_name": "check_default( self )", "filename": "test_catalog.py", "nloc": 6, "complexity": 1, "token_count": 42, "parameters": [ "self" ], "start_line": 35, "end_line": 40, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "check_current", "long_name": "check_current( self )", "filename": "test_catalog.py", "nloc": 6, "complexity": 1, "token_count": 47, "parameters": [ "self" ], "start_line": 41, "end_line": 46, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "check_user", "long_name": "check_user( path )", "filename": "test_catalog.py", "nloc": 7, "complexity": 2, "token_count": 54, "parameters": [ "path" ], "start_line": 47, "end_line": 53, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_module", "long_name": "check_module( self )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 45, "parameters": [ "self" ], "start_line": 54, "end_line": 60, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_path", "long_name": "check_path( self )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 43, "parameters": [ "self" ], "start_line": 61, "end_line": 66, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "check_bad_path", "long_name": "check_bad_path( self )", "filename": "test_catalog.py", "nloc": 4, "complexity": 1, "token_count": 20, "parameters": [ "self" ], "start_line": 67, "end_line": 71, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "get_test_dir", "long_name": "get_test_dir( self , erase = 0 )", "filename": "test_catalog.py", "nloc": 16, "complexity": 8, "token_count": 155, "parameters": [ "self", "erase" ], "start_line": 79, "end_line": 95, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 1 }, { "name": "check_nonexistent_catalog_is_none", "long_name": "check_nonexistent_catalog_is_none( self )", "filename": "test_catalog.py", "nloc": 4, "complexity": 1, "token_count": 27, "parameters": [ "self" ], "start_line": 96, "end_line": 99, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_create_catalog", "long_name": "check_create_catalog( self )", "filename": "test_catalog.py", "nloc": 4, "complexity": 1, "token_count": 30, "parameters": [ "self" ], "start_line": 100, "end_line": 103, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "clear_environ", "long_name": "clear_environ( self )", "filename": "test_catalog.py", "nloc": 6, "complexity": 2, "token_count": 39, "parameters": [ "self" ], "start_line": 107, "end_line": 112, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "reset_environ", "long_name": "reset_environ( self )", "filename": "test_catalog.py", "nloc": 4, "complexity": 2, "token_count": 25, "parameters": [ "self" ], "start_line": 113, "end_line": 116, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "setUp", "long_name": "setUp( self )", "filename": "test_catalog.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 117, "end_line": 118, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "tearDown", "long_name": "tearDown( self )", "filename": "test_catalog.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 119, "end_line": 120, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_set_module_directory", "long_name": "check_set_module_directory( self )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 31, "parameters": [ "self" ], "start_line": 122, "end_line": 126, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_clear_module_directory", "long_name": "check_clear_module_directory( self )", "filename": "test_catalog.py", "nloc": 7, "complexity": 1, "token_count": 44, "parameters": [ "self" ], "start_line": 127, "end_line": 133, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_get_environ_path", "long_name": "check_get_environ_path( self )", "filename": "test_catalog.py", "nloc": 7, "complexity": 2, "token_count": 65, "parameters": [ "self" ], "start_line": 134, "end_line": 140, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_build_search_order1", "long_name": "check_build_search_order1( self )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 49, "parameters": [ "self" ], "start_line": 141, "end_line": 147, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_build_search_order2", "long_name": "check_build_search_order2( self )", "filename": "test_catalog.py", "nloc": 4, "complexity": 1, "token_count": 41, "parameters": [ "self" ], "start_line": 148, "end_line": 153, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "check_build_search_order3", "long_name": "check_build_search_order3( self )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 45, "parameters": [ "self" ], "start_line": 154, "end_line": 160, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_build_search_order4", "long_name": "check_build_search_order4( self )", "filename": "test_catalog.py", "nloc": 8, "complexity": 2, "token_count": 85, "parameters": [ "self" ], "start_line": 161, "end_line": 170, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "check_catalog_files1", "long_name": "check_catalog_files1( self )", "filename": "test_catalog.py", "nloc": 4, "complexity": 1, "token_count": 29, "parameters": [ "self" ], "start_line": 172, "end_line": 177, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "check_catalog_files2", "long_name": "check_catalog_files2( self )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 37, "parameters": [ "self" ], "start_line": 179, "end_line": 185, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_get_existing_files1", "long_name": "check_get_existing_files1( self )", "filename": "test_catalog.py", "nloc": 6, "complexity": 1, "token_count": 35, "parameters": [ "self" ], "start_line": 187, "end_line": 194, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "check_get_existing_files2", "long_name": "check_get_existing_files2( self )", "filename": "test_catalog.py", "nloc": 10, "complexity": 1, "token_count": 56, "parameters": [ "self" ], "start_line": 195, "end_line": 207, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "check_access_writable_file", "long_name": "check_access_writable_file( self )", "filename": "test_catalog.py", "nloc": 9, "complexity": 2, "token_count": 49, "parameters": [ "self" ], "start_line": 209, "end_line": 219, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 1 }, { "name": "check_writable_with_bad_path", "long_name": "check_writable_with_bad_path( self )", "filename": "test_catalog.py", "nloc": 12, "complexity": 3, "token_count": 79, "parameters": [ "self" ], "start_line": 220, "end_line": 234, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "check_writable_dir", "long_name": "check_writable_dir( self )", "filename": "test_catalog.py", "nloc": 10, "complexity": 2, "token_count": 61, "parameters": [ "self" ], "start_line": 235, "end_line": 246, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 12, "top_nesting_level": 1 }, { "name": "check_unique_module_name", "long_name": "check_unique_module_name( self )", "filename": "test_catalog.py", "nloc": 14, "complexity": 2, "token_count": 94, "parameters": [ "self" ], "start_line": 247, "end_line": 264, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 1 }, { "name": "check_add_function_persistent1", "long_name": "check_add_function_persistent1( self )", "filename": "test_catalog.py", "nloc": 13, "complexity": 3, "token_count": 89, "parameters": [ "self" ], "start_line": 265, "end_line": 280, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "not_sure_about_this_check_add_function_persistent2", "long_name": "not_sure_about_this_check_add_function_persistent2( self )", "filename": "test_catalog.py", "nloc": 29, "complexity": 6, "token_count": 208, "parameters": [ "self" ], "start_line": 282, "end_line": 319, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 38, "top_nesting_level": 1 }, { "name": "check_add_function_ordered", "long_name": "check_add_function_ordered( self )", "filename": "test_catalog.py", "nloc": 36, "complexity": 1, "token_count": 288, "parameters": [ "self" ], "start_line": 321, "end_line": 366, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 46, "top_nesting_level": 1 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_catalog.py", "nloc": 9, "complexity": 1, "token_count": 83, "parameters": [], "start_line": 369, "end_line": 378, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 380, "end_line": 384, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "methods_before": [ { "name": "check_is_writable", "long_name": "check_is_writable( self )", "filename": "test_catalog.py", "nloc": 9, "complexity": 2, "token_count": 51, "parameters": [ "self" ], "start_line": 21, "end_line": 29, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "check_default", "long_name": "check_default( self )", "filename": "test_catalog.py", "nloc": 6, "complexity": 1, "token_count": 42, "parameters": [ "self" ], "start_line": 35, "end_line": 40, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "check_current", "long_name": "check_current( self )", "filename": "test_catalog.py", "nloc": 6, "complexity": 1, "token_count": 47, "parameters": [ "self" ], "start_line": 41, "end_line": 46, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "check_user", "long_name": "check_user( path )", "filename": "test_catalog.py", "nloc": 7, "complexity": 2, "token_count": 54, "parameters": [ "path" ], "start_line": 47, "end_line": 53, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_module", "long_name": "check_module( self )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 45, "parameters": [ "self" ], "start_line": 54, "end_line": 60, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_path", "long_name": "check_path( self )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 43, "parameters": [ "self" ], "start_line": 61, "end_line": 66, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "check_bad_path", "long_name": "check_bad_path( self )", "filename": "test_catalog.py", "nloc": 4, "complexity": 1, "token_count": 20, "parameters": [ "self" ], "start_line": 67, "end_line": 71, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "get_test_dir", "long_name": "get_test_dir( self , erase = 0 )", "filename": "test_catalog.py", "nloc": 16, "complexity": 8, "token_count": 149, "parameters": [ "self", "erase" ], "start_line": 79, "end_line": 95, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 1 }, { "name": "check_nonexistent_catalog_is_none", "long_name": "check_nonexistent_catalog_is_none( self )", "filename": "test_catalog.py", "nloc": 4, "complexity": 1, "token_count": 27, "parameters": [ "self" ], "start_line": 96, "end_line": 99, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_create_catalog", "long_name": "check_create_catalog( self )", "filename": "test_catalog.py", "nloc": 4, "complexity": 1, "token_count": 30, "parameters": [ "self" ], "start_line": 100, "end_line": 103, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "clear_environ", "long_name": "clear_environ( self )", "filename": "test_catalog.py", "nloc": 6, "complexity": 2, "token_count": 39, "parameters": [ "self" ], "start_line": 107, "end_line": 112, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "reset_environ", "long_name": "reset_environ( self )", "filename": "test_catalog.py", "nloc": 4, "complexity": 2, "token_count": 25, "parameters": [ "self" ], "start_line": 113, "end_line": 116, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "setUp", "long_name": "setUp( self )", "filename": "test_catalog.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 117, "end_line": 118, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "tearDown", "long_name": "tearDown( self )", "filename": "test_catalog.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 119, "end_line": 120, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_set_module_directory", "long_name": "check_set_module_directory( self )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 31, "parameters": [ "self" ], "start_line": 122, "end_line": 126, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_clear_module_directory", "long_name": "check_clear_module_directory( self )", "filename": "test_catalog.py", "nloc": 7, "complexity": 1, "token_count": 44, "parameters": [ "self" ], "start_line": 127, "end_line": 133, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_get_environ_path", "long_name": "check_get_environ_path( self )", "filename": "test_catalog.py", "nloc": 7, "complexity": 2, "token_count": 65, "parameters": [ "self" ], "start_line": 134, "end_line": 140, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_build_search_order1", "long_name": "check_build_search_order1( self )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 49, "parameters": [ "self" ], "start_line": 141, "end_line": 147, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_build_search_order2", "long_name": "check_build_search_order2( self )", "filename": "test_catalog.py", "nloc": 4, "complexity": 1, "token_count": 41, "parameters": [ "self" ], "start_line": 148, "end_line": 153, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "check_build_search_order3", "long_name": "check_build_search_order3( self )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 45, "parameters": [ "self" ], "start_line": 154, "end_line": 160, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_build_search_order4", "long_name": "check_build_search_order4( self )", "filename": "test_catalog.py", "nloc": 8, "complexity": 2, "token_count": 85, "parameters": [ "self" ], "start_line": 161, "end_line": 170, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "check_catalog_files1", "long_name": "check_catalog_files1( self )", "filename": "test_catalog.py", "nloc": 4, "complexity": 1, "token_count": 29, "parameters": [ "self" ], "start_line": 172, "end_line": 177, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "check_catalog_files2", "long_name": "check_catalog_files2( self )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 37, "parameters": [ "self" ], "start_line": 179, "end_line": 185, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "check_get_existing_files1", "long_name": "check_get_existing_files1( self )", "filename": "test_catalog.py", "nloc": 6, "complexity": 1, "token_count": 35, "parameters": [ "self" ], "start_line": 187, "end_line": 194, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "check_get_existing_files2", "long_name": "check_get_existing_files2( self )", "filename": "test_catalog.py", "nloc": 10, "complexity": 1, "token_count": 56, "parameters": [ "self" ], "start_line": 195, "end_line": 207, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "check_access_writable_file", "long_name": "check_access_writable_file( self )", "filename": "test_catalog.py", "nloc": 9, "complexity": 2, "token_count": 49, "parameters": [ "self" ], "start_line": 209, "end_line": 219, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 1 }, { "name": "check_writable_with_bad_path", "long_name": "check_writable_with_bad_path( self )", "filename": "test_catalog.py", "nloc": 12, "complexity": 3, "token_count": 79, "parameters": [ "self" ], "start_line": 220, "end_line": 234, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "check_writable_dir", "long_name": "check_writable_dir( self )", "filename": "test_catalog.py", "nloc": 10, "complexity": 2, "token_count": 61, "parameters": [ "self" ], "start_line": 235, "end_line": 246, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 12, "top_nesting_level": 1 }, { "name": "check_unique_module_name", "long_name": "check_unique_module_name( self )", "filename": "test_catalog.py", "nloc": 14, "complexity": 2, "token_count": 94, "parameters": [ "self" ], "start_line": 247, "end_line": 264, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 1 }, { "name": "check_add_function_persistent1", "long_name": "check_add_function_persistent1( self )", "filename": "test_catalog.py", "nloc": 13, "complexity": 3, "token_count": 89, "parameters": [ "self" ], "start_line": 265, "end_line": 280, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "not_sure_about_this_check_add_function_persistent2", "long_name": "not_sure_about_this_check_add_function_persistent2( self )", "filename": "test_catalog.py", "nloc": 29, "complexity": 6, "token_count": 208, "parameters": [ "self" ], "start_line": 282, "end_line": 319, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 38, "top_nesting_level": 1 }, { "name": "check_add_function_ordered", "long_name": "check_add_function_ordered( self )", "filename": "test_catalog.py", "nloc": 36, "complexity": 1, "token_count": 288, "parameters": [ "self" ], "start_line": 321, "end_line": 366, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 46, "top_nesting_level": 1 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_catalog.py", "nloc": 9, "complexity": 1, "token_count": 83, "parameters": [], "start_line": 369, "end_line": 378, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_catalog.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 380, "end_line": 384, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "get_test_dir", "long_name": "get_test_dir( self , erase = 0 )", "filename": "test_catalog.py", "nloc": 16, "complexity": 8, "token_count": 155, "parameters": [ "self", "erase" ], "start_line": 79, "end_line": 95, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 1 } ], "nloc": 307, "complexity": 59, "token_count": 2218, "diff_parsed": { "added": [ " pardir = os.path.join(temp,'catalog_test'+tempfile.gettempprefix())" ], "deleted": [ " pardir = os.path.join(temp,'catalog_test')" ] } } ] }, { "hash": "06d067a4c9382426c8755cdcc39c3ce2ebf38706", "msg": "changed inline() args so that arg_names defaults to an empty list. THis allows you to run C code that doesn't need any arguments without supplying any.", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-04T03:40:54+00:00", "author_timezone": 0, "committer_date": "2002-01-04T03:40:54+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "dfa34a79638600346b06aab7d157db855d22a1ba" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 3, "insertions": 4, "lines": 7, "files": 1, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": "weave/inline_tools.py", "new_path": "weave/inline_tools.py", "filename": "inline_tools.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -130,7 +130,7 @@ def __init__(self,name,compiler=''):\n self._build_information.append(inline_info.inline_info())\n \n function_cache = {}\n-def inline(code,arg_names,local_dict = None, global_dict = None,\n+def inline(code,arg_names=[],local_dict = None, global_dict = None,\n force = 0,\n compiler='',\n verbose = 0,\n@@ -157,8 +157,9 @@ def inline(code,arg_names,local_dict = None, global_dict = None,\n code -- string. A string of valid C++ code. It should not specify a\n return statement. Instead it should assign results that\n need to be returned to Python in the return_val.\n- arg_names -- list of strings. A list of Python variable names that\n- should be transferred from Python into the C/C++ code.\n+ arg_names -- optional. list of strings. A list of Python variable names \n+ that should be transferred from Python into the C/C++ \n+ code. It defaults to an empty string.\n local_dict -- optional. dictionary. If specified, it is a dictionary\n of values that should be used as the local scope for the\n C/C++ code. If local_dict is not specified the local\n", "added_lines": 4, "deleted_lines": 3, "source_code": "# should re-write compiled functions to take a local and global dict\n# as input.\nimport sys,os\nimport ext_tools\nimport string\nfrom catalog import catalog\nimport inline_info, cxx_info\n\n# not an easy way for the user_path_list to come in here.\n# the PYTHONCOMPILED environment variable offers the most hope.\n\nfunction_catalog = catalog()\n\n\nclass inline_ext_function(ext_tools.ext_function):\n # Some specialization is needed for inline extension functions\n def function_declaration_code(self):\n code = 'static PyObject* %s(PyObject*self, PyObject* args)\\n{\\n'\n return code % self.name\n\n def template_declaration_code(self):\n code = 'template\\n' \\\n 'static PyObject* %s(PyObject*self, PyObject* args)\\n{\\n'\n return code % self.name\n\n def parse_tuple_code(self):\n \"\"\" Create code block for PyArg_ParseTuple. Variable declarations\n for all PyObjects are done also.\n\n This code got a lot uglier when I added local_dict...\n \"\"\"\n declare_return = 'PyObject *return_val = NULL;\\n' \\\n 'int exception_occured = 0;\\n' \\\n 'PyObject *py__locals = NULL;\\n' \\\n 'PyObject *py__globals = NULL;\\n'\n\n py_objects = ', '.join(self.arg_specs.py_pointers())\n if py_objects:\n declare_py_objects = 'PyObject ' + py_objects +';\\n'\n else:\n declare_py_objects = ''\n\n py_vars = ' = '.join(self.arg_specs.py_variables())\n if py_vars:\n init_values = py_vars + ' = NULL;\\n\\n'\n else:\n init_values = ''\n\n parse_tuple = 'if(!PyArg_ParseTuple(args,\"OO:compiled_func\",'\\\n '&py__locals,'\\\n '&py__globals))\\n'\\\n ' return NULL;\\n'\n\n return declare_return + declare_py_objects + \\\n init_values + parse_tuple\n\n def arg_declaration_code(self):\n arg_strings = []\n for arg in self.arg_specs:\n arg_strings.append(arg.declaration_code(inline=1))\n code = string.join(arg_strings,\"\")\n return code\n\n def arg_cleanup_code(self):\n arg_strings = []\n for arg in self.arg_specs:\n arg_strings.append(arg.cleanup_code())\n code = string.join(arg_strings,\"\")\n return code\n\n def arg_local_dict_code(self):\n arg_strings = []\n for arg in self.arg_specs:\n arg_strings.append(arg.local_dict_code())\n code = string.join(arg_strings,\"\")\n return code\n\n\n def function_code(self):\n from ext_tools import indent\n decl_code = indent(self.arg_declaration_code(),4)\n cleanup_code = indent(self.arg_cleanup_code(),4)\n function_code = indent(self.code_block,4)\n #local_dict_code = indent(self.arg_local_dict_code(),4)\n\n try_code = 'try \\n' \\\n '{ \\n' \\\n ' PyObject* raw_locals = py_to_raw_dict(' \\\n 'py__locals,\"_locals\");\\n' \\\n ' PyObject* raw_globals = py_to_raw_dict(' \\\n 'py__globals,\"_globals\");\\n' + \\\n ' /* argument conversion code */ \\n' + \\\n decl_code + \\\n ' /* inline code */ \\n' + \\\n function_code + \\\n ' /*I would like to fill in changed ' \\\n 'locals and globals here...*/ \\n' \\\n '\\n} \\n'\n catch_code = \"catch( Py::Exception& e) \\n\" \\\n \"{ \\n\" + \\\n \" return_val = Py::Null(); \\n\" \\\n \" exception_occured = 1; \\n\" \\\n \"} \\n\"\n return_code = \" /* cleanup code */ \\n\" + \\\n cleanup_code + \\\n \" if(!return_val && !exception_occured)\\n\" \\\n \" {\\n \\n\" \\\n \" Py_INCREF(Py_None); \\n\" \\\n \" return_val = Py_None; \\n\" \\\n \" }\\n \\n\" \\\n \" return return_val; \\n\" \\\n \"} \\n\"\n\n all_code = self.function_declaration_code() + \\\n indent(self.parse_tuple_code(),4) + \\\n indent(try_code,4) + \\\n indent(catch_code,4) + \\\n return_code\n\n return all_code\n\n def python_function_definition_code(self):\n args = (self.name, self.name)\n function_decls = '{\"%s\",(PyCFunction)%s , METH_VARARGS},\\n' % args\n return function_decls\n\nclass inline_ext_module(ext_tools.ext_module):\n def __init__(self,name,compiler=''):\n ext_tools.ext_module.__init__(self,name,compiler)\n self._build_information.append(inline_info.inline_info())\n\nfunction_cache = {}\ndef inline(code,arg_names=[],local_dict = None, global_dict = None,\n force = 0,\n compiler='',\n verbose = 0,\n support_code = None,\n customize=None,\n type_factories = None,\n auto_downcast=1,\n **kw):\n \"\"\" Inline C/C++ code within Python scripts.\n\n inline() compiles and executes C/C++ code on the fly. Variables\n in the local and global Python scope are also available in the\n C/C++ code. Values are passed to the C/C++ code by assignment\n much like variables passed are passed into a standard Python\n function. Values are returned from the C/C++ code through a\n special argument called return_val. Also, the contents of\n mutable objects can be changed within the C/C++ code and the\n changes remain after the C code exits and returns to Python.\n\n inline has quite a few options as listed below. Also, the keyword\n arguments for distutils extension modules are accepted to\n specify extra information needed for compiling.\n\n code -- string. A string of valid C++ code. It should not specify a\n return statement. Instead it should assign results that\n need to be returned to Python in the return_val.\n arg_names -- optional. list of strings. A list of Python variable names \n that should be transferred from Python into the C/C++ \n code. It defaults to an empty string.\n local_dict -- optional. dictionary. If specified, it is a dictionary\n of values that should be used as the local scope for the\n C/C++ code. If local_dict is not specified the local\n dictionary of the calling function is used.\n global_dict -- optional. dictionary. If specified, it is a dictionary\n of values that should be used as the global scope for\n the C/C++ code. If global_dict is not specified the\n global dictionary of the calling function is used.\n force -- optional. 0 or 1. default 0. If 1, the C++ code is\n compiled every time inline is called. This is really\n only useful for debugging, and probably only useful if\n your editing support_code a lot.\n compiler -- optional. string. The name of compiler to use when\n compiling. On windows, it understands 'msvc' and 'gcc'\n as well as all the compiler names understood by\n distutils. On Unix, it'll only understand the values\n understoof by distutils. ( I should add 'gcc' though\n to this).\n\n On windows, the compiler defaults to the Microsoft C++\n compiler. If this isn't available, it looks for mingw32\n (the gcc compiler).\n\n On Unix, it'll probably use the same compiler that was\n used when compiling Python. Cygwin's behavior should be\n similar.\n verbose -- optional. 0,1, or 2. defualt 0. Speficies how much\n much information is printed during the compile phase\n of inlining code. 0 is silent (except on windows with\n msvc where it still prints some garbage). 1 informs\n you when compiling starts, finishes, and how long it\n took. 2 prints out the command lines for the compilation\n process and can be useful if your having problems\n getting code to work. Its handy for finding the name\n of the .cpp file if you need to examine it. verbose has\n no affect if the compilation isn't necessary.\n support_code -- optional. string. A string of valid C++ code declaring\n extra code that might be needed by your compiled\n function. This could be declarations of functions,\n classes, or structures.\n customize -- optional. base_info.custom_info object. An alternative\n way to specifiy support_code, headers, etc. needed by\n the function see the compiler.base_info module for more\n details. (not sure this'll be used much).\n type_factories -- optional. list of type specification factories. These\n guys are what convert Python data types to C/C++ data\n types. If you'd like to use a different set of type\n conversions than the default, specify them here. Look\n in the type conversions section of the main\n documentation for examples.\n auto_downcast -- optional. 0 or 1. default 1. This only affects\n functions that have Numeric arrays as input variables.\n Setting this to 1 will cause all floating point values\n to be cast as float instead of double if all the\n Numeric arrays are of type float. If even one of the\n arrays has type double or double complex, all\n variables maintain there standard types.\n\n Distutils keywords. These are cut and pasted from Greg Ward's\n distutils.extension.Extension class for convenience:\n\n sources : [string]\n list of source filenames, relative to the distribution root\n (where the setup script lives), in Unix form (slash-separated)\n for portability. Source files may be C, C++, SWIG (.i),\n platform-specific resource files, or whatever else is recognized\n by the \"build_ext\" command as source for a Python extension.\n Note: The module_path file is always appended to the front of this\n list\n include_dirs : [string]\n list of directories to search for C/C++ header files (in Unix\n form for portability)\n define_macros : [(name : string, value : string|None)]\n list of macros to define; each macro is defined using a 2-tuple,\n where 'value' is either the string to define it to or None to\n define it without a particular value (equivalent of \"#define\n FOO\" in source or -DFOO on Unix C compiler command line)\n undef_macros : [string]\n list of macros to undefine explicitly\n library_dirs : [string]\n list of directories to search for C/C++ libraries at link time\n libraries : [string]\n list of library names (not filenames or paths) to link against\n runtime_library_dirs : [string]\n list of directories to search for C/C++ libraries at run time\n (for shared extensions, this is when the extension is loaded)\n extra_objects : [string]\n list of extra files to link with (eg. object files not implied\n by 'sources', static library that must be explicitly specified,\n binary resource files, etc.)\n extra_compile_args : [string]\n any extra platform- and compiler-specific information to use\n when compiling the source files in 'sources'. For platforms and\n compilers where \"command line\" makes sense, this is typically a\n list of command-line arguments, but for other platforms it could\n be anything.\n extra_link_args : [string]\n any extra platform- and compiler-specific information to use\n when linking object files together to create the extension (or\n to create a new static Python interpreter). Similar\n interpretation as for 'extra_compile_args'.\n export_symbols : [string]\n list of symbols to be exported from a shared extension. Not\n used on all platforms, and not generally necessary for Python\n extensions, which typically export exactly one symbol: \"init\" +\n extension_name.\n \"\"\"\n # this grabs the local variables from the *previous* call\n # frame -- that is the locals from the function that called\n # inline.\n global function_catalog\n\n call_frame = sys._getframe().f_back\n if local_dict is None:\n local_dict = call_frame.f_locals\n if global_dict is None:\n global_dict = call_frame.f_globals\n if force:\n module_dir = global_dict.get('__file__',None)\n func = compile_function(code,arg_names,local_dict,\n global_dict,module_dir,\n compiler=compiler,\n verbose=verbose,\n support_code = support_code,\n customize=customize,\n type_factories = type_factories,\n auto_downcast = auto_downcast,\n **kw)\n\n function_catalog.add_function(code,func,module_dir)\n results = attempt_function_call(code,local_dict,global_dict)\n else:\n # 1. try local cache\n try:\n results = apply(function_cache[code],(local_dict,global_dict))\n return results\n except:\n pass\n\n # 2. try function catalog\n try:\n results = attempt_function_call(code,local_dict,global_dict)\n # 3. build the function\n except ValueError:\n # compile the library\n module_dir = global_dict.get('__file__',None)\n func = compile_function(code,arg_names,local_dict,\n global_dict,module_dir,\n compiler=compiler,\n verbose=verbose,\n support_code = support_code,\n customize=customize,\n type_factories = type_factories,\n auto_downcast = auto_downcast,\n **kw)\n\n function_catalog.add_function(code,func,module_dir)\n results = attempt_function_call(code,local_dict,global_dict)\n return results\n\ndef attempt_function_call(code,local_dict,global_dict):\n # we try 3 levels here -- a local cache first, then the\n # catalog cache, and then persistent catalog.\n #\n global function_cache\n # 2. try catalog cache.\n function_list = function_catalog.get_functions_fast(code)\n for func in function_list:\n try:\n results = apply(func,(local_dict,global_dict))\n function_catalog.fast_cache(code,func)\n function_cache[code] = func\n return results\n except: # should specify argument types here.\n pass\n # 3. try persistent catalog\n module_dir = global_dict.get('__file__',None)\n function_list = function_catalog.get_functions(code,module_dir)\n for func in function_list:\n try:\n results = apply(func,(local_dict,global_dict))\n function_catalog.fast_cache(code,func)\n function_cache[code] = func\n return results\n except: # should specify argument types here.\n pass\n # if we get here, the function wasn't found\n raise ValueError, 'function with correct signature not found'\n\ndef inline_function_code(code,arg_names,local_dict=None,\n global_dict=None,auto_downcast = 1,\n type_factories=None,compiler=''):\n call_frame = sys._getframe().f_back\n if local_dict is None:\n local_dict = call_frame.f_locals\n if global_dict is None:\n global_dict = call_frame.f_globals\n ext_func = inline_ext_function('compiled_func',code,arg_names,\n local_dict,global_dict,auto_downcast,\n type_factories = type_factories)\n import build_tools\n compiler = build_tools.choose_compiler(compiler)\n ext_func.set_compiler(compiler)\n return ext_func.function_code()\n\ndef compile_function(code,arg_names,local_dict,global_dict,\n module_dir,\n compiler='',\n verbose = 0,\n support_code = None,\n customize = None,\n type_factories = None,\n auto_downcast=1,\n **kw):\n # figure out where to store and what to name the extension module\n # that will contain the function.\n module_path = function_catalog.unique_module_name(code,module_dir)\n storage_dir, module_name = os.path.split(module_path)\n mod = inline_ext_module(module_name,compiler)\n\n # create the function. This relies on the auto_downcast and\n # type factories setting\n ext_func = inline_ext_function('compiled_func',code,arg_names,\n local_dict,global_dict,auto_downcast,\n type_factories = type_factories)\n mod.add_function(ext_func)\n\n # if customize (a custom_info object), then set the module customization.\n if customize:\n mod.customize = customize\n\n # add the extra \"support code\" needed by the function to the module.\n if support_code:\n mod.customize.add_support_code(support_code)\n\n # compile code in correct location, with the given compiler and verbosity\n # setting. All input keywords are passed through to distutils\n mod.compile(location=storage_dir,compiler=compiler,\n verbose=verbose, **kw)\n\n # import the module and return the function. Make sure\n # the directory where it lives is in the python path.\n try:\n sys.path.insert(0,storage_dir)\n exec 'import ' + module_name\n func = eval(module_name+'.compiled_func')\n finally:\n del sys.path[0]\n return func\n\n\ndef test1(n=1000):\n a = 2;b = 'string'\n code = \"\"\"\n int a=b.length();\n return_val = Py::new_reference_to(Py::Int(a));\n \"\"\"\n #result = inline(code,['a','b'])\n result = inline(code,['b'])\n print result\n print 'should be %d. It is ---> %d' % (len(b),result)\n import time\n t1 = time.time()\n for i in range(n):\n result = inline(code,['b'])\n #result = inline(code,['a','b'])\n t2 = time.time()\n print 'inline call(sec per call,total):', (t2 - t1) / n, t2-t1\n t1 = time.time()\n for i in range(n):\n result = len(b)\n t2 = time.time()\n print 'standard call(sec per call,total):', (t2 - t1) / n, t2-t1\n bb=[b]*n\n t1 = time.time()\n result_list = [len(b) for b in bb]\n t2 = time.time()\n print 'new fangled list thing(sec per call, total):', (t2 - t1) / n, t2-t1\ndef test2(m=1,n=1000):\n import time\n lst = ['string']*n\n code = \"\"\"\n int sum = 0;\n PyObject* raw_list = lst.ptr();\n PyObject* str;\n for(int i=0; i < lst.length(); i++)\n {\n str = PyList_GetItem(raw_list,i);\n if (!PyString_Check(str))\n {\n char msg[500];\n sprintf(msg,\"Element %d of the list is not a string\\n\", i);\n throw Py::TypeError(msg);\n }\n sum += PyString_Size(str);\n }\n return_val = Py::new_reference_to(Py::Int(sum));\n \"\"\"\n result = inline(code,['lst'])\n t1 = time.time()\n for i in range(m):\n result = inline(code,['lst'])\n t2 = time.time()\n print 'inline call(sec per call,total,result):', (t2 - t1) / n, t2-t1, result\n\n lst = ['string']*n\n code = \"\"\"\n #line 280 \"inline_expr.py\"\n int sum = 0;\n Py::String str;\n for(int i=0; i < lst.length(); i++)\n {\n str = lst[i];\n sum += str.length();\n }\n return_val = Py::new_reference_to(Py::Int(sum));\n \"\"\"\n result = inline(code,['lst'])\n t1 = time.time()\n for i in range(m):\n result = inline(code,['lst'])\n t2 = time.time()\n print 'cxx inline call(sec per call,total,result):', (t2 - t1) / n, t2-t1,result\n\n lst = ['string']*n\n t1 = time.time()\n for i in range(m):\n result = 0\n for i in lst:\n result += len(i)\n t2 = time.time()\n print 'python call(sec per call,total,result):', (t2 - t1) / n, t2-t1, result\n\n lst = ['string']*n\n t1 = time.time()\n for i in range(m):\n result = reduce(lambda x,y: x + len(y),lst[1:],len(lst[0]))\n t2 = time.time()\n print 'reduce(sec per call,total,result):', (t2 - t1) / n, t2-t1, result\n\n import operator\n lst = ['string']*n\n t1 = time.time()\n for i in range(m):\n l = map(len,lst)\n result = reduce(operator.add,l)\n t2 = time.time()\n print 'reduce2(sec per call,total,result):', (t2 - t1) / n, t2-t1, result\n\nif __name__ == '__main__':\n test2(10000,100)\n test1(100000)", "source_code_before": "# should re-write compiled functions to take a local and global dict\n# as input.\nimport sys,os\nimport ext_tools\nimport string\nfrom catalog import catalog\nimport inline_info, cxx_info\n\n# not an easy way for the user_path_list to come in here.\n# the PYTHONCOMPILED environment variable offers the most hope.\n\nfunction_catalog = catalog()\n\n\nclass inline_ext_function(ext_tools.ext_function):\n # Some specialization is needed for inline extension functions\n def function_declaration_code(self):\n code = 'static PyObject* %s(PyObject*self, PyObject* args)\\n{\\n'\n return code % self.name\n\n def template_declaration_code(self):\n code = 'template\\n' \\\n 'static PyObject* %s(PyObject*self, PyObject* args)\\n{\\n'\n return code % self.name\n\n def parse_tuple_code(self):\n \"\"\" Create code block for PyArg_ParseTuple. Variable declarations\n for all PyObjects are done also.\n\n This code got a lot uglier when I added local_dict...\n \"\"\"\n declare_return = 'PyObject *return_val = NULL;\\n' \\\n 'int exception_occured = 0;\\n' \\\n 'PyObject *py__locals = NULL;\\n' \\\n 'PyObject *py__globals = NULL;\\n'\n\n py_objects = ', '.join(self.arg_specs.py_pointers())\n if py_objects:\n declare_py_objects = 'PyObject ' + py_objects +';\\n'\n else:\n declare_py_objects = ''\n\n py_vars = ' = '.join(self.arg_specs.py_variables())\n if py_vars:\n init_values = py_vars + ' = NULL;\\n\\n'\n else:\n init_values = ''\n\n parse_tuple = 'if(!PyArg_ParseTuple(args,\"OO:compiled_func\",'\\\n '&py__locals,'\\\n '&py__globals))\\n'\\\n ' return NULL;\\n'\n\n return declare_return + declare_py_objects + \\\n init_values + parse_tuple\n\n def arg_declaration_code(self):\n arg_strings = []\n for arg in self.arg_specs:\n arg_strings.append(arg.declaration_code(inline=1))\n code = string.join(arg_strings,\"\")\n return code\n\n def arg_cleanup_code(self):\n arg_strings = []\n for arg in self.arg_specs:\n arg_strings.append(arg.cleanup_code())\n code = string.join(arg_strings,\"\")\n return code\n\n def arg_local_dict_code(self):\n arg_strings = []\n for arg in self.arg_specs:\n arg_strings.append(arg.local_dict_code())\n code = string.join(arg_strings,\"\")\n return code\n\n\n def function_code(self):\n from ext_tools import indent\n decl_code = indent(self.arg_declaration_code(),4)\n cleanup_code = indent(self.arg_cleanup_code(),4)\n function_code = indent(self.code_block,4)\n #local_dict_code = indent(self.arg_local_dict_code(),4)\n\n try_code = 'try \\n' \\\n '{ \\n' \\\n ' PyObject* raw_locals = py_to_raw_dict(' \\\n 'py__locals,\"_locals\");\\n' \\\n ' PyObject* raw_globals = py_to_raw_dict(' \\\n 'py__globals,\"_globals\");\\n' + \\\n ' /* argument conversion code */ \\n' + \\\n decl_code + \\\n ' /* inline code */ \\n' + \\\n function_code + \\\n ' /*I would like to fill in changed ' \\\n 'locals and globals here...*/ \\n' \\\n '\\n} \\n'\n catch_code = \"catch( Py::Exception& e) \\n\" \\\n \"{ \\n\" + \\\n \" return_val = Py::Null(); \\n\" \\\n \" exception_occured = 1; \\n\" \\\n \"} \\n\"\n return_code = \" /* cleanup code */ \\n\" + \\\n cleanup_code + \\\n \" if(!return_val && !exception_occured)\\n\" \\\n \" {\\n \\n\" \\\n \" Py_INCREF(Py_None); \\n\" \\\n \" return_val = Py_None; \\n\" \\\n \" }\\n \\n\" \\\n \" return return_val; \\n\" \\\n \"} \\n\"\n\n all_code = self.function_declaration_code() + \\\n indent(self.parse_tuple_code(),4) + \\\n indent(try_code,4) + \\\n indent(catch_code,4) + \\\n return_code\n\n return all_code\n\n def python_function_definition_code(self):\n args = (self.name, self.name)\n function_decls = '{\"%s\",(PyCFunction)%s , METH_VARARGS},\\n' % args\n return function_decls\n\nclass inline_ext_module(ext_tools.ext_module):\n def __init__(self,name,compiler=''):\n ext_tools.ext_module.__init__(self,name,compiler)\n self._build_information.append(inline_info.inline_info())\n\nfunction_cache = {}\ndef inline(code,arg_names,local_dict = None, global_dict = None,\n force = 0,\n compiler='',\n verbose = 0,\n support_code = None,\n customize=None,\n type_factories = None,\n auto_downcast=1,\n **kw):\n \"\"\" Inline C/C++ code within Python scripts.\n\n inline() compiles and executes C/C++ code on the fly. Variables\n in the local and global Python scope are also available in the\n C/C++ code. Values are passed to the C/C++ code by assignment\n much like variables passed are passed into a standard Python\n function. Values are returned from the C/C++ code through a\n special argument called return_val. Also, the contents of\n mutable objects can be changed within the C/C++ code and the\n changes remain after the C code exits and returns to Python.\n\n inline has quite a few options as listed below. Also, the keyword\n arguments for distutils extension modules are accepted to\n specify extra information needed for compiling.\n\n code -- string. A string of valid C++ code. It should not specify a\n return statement. Instead it should assign results that\n need to be returned to Python in the return_val.\n arg_names -- list of strings. A list of Python variable names that\n should be transferred from Python into the C/C++ code.\n local_dict -- optional. dictionary. If specified, it is a dictionary\n of values that should be used as the local scope for the\n C/C++ code. If local_dict is not specified the local\n dictionary of the calling function is used.\n global_dict -- optional. dictionary. If specified, it is a dictionary\n of values that should be used as the global scope for\n the C/C++ code. If global_dict is not specified the\n global dictionary of the calling function is used.\n force -- optional. 0 or 1. default 0. If 1, the C++ code is\n compiled every time inline is called. This is really\n only useful for debugging, and probably only useful if\n your editing support_code a lot.\n compiler -- optional. string. The name of compiler to use when\n compiling. On windows, it understands 'msvc' and 'gcc'\n as well as all the compiler names understood by\n distutils. On Unix, it'll only understand the values\n understoof by distutils. ( I should add 'gcc' though\n to this).\n\n On windows, the compiler defaults to the Microsoft C++\n compiler. If this isn't available, it looks for mingw32\n (the gcc compiler).\n\n On Unix, it'll probably use the same compiler that was\n used when compiling Python. Cygwin's behavior should be\n similar.\n verbose -- optional. 0,1, or 2. defualt 0. Speficies how much\n much information is printed during the compile phase\n of inlining code. 0 is silent (except on windows with\n msvc where it still prints some garbage). 1 informs\n you when compiling starts, finishes, and how long it\n took. 2 prints out the command lines for the compilation\n process and can be useful if your having problems\n getting code to work. Its handy for finding the name\n of the .cpp file if you need to examine it. verbose has\n no affect if the compilation isn't necessary.\n support_code -- optional. string. A string of valid C++ code declaring\n extra code that might be needed by your compiled\n function. This could be declarations of functions,\n classes, or structures.\n customize -- optional. base_info.custom_info object. An alternative\n way to specifiy support_code, headers, etc. needed by\n the function see the compiler.base_info module for more\n details. (not sure this'll be used much).\n type_factories -- optional. list of type specification factories. These\n guys are what convert Python data types to C/C++ data\n types. If you'd like to use a different set of type\n conversions than the default, specify them here. Look\n in the type conversions section of the main\n documentation for examples.\n auto_downcast -- optional. 0 or 1. default 1. This only affects\n functions that have Numeric arrays as input variables.\n Setting this to 1 will cause all floating point values\n to be cast as float instead of double if all the\n Numeric arrays are of type float. If even one of the\n arrays has type double or double complex, all\n variables maintain there standard types.\n\n Distutils keywords. These are cut and pasted from Greg Ward's\n distutils.extension.Extension class for convenience:\n\n sources : [string]\n list of source filenames, relative to the distribution root\n (where the setup script lives), in Unix form (slash-separated)\n for portability. Source files may be C, C++, SWIG (.i),\n platform-specific resource files, or whatever else is recognized\n by the \"build_ext\" command as source for a Python extension.\n Note: The module_path file is always appended to the front of this\n list\n include_dirs : [string]\n list of directories to search for C/C++ header files (in Unix\n form for portability)\n define_macros : [(name : string, value : string|None)]\n list of macros to define; each macro is defined using a 2-tuple,\n where 'value' is either the string to define it to or None to\n define it without a particular value (equivalent of \"#define\n FOO\" in source or -DFOO on Unix C compiler command line)\n undef_macros : [string]\n list of macros to undefine explicitly\n library_dirs : [string]\n list of directories to search for C/C++ libraries at link time\n libraries : [string]\n list of library names (not filenames or paths) to link against\n runtime_library_dirs : [string]\n list of directories to search for C/C++ libraries at run time\n (for shared extensions, this is when the extension is loaded)\n extra_objects : [string]\n list of extra files to link with (eg. object files not implied\n by 'sources', static library that must be explicitly specified,\n binary resource files, etc.)\n extra_compile_args : [string]\n any extra platform- and compiler-specific information to use\n when compiling the source files in 'sources'. For platforms and\n compilers where \"command line\" makes sense, this is typically a\n list of command-line arguments, but for other platforms it could\n be anything.\n extra_link_args : [string]\n any extra platform- and compiler-specific information to use\n when linking object files together to create the extension (or\n to create a new static Python interpreter). Similar\n interpretation as for 'extra_compile_args'.\n export_symbols : [string]\n list of symbols to be exported from a shared extension. Not\n used on all platforms, and not generally necessary for Python\n extensions, which typically export exactly one symbol: \"init\" +\n extension_name.\n \"\"\"\n # this grabs the local variables from the *previous* call\n # frame -- that is the locals from the function that called\n # inline.\n global function_catalog\n\n call_frame = sys._getframe().f_back\n if local_dict is None:\n local_dict = call_frame.f_locals\n if global_dict is None:\n global_dict = call_frame.f_globals\n if force:\n module_dir = global_dict.get('__file__',None)\n func = compile_function(code,arg_names,local_dict,\n global_dict,module_dir,\n compiler=compiler,\n verbose=verbose,\n support_code = support_code,\n customize=customize,\n type_factories = type_factories,\n auto_downcast = auto_downcast,\n **kw)\n\n function_catalog.add_function(code,func,module_dir)\n results = attempt_function_call(code,local_dict,global_dict)\n else:\n # 1. try local cache\n try:\n results = apply(function_cache[code],(local_dict,global_dict))\n return results\n except:\n pass\n\n # 2. try function catalog\n try:\n results = attempt_function_call(code,local_dict,global_dict)\n # 3. build the function\n except ValueError:\n # compile the library\n module_dir = global_dict.get('__file__',None)\n func = compile_function(code,arg_names,local_dict,\n global_dict,module_dir,\n compiler=compiler,\n verbose=verbose,\n support_code = support_code,\n customize=customize,\n type_factories = type_factories,\n auto_downcast = auto_downcast,\n **kw)\n\n function_catalog.add_function(code,func,module_dir)\n results = attempt_function_call(code,local_dict,global_dict)\n return results\n\ndef attempt_function_call(code,local_dict,global_dict):\n # we try 3 levels here -- a local cache first, then the\n # catalog cache, and then persistent catalog.\n #\n global function_cache\n # 2. try catalog cache.\n function_list = function_catalog.get_functions_fast(code)\n for func in function_list:\n try:\n results = apply(func,(local_dict,global_dict))\n function_catalog.fast_cache(code,func)\n function_cache[code] = func\n return results\n except: # should specify argument types here.\n pass\n # 3. try persistent catalog\n module_dir = global_dict.get('__file__',None)\n function_list = function_catalog.get_functions(code,module_dir)\n for func in function_list:\n try:\n results = apply(func,(local_dict,global_dict))\n function_catalog.fast_cache(code,func)\n function_cache[code] = func\n return results\n except: # should specify argument types here.\n pass\n # if we get here, the function wasn't found\n raise ValueError, 'function with correct signature not found'\n\ndef inline_function_code(code,arg_names,local_dict=None,\n global_dict=None,auto_downcast = 1,\n type_factories=None,compiler=''):\n call_frame = sys._getframe().f_back\n if local_dict is None:\n local_dict = call_frame.f_locals\n if global_dict is None:\n global_dict = call_frame.f_globals\n ext_func = inline_ext_function('compiled_func',code,arg_names,\n local_dict,global_dict,auto_downcast,\n type_factories = type_factories)\n import build_tools\n compiler = build_tools.choose_compiler(compiler)\n ext_func.set_compiler(compiler)\n return ext_func.function_code()\n\ndef compile_function(code,arg_names,local_dict,global_dict,\n module_dir,\n compiler='',\n verbose = 0,\n support_code = None,\n customize = None,\n type_factories = None,\n auto_downcast=1,\n **kw):\n # figure out where to store and what to name the extension module\n # that will contain the function.\n module_path = function_catalog.unique_module_name(code,module_dir)\n storage_dir, module_name = os.path.split(module_path)\n mod = inline_ext_module(module_name,compiler)\n\n # create the function. This relies on the auto_downcast and\n # type factories setting\n ext_func = inline_ext_function('compiled_func',code,arg_names,\n local_dict,global_dict,auto_downcast,\n type_factories = type_factories)\n mod.add_function(ext_func)\n\n # if customize (a custom_info object), then set the module customization.\n if customize:\n mod.customize = customize\n\n # add the extra \"support code\" needed by the function to the module.\n if support_code:\n mod.customize.add_support_code(support_code)\n\n # compile code in correct location, with the given compiler and verbosity\n # setting. All input keywords are passed through to distutils\n mod.compile(location=storage_dir,compiler=compiler,\n verbose=verbose, **kw)\n\n # import the module and return the function. Make sure\n # the directory where it lives is in the python path.\n try:\n sys.path.insert(0,storage_dir)\n exec 'import ' + module_name\n func = eval(module_name+'.compiled_func')\n finally:\n del sys.path[0]\n return func\n\n\ndef test1(n=1000):\n a = 2;b = 'string'\n code = \"\"\"\n int a=b.length();\n return_val = Py::new_reference_to(Py::Int(a));\n \"\"\"\n #result = inline(code,['a','b'])\n result = inline(code,['b'])\n print result\n print 'should be %d. It is ---> %d' % (len(b),result)\n import time\n t1 = time.time()\n for i in range(n):\n result = inline(code,['b'])\n #result = inline(code,['a','b'])\n t2 = time.time()\n print 'inline call(sec per call,total):', (t2 - t1) / n, t2-t1\n t1 = time.time()\n for i in range(n):\n result = len(b)\n t2 = time.time()\n print 'standard call(sec per call,total):', (t2 - t1) / n, t2-t1\n bb=[b]*n\n t1 = time.time()\n result_list = [len(b) for b in bb]\n t2 = time.time()\n print 'new fangled list thing(sec per call, total):', (t2 - t1) / n, t2-t1\ndef test2(m=1,n=1000):\n import time\n lst = ['string']*n\n code = \"\"\"\n int sum = 0;\n PyObject* raw_list = lst.ptr();\n PyObject* str;\n for(int i=0; i < lst.length(); i++)\n {\n str = PyList_GetItem(raw_list,i);\n if (!PyString_Check(str))\n {\n char msg[500];\n sprintf(msg,\"Element %d of the list is not a string\\n\", i);\n throw Py::TypeError(msg);\n }\n sum += PyString_Size(str);\n }\n return_val = Py::new_reference_to(Py::Int(sum));\n \"\"\"\n result = inline(code,['lst'])\n t1 = time.time()\n for i in range(m):\n result = inline(code,['lst'])\n t2 = time.time()\n print 'inline call(sec per call,total,result):', (t2 - t1) / n, t2-t1, result\n\n lst = ['string']*n\n code = \"\"\"\n #line 280 \"inline_expr.py\"\n int sum = 0;\n Py::String str;\n for(int i=0; i < lst.length(); i++)\n {\n str = lst[i];\n sum += str.length();\n }\n return_val = Py::new_reference_to(Py::Int(sum));\n \"\"\"\n result = inline(code,['lst'])\n t1 = time.time()\n for i in range(m):\n result = inline(code,['lst'])\n t2 = time.time()\n print 'cxx inline call(sec per call,total,result):', (t2 - t1) / n, t2-t1,result\n\n lst = ['string']*n\n t1 = time.time()\n for i in range(m):\n result = 0\n for i in lst:\n result += len(i)\n t2 = time.time()\n print 'python call(sec per call,total,result):', (t2 - t1) / n, t2-t1, result\n\n lst = ['string']*n\n t1 = time.time()\n for i in range(m):\n result = reduce(lambda x,y: x + len(y),lst[1:],len(lst[0]))\n t2 = time.time()\n print 'reduce(sec per call,total,result):', (t2 - t1) / n, t2-t1, result\n\n import operator\n lst = ['string']*n\n t1 = time.time()\n for i in range(m):\n l = map(len,lst)\n result = reduce(operator.add,l)\n t2 = time.time()\n print 'reduce2(sec per call,total,result):', (t2 - t1) / n, t2-t1, result\n\nif __name__ == '__main__':\n test2(10000,100)\n test1(100000)", "methods": [ { "name": "function_declaration_code", "long_name": "function_declaration_code( self )", "filename": "inline_tools.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [ "self" ], "start_line": 17, "end_line": 19, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "template_declaration_code", "long_name": "template_declaration_code( self )", "filename": "inline_tools.py", "nloc": 4, "complexity": 1, "token_count": 16, "parameters": [ "self" ], "start_line": 21, "end_line": 24, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "parse_tuple_code", "long_name": "parse_tuple_code( self )", "filename": "inline_tools.py", "nloc": 21, "complexity": 3, "token_count": 89, "parameters": [ "self" ], "start_line": 26, "end_line": 55, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 30, "top_nesting_level": 1 }, { "name": "arg_declaration_code", "long_name": "arg_declaration_code( self )", "filename": "inline_tools.py", "nloc": 6, "complexity": 2, "token_count": 41, "parameters": [ "self" ], "start_line": 57, "end_line": 62, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "arg_cleanup_code", "long_name": "arg_cleanup_code( self )", "filename": "inline_tools.py", "nloc": 6, "complexity": 2, "token_count": 38, "parameters": [ "self" ], "start_line": 64, "end_line": 69, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "arg_local_dict_code", "long_name": "arg_local_dict_code( self )", "filename": "inline_tools.py", "nloc": 6, "complexity": 2, "token_count": 38, "parameters": [ "self" ], "start_line": 71, "end_line": 76, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "function_code", "long_name": "function_code( self )", "filename": "inline_tools.py", "nloc": 38, "complexity": 1, "token_count": 148, "parameters": [ "self" ], "start_line": 79, "end_line": 120, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 42, "top_nesting_level": 1 }, { "name": "python_function_definition_code", "long_name": "python_function_definition_code( self )", "filename": "inline_tools.py", "nloc": 4, "complexity": 1, "token_count": 23, "parameters": [ "self" ], "start_line": 122, "end_line": 125, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , name , compiler = '' )", "filename": "inline_tools.py", "nloc": 3, "complexity": 1, "token_count": 35, "parameters": [ "self", "name", "compiler" ], "start_line": 128, "end_line": 130, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "inline", "long_name": "inline( code , arg_names = [ ] , local_dict = None , global_dict = None , force = 0 , compiler = '' , verbose = 0 , support_code = None , customize = None , type_factories = None , auto_downcast = 1 , ** kw )", "filename": "inline_tools.py", "nloc": 50, "complexity": 6, "token_count": 267, "parameters": [ "code", "arg_names", "local_dict", "global_dict", "force", "compiler", "verbose", "support_code", "customize", "type_factories", "auto_downcast", "kw" ], "start_line": 133, "end_line": 321, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 189, "top_nesting_level": 0 }, { "name": "attempt_function_call", "long_name": "attempt_function_call( code , local_dict , global_dict )", "filename": "inline_tools.py", "nloc": 22, "complexity": 5, "token_count": 119, "parameters": [ "code", "local_dict", "global_dict" ], "start_line": 323, "end_line": 350, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 28, "top_nesting_level": 0 }, { "name": "inline_function_code", "long_name": "inline_function_code( code , arg_names , local_dict = None , global_dict = None , auto_downcast = 1 , type_factories = None , compiler = '' )", "filename": "inline_tools.py", "nloc": 15, "complexity": 3, "token_count": 98, "parameters": [ "code", "arg_names", "local_dict", "global_dict", "auto_downcast", "type_factories", "compiler" ], "start_line": 352, "end_line": 366, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "compile_function", "long_name": "compile_function( code , arg_names , local_dict , global_dict , module_dir , compiler = '' , verbose = 0 , support_code = None , customize = None , type_factories = None , auto_downcast = 1 , ** kw )", "filename": "inline_tools.py", "nloc": 29, "complexity": 4, "token_count": 169, "parameters": [ "code", "arg_names", "local_dict", "global_dict", "module_dir", "compiler", "verbose", "support_code", "customize", "type_factories", "auto_downcast", "kw" ], "start_line": 368, "end_line": 411, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 44, "top_nesting_level": 0 }, { "name": "test1", "long_name": "test1( n = 1000 )", "filename": "inline_tools.py", "nloc": 25, "complexity": 4, "token_count": 177, "parameters": [ "n" ], "start_line": 414, "end_line": 440, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 27, "top_nesting_level": 0 }, { "name": "test2", "long_name": "test2( m = 1 , n = 1000 )", "filename": "inline_tools.py", "nloc": 66, "complexity": 7, "token_count": 348, "parameters": [ "m", "n" ], "start_line": 441, "end_line": 510, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 70, "top_nesting_level": 0 } ], "methods_before": [ { "name": "function_declaration_code", "long_name": "function_declaration_code( self )", "filename": "inline_tools.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [ "self" ], "start_line": 17, "end_line": 19, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "template_declaration_code", "long_name": "template_declaration_code( self )", "filename": "inline_tools.py", "nloc": 4, "complexity": 1, "token_count": 16, "parameters": [ "self" ], "start_line": 21, "end_line": 24, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "parse_tuple_code", "long_name": "parse_tuple_code( self )", "filename": "inline_tools.py", "nloc": 21, "complexity": 3, "token_count": 89, "parameters": [ "self" ], "start_line": 26, "end_line": 55, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 30, "top_nesting_level": 1 }, { "name": "arg_declaration_code", "long_name": "arg_declaration_code( self )", "filename": "inline_tools.py", "nloc": 6, "complexity": 2, "token_count": 41, "parameters": [ "self" ], "start_line": 57, "end_line": 62, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "arg_cleanup_code", "long_name": "arg_cleanup_code( self )", "filename": "inline_tools.py", "nloc": 6, "complexity": 2, "token_count": 38, "parameters": [ "self" ], "start_line": 64, "end_line": 69, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "arg_local_dict_code", "long_name": "arg_local_dict_code( self )", "filename": "inline_tools.py", "nloc": 6, "complexity": 2, "token_count": 38, "parameters": [ "self" ], "start_line": 71, "end_line": 76, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "function_code", "long_name": "function_code( self )", "filename": "inline_tools.py", "nloc": 38, "complexity": 1, "token_count": 148, "parameters": [ "self" ], "start_line": 79, "end_line": 120, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 42, "top_nesting_level": 1 }, { "name": "python_function_definition_code", "long_name": "python_function_definition_code( self )", "filename": "inline_tools.py", "nloc": 4, "complexity": 1, "token_count": 23, "parameters": [ "self" ], "start_line": 122, "end_line": 125, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , name , compiler = '' )", "filename": "inline_tools.py", "nloc": 3, "complexity": 1, "token_count": 35, "parameters": [ "self", "name", "compiler" ], "start_line": 128, "end_line": 130, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "inline", "long_name": "inline( code , arg_names , local_dict = None , global_dict = None , force = 0 , compiler = '' , verbose = 0 , support_code = None , customize = None , type_factories = None , auto_downcast = 1 , ** kw )", "filename": "inline_tools.py", "nloc": 50, "complexity": 6, "token_count": 264, "parameters": [ "code", "arg_names", "local_dict", "global_dict", "force", "compiler", "verbose", "support_code", "customize", "type_factories", "auto_downcast", "kw" ], "start_line": 133, "end_line": 320, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 188, "top_nesting_level": 0 }, { "name": "attempt_function_call", "long_name": "attempt_function_call( code , local_dict , global_dict )", "filename": "inline_tools.py", "nloc": 22, "complexity": 5, "token_count": 119, "parameters": [ "code", "local_dict", "global_dict" ], "start_line": 322, "end_line": 349, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 28, "top_nesting_level": 0 }, { "name": "inline_function_code", "long_name": "inline_function_code( code , arg_names , local_dict = None , global_dict = None , auto_downcast = 1 , type_factories = None , compiler = '' )", "filename": "inline_tools.py", "nloc": 15, "complexity": 3, "token_count": 98, "parameters": [ "code", "arg_names", "local_dict", "global_dict", "auto_downcast", "type_factories", "compiler" ], "start_line": 351, "end_line": 365, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "compile_function", "long_name": "compile_function( code , arg_names , local_dict , global_dict , module_dir , compiler = '' , verbose = 0 , support_code = None , customize = None , type_factories = None , auto_downcast = 1 , ** kw )", "filename": "inline_tools.py", "nloc": 29, "complexity": 4, "token_count": 169, "parameters": [ "code", "arg_names", "local_dict", "global_dict", "module_dir", "compiler", "verbose", "support_code", "customize", "type_factories", "auto_downcast", "kw" ], "start_line": 367, "end_line": 410, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 44, "top_nesting_level": 0 }, { "name": "test1", "long_name": "test1( n = 1000 )", "filename": "inline_tools.py", "nloc": 25, "complexity": 4, "token_count": 177, "parameters": [ "n" ], "start_line": 413, "end_line": 439, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 27, "top_nesting_level": 0 }, { "name": "test2", "long_name": "test2( m = 1 , n = 1000 )", "filename": "inline_tools.py", "nloc": 66, "complexity": 7, "token_count": 348, "parameters": [ "m", "n" ], "start_line": 440, "end_line": 509, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 70, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "inline", "long_name": "inline( code , arg_names = [ ] , local_dict = None , global_dict = None , force = 0 , compiler = '' , verbose = 0 , support_code = None , customize = None , type_factories = None , auto_downcast = 1 , ** kw )", "filename": "inline_tools.py", "nloc": 50, "complexity": 6, "token_count": 267, "parameters": [ "code", "arg_names", "local_dict", "global_dict", "force", "compiler", "verbose", "support_code", "customize", "type_factories", "auto_downcast", "kw" ], "start_line": 133, "end_line": 321, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 189, "top_nesting_level": 0 }, { "name": "inline", "long_name": "inline( code , arg_names , local_dict = None , global_dict = None , force = 0 , compiler = '' , verbose = 0 , support_code = None , customize = None , type_factories = None , auto_downcast = 1 , ** kw )", "filename": "inline_tools.py", "nloc": 50, "complexity": 6, "token_count": 264, "parameters": [ "code", "arg_names", "local_dict", "global_dict", "force", "compiler", "verbose", "support_code", "customize", "type_factories", "auto_downcast", "kw" ], "start_line": 133, "end_line": 320, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 188, "top_nesting_level": 0 } ], "nloc": 310, "complexity": 43, "token_count": 1691, "diff_parsed": { "added": [ "def inline(code,arg_names=[],local_dict = None, global_dict = None,", " arg_names -- optional. list of strings. A list of Python variable names", " that should be transferred from Python into the C/C++", " code. It defaults to an empty string." ], "deleted": [ "def inline(code,arg_names,local_dict = None, global_dict = None,", " arg_names -- list of strings. A list of Python variable names that", " should be transferred from Python into the C/C++ code." ] } } ] }, { "hash": "424101955d2f074aa32b21ac24bad2d767936094", "msg": "fortran extension support", "author": { "name": "Pearu Peterson", "email": "pearu.peterson@gmail.com" }, "committer": { "name": "Pearu Peterson", "email": "pearu.peterson@gmail.com" }, "author_date": "2002-01-04T08:42:56+00:00", "author_timezone": 0, "committer_date": "2002-01-04T08:42:56+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "06d067a4c9382426c8755cdcc39c3ce2ebf38706" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 284, "insertions": 190, "lines": 474, "files": 7, "dmm_unit_size": 0.803030303030303, "dmm_unit_complexity": 0.6515151515151515, "dmm_unit_interfacing": 0.0, "modified_files": [ { "old_path": "scipy_distutils/command/build.py", "new_path": "scipy_distutils/command/build.py", "filename": "build.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -8,6 +8,7 @@\n class build(old_build):\n def has_f_libraries(self):\n return self.distribution.has_f_libraries()\n+\n sub_commands = [('build_py', old_build.has_pure_modules),\n ('build_clib', old_build.has_c_libraries),\n ('build_flib', has_f_libraries), # new feature\n", "added_lines": 1, "deleted_lines": 0, "source_code": "# Need to override the build command to include building of fortran libraries\n# This class must be used as the entry for the build key in the cmdclass\n# dictionary which is given to the setup command.\n\nfrom distutils.command.build import *\nfrom distutils.command.build import build as old_build\n\nclass build(old_build):\n def has_f_libraries(self):\n return self.distribution.has_f_libraries()\n\n sub_commands = [('build_py', old_build.has_pure_modules),\n ('build_clib', old_build.has_c_libraries),\n ('build_flib', has_f_libraries), # new feature\n ('build_ext', old_build.has_ext_modules),\n ('build_scripts', old_build.has_scripts),\n ]\n", "source_code_before": "# Need to override the build command to include building of fortran libraries\n# This class must be used as the entry for the build key in the cmdclass\n# dictionary which is given to the setup command.\n\nfrom distutils.command.build import *\nfrom distutils.command.build import build as old_build\n\nclass build(old_build):\n def has_f_libraries(self):\n return self.distribution.has_f_libraries()\n sub_commands = [('build_py', old_build.has_pure_modules),\n ('build_clib', old_build.has_c_libraries),\n ('build_flib', has_f_libraries), # new feature\n ('build_ext', old_build.has_ext_modules),\n ('build_scripts', old_build.has_scripts),\n ]\n", "methods": [ { "name": "has_f_libraries", "long_name": "has_f_libraries( self )", "filename": "build.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 9, "end_line": 10, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 } ], "methods_before": [ { "name": "has_f_libraries", "long_name": "has_f_libraries( self )", "filename": "build.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 9, "end_line": 10, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 } ], "changed_methods": [], "nloc": 11, "complexity": 1, "token_count": 80, "diff_parsed": { "added": [ "" ], "deleted": [] } }, { "old_path": "scipy_distutils/command/build_ext.py", "new_path": "scipy_distutils/command/build_ext.py", "filename": "build_ext.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -1,15 +1,5 @@\n \"\"\" Modified version of build_ext that handles fortran source files and f2py \n \n- The f2py_sources() method is pretty much a copy of the swig_sources()\n- method in the standard build_ext class , but modified to use f2py. It\n- also.\n- \n- slightly_modified_standard_build_extension() is a verbatim copy of\n- the standard build_extension() method with a single line changed so that\n- preprocess_sources() is called instead of just swig_sources(). This new\n- function is a nice place to stick any source code preprocessing functions\n- needed.\n- \n build_extension() handles building any needed static fortran libraries\n first and then calls our slightly_modified_..._extenstion() to do the\n rest of the processing in the (mostly) standard way. \n@@ -23,7 +13,9 @@\n from distutils.command.build_ext import build_ext as old_build_ext\n \n class build_ext (old_build_ext):\n+\n def run (self):\n+\n if self.distribution.has_f_libraries():\n build_flib = self.get_finalized_command('build_flib')\n self.libraries.extend(build_flib.get_library_names() or [])\n@@ -36,12 +28,7 @@ def run (self):\n self.library_dirs.append(build_flib.build_flib)\n \n old_build_ext.run(self)\n-\n- def preprocess_sources(self,sources):\n- sources = self.swig_sources(sources) \n- sources = self.f2py_sources(sources)\n- return sources\n- \n+ \n def build_extension(self, ext):\n # support for building static fortran libraries\n if self.distribution.has_f_libraries():\n@@ -59,153 +46,7 @@ def build_extension(self, ext):\n if linker_so is not None:\n self.compiler.linker_so = linker_so\n # end of fortran source support\n- # f2py support handled slightly_modified..._extenstion.\n- return self.slightly_modified_standard_build_extension(ext)\n- \n- def slightly_modified_standard_build_extension(self, ext):\n- \"\"\"\n- This is pretty much a verbatim copy of the build_extension()\n- function in distutils with a single change to make it possible\n- to pre-process f2py as well as swig source files before \n- compilation.\n- \"\"\"\n- sources = ext.sources\n- if sources is None or type(sources) not in (ListType, TupleType):\n- raise DistutilsSetupError, \\\n- (\"in 'ext_modules' option (extension '%s'), \" +\n- \"'sources' must be present and must be \" +\n- \"a list of source filenames\") % ext.name\n- sources = list(sources)\n-\n- fullname = self.get_ext_fullname(ext.name)\n- if self.inplace:\n- # ignore build-lib -- put the compiled extension into\n- # the source tree along with pure Python modules\n-\n- modpath = string.split(fullname, '.')\n- package = string.join(modpath[0:-1], '.')\n- base = modpath[-1]\n-\n- build_py = self.get_finalized_command('build_py')\n- package_dir = build_py.get_package_dir(package)\n- ext_filename = os.path.join(package_dir,\n- self.get_ext_filename(base))\n- else:\n- ext_filename = os.path.join(self.build_lib,\n- self.get_ext_filename(fullname))\n-\n- if not (self.force or newer_group(sources, ext_filename, 'newer')):\n- self.announce(\"skipping '%s' extension (up-to-date)\" %\n- ext.name)\n- return\n- else:\n- self.announce(\"building '%s' extension\" % ext.name)\n-\n- # I copied this hole stinken function just to change from\n- # self.swig_sources to self.preprocess_sources...\n- sources = self.preprocess_sources(sources)\n-\n- # Next, compile the source code to object files.\n-\n- # XXX not honouring 'define_macros' or 'undef_macros' -- the\n- # CCompiler API needs to change to accommodate this, and I\n- # want to do one thing at a time!\n-\n- # Two possible sources for extra compiler arguments:\n- # - 'extra_compile_args' in Extension object\n- # - CFLAGS environment variable (not particularly\n- # elegant, but people seem to expect it and I\n- # guess it's useful)\n- # The environment variable should take precedence, and\n- # any sensible compiler will give precedence to later\n- # command line args. Hence we combine them in order:\n- extra_args = ext.extra_compile_args or []\n-\n- macros = ext.define_macros[:]\n- for undef in ext.undef_macros:\n- macros.append((undef,))\n-\n- # XXX and if we support CFLAGS, why not CC (compiler\n- # executable), CPPFLAGS (pre-processor options), and LDFLAGS\n- # (linker options) too?\n- # XXX should we use shlex to properly parse CFLAGS?\n-\n- if os.environ.has_key('CFLAGS'):\n- extra_args.extend(string.split(os.environ['CFLAGS']))\n-\n- objects = self.compiler.compile(sources,\n- output_dir=self.build_temp,\n- macros=macros,\n- include_dirs=ext.include_dirs,\n- debug=self.debug,\n- extra_postargs=extra_args)\n-\n- # Now link the object files together into a \"shared object\" --\n- # of course, first we have to figure out all the other things\n- # that go into the mix.\n- if ext.extra_objects:\n- objects.extend(ext.extra_objects)\n- extra_args = ext.extra_link_args or []\n-\n-\n- self.compiler.link_shared_object(\n- objects, ext_filename, \n- libraries=self.get_libraries(ext),\n- library_dirs=ext.library_dirs,\n- runtime_library_dirs=ext.runtime_library_dirs,\n- extra_postargs=extra_args,\n- export_symbols=self.get_export_symbols(ext), \n- debug=self.debug,\n- build_temp=self.build_temp)\n-\n- def f2py_sources (self, sources):\n-\n- \"\"\"Walk the list of source files in 'sources', looking for f2py\n- interface (.pyf) files. Run f2py on all that are found, and\n- return a modified 'sources' list with f2py source files replaced\n- by the generated C (or C++) files.\n- \"\"\"\n-\n- import f2py2e\n-\n- new_sources = []\n- f2py_sources = []\n- f2py_targets = {}\n-\n- # XXX this drops generated C/C++ files into the source tree, which\n- # is fine for developers who want to distribute the generated\n- # source -- but there should be an option to put f2py output in\n- # the temp dir.\n-\n- target_ext = 'module.c'\n-\n- for source in sources:\n- (base, ext) = os.path.splitext(source)\n- if ext == \".pyf\": # f2py interface file\n- new_sources.append(base + target_ext)\n- f2py_sources.append(source)\n- f2py_targets[source] = new_sources[-1]\n- else:\n- new_sources.append(source)\n-\n- if not f2py_sources:\n- return new_sources\n-\n- # a bit of a hack, but I think it'll work. Just include one of\n- # the fortranobject.c files that was copied into most \n- d,f = os.path.split(f2py_sources[0])\n- new_sources.append(os.path.join(d,'fortranobject.c'))\n-\n- f2py_opts = ['--no-wrap-functions', '--no-latex-doc',\n- '--no-makefile','--no-setup']\n- for source in f2py_sources:\n- target = f2py_targets[source]\n- if newer(source,target):\n- self.announce(\"f2py-ing %s to %s\" % (source, target))\n- f2py2e.run_main(f2py_opts + [source])\n-\n- return new_sources\n- # f2py_sources ()\n+ return old_build_ext.build_extension(self,ext)\n \n def get_source_files (self):\n self.check_extensions_list(self.extensions)\n", "added_lines": 4, "deleted_lines": 163, "source_code": "\"\"\" Modified version of build_ext that handles fortran source files and f2py \n\n build_extension() handles building any needed static fortran libraries\n first and then calls our slightly_modified_..._extenstion() to do the\n rest of the processing in the (mostly) standard way. \n\"\"\"\n\nimport os, string\nfrom types import *\n\nfrom distutils.dep_util import newer_group, newer\nfrom distutils.command.build_ext import *\nfrom distutils.command.build_ext import build_ext as old_build_ext\n\nclass build_ext (old_build_ext):\n\n def run (self):\n\n if self.distribution.has_f_libraries():\n build_flib = self.get_finalized_command('build_flib')\n self.libraries.extend(build_flib.get_library_names() or [])\n self.library_dirs.extend(build_flib.get_library_dirs() or [])\n #self.library_dirs.extend(build_flib.get_library_dirs() or [])\n #runtime_dirs = build_flib.get_runtime_library_dirs()\n #self.runtime_library_dirs.extend(runtime_dirs or [])\n \n #?? what is this ??\n self.library_dirs.append(build_flib.build_flib)\n \n old_build_ext.run(self)\n \n def build_extension(self, ext):\n # support for building static fortran libraries\n if self.distribution.has_f_libraries():\n build_flib = self.get_finalized_command('build_flib')\n moreargs = build_flib.fcompiler.get_extra_link_args()\n if moreargs != []: \n if ext.extra_link_args is None:\n ext.extra_link_args = moreargs\n else:\n ext.extra_link_args += moreargs\n # be sure to include fortran runtime library directory names\n runtime_dirs = build_flib.get_runtime_library_dirs()\n ext.runtime_library_dirs.extend(runtime_dirs or [])\n linker_so = build_flib.fcompiler.get_linker_so()\n if linker_so is not None:\n self.compiler.linker_so = linker_so\n # end of fortran source support\n return old_build_ext.build_extension(self,ext)\n\n def get_source_files (self):\n self.check_extensions_list(self.extensions)\n filenames = []\n\n # Get sources and any include files in the same directory.\n for ext in self.extensions:\n filenames.extend(ext.sources)\n filenames.extend(get_headers(get_directories(ext.sources)))\n\n return filenames\n", "source_code_before": "\"\"\" Modified version of build_ext that handles fortran source files and f2py \n\n The f2py_sources() method is pretty much a copy of the swig_sources()\n method in the standard build_ext class , but modified to use f2py. It\n also.\n \n slightly_modified_standard_build_extension() is a verbatim copy of\n the standard build_extension() method with a single line changed so that\n preprocess_sources() is called instead of just swig_sources(). This new\n function is a nice place to stick any source code preprocessing functions\n needed.\n \n build_extension() handles building any needed static fortran libraries\n first and then calls our slightly_modified_..._extenstion() to do the\n rest of the processing in the (mostly) standard way. \n\"\"\"\n\nimport os, string\nfrom types import *\n\nfrom distutils.dep_util import newer_group, newer\nfrom distutils.command.build_ext import *\nfrom distutils.command.build_ext import build_ext as old_build_ext\n\nclass build_ext (old_build_ext):\n def run (self):\n if self.distribution.has_f_libraries():\n build_flib = self.get_finalized_command('build_flib')\n self.libraries.extend(build_flib.get_library_names() or [])\n self.library_dirs.extend(build_flib.get_library_dirs() or [])\n #self.library_dirs.extend(build_flib.get_library_dirs() or [])\n #runtime_dirs = build_flib.get_runtime_library_dirs()\n #self.runtime_library_dirs.extend(runtime_dirs or [])\n \n #?? what is this ??\n self.library_dirs.append(build_flib.build_flib)\n \n old_build_ext.run(self)\n\n def preprocess_sources(self,sources):\n sources = self.swig_sources(sources) \n sources = self.f2py_sources(sources)\n return sources\n \n def build_extension(self, ext):\n # support for building static fortran libraries\n if self.distribution.has_f_libraries():\n build_flib = self.get_finalized_command('build_flib')\n moreargs = build_flib.fcompiler.get_extra_link_args()\n if moreargs != []: \n if ext.extra_link_args is None:\n ext.extra_link_args = moreargs\n else:\n ext.extra_link_args += moreargs\n # be sure to include fortran runtime library directory names\n runtime_dirs = build_flib.get_runtime_library_dirs()\n ext.runtime_library_dirs.extend(runtime_dirs or [])\n linker_so = build_flib.fcompiler.get_linker_so()\n if linker_so is not None:\n self.compiler.linker_so = linker_so\n # end of fortran source support\n # f2py support handled slightly_modified..._extenstion.\n return self.slightly_modified_standard_build_extension(ext)\n \n def slightly_modified_standard_build_extension(self, ext):\n \"\"\"\n This is pretty much a verbatim copy of the build_extension()\n function in distutils with a single change to make it possible\n to pre-process f2py as well as swig source files before \n compilation.\n \"\"\"\n sources = ext.sources\n if sources is None or type(sources) not in (ListType, TupleType):\n raise DistutilsSetupError, \\\n (\"in 'ext_modules' option (extension '%s'), \" +\n \"'sources' must be present and must be \" +\n \"a list of source filenames\") % ext.name\n sources = list(sources)\n\n fullname = self.get_ext_fullname(ext.name)\n if self.inplace:\n # ignore build-lib -- put the compiled extension into\n # the source tree along with pure Python modules\n\n modpath = string.split(fullname, '.')\n package = string.join(modpath[0:-1], '.')\n base = modpath[-1]\n\n build_py = self.get_finalized_command('build_py')\n package_dir = build_py.get_package_dir(package)\n ext_filename = os.path.join(package_dir,\n self.get_ext_filename(base))\n else:\n ext_filename = os.path.join(self.build_lib,\n self.get_ext_filename(fullname))\n\n if not (self.force or newer_group(sources, ext_filename, 'newer')):\n self.announce(\"skipping '%s' extension (up-to-date)\" %\n ext.name)\n return\n else:\n self.announce(\"building '%s' extension\" % ext.name)\n\n # I copied this hole stinken function just to change from\n # self.swig_sources to self.preprocess_sources...\n sources = self.preprocess_sources(sources)\n\n # Next, compile the source code to object files.\n\n # XXX not honouring 'define_macros' or 'undef_macros' -- the\n # CCompiler API needs to change to accommodate this, and I\n # want to do one thing at a time!\n\n # Two possible sources for extra compiler arguments:\n # - 'extra_compile_args' in Extension object\n # - CFLAGS environment variable (not particularly\n # elegant, but people seem to expect it and I\n # guess it's useful)\n # The environment variable should take precedence, and\n # any sensible compiler will give precedence to later\n # command line args. Hence we combine them in order:\n extra_args = ext.extra_compile_args or []\n\n macros = ext.define_macros[:]\n for undef in ext.undef_macros:\n macros.append((undef,))\n\n # XXX and if we support CFLAGS, why not CC (compiler\n # executable), CPPFLAGS (pre-processor options), and LDFLAGS\n # (linker options) too?\n # XXX should we use shlex to properly parse CFLAGS?\n\n if os.environ.has_key('CFLAGS'):\n extra_args.extend(string.split(os.environ['CFLAGS']))\n\n objects = self.compiler.compile(sources,\n output_dir=self.build_temp,\n macros=macros,\n include_dirs=ext.include_dirs,\n debug=self.debug,\n extra_postargs=extra_args)\n\n # Now link the object files together into a \"shared object\" --\n # of course, first we have to figure out all the other things\n # that go into the mix.\n if ext.extra_objects:\n objects.extend(ext.extra_objects)\n extra_args = ext.extra_link_args or []\n\n\n self.compiler.link_shared_object(\n objects, ext_filename, \n libraries=self.get_libraries(ext),\n library_dirs=ext.library_dirs,\n runtime_library_dirs=ext.runtime_library_dirs,\n extra_postargs=extra_args,\n export_symbols=self.get_export_symbols(ext), \n debug=self.debug,\n build_temp=self.build_temp)\n\n def f2py_sources (self, sources):\n\n \"\"\"Walk the list of source files in 'sources', looking for f2py\n interface (.pyf) files. Run f2py on all that are found, and\n return a modified 'sources' list with f2py source files replaced\n by the generated C (or C++) files.\n \"\"\"\n\n import f2py2e\n\n new_sources = []\n f2py_sources = []\n f2py_targets = {}\n\n # XXX this drops generated C/C++ files into the source tree, which\n # is fine for developers who want to distribute the generated\n # source -- but there should be an option to put f2py output in\n # the temp dir.\n\n target_ext = 'module.c'\n\n for source in sources:\n (base, ext) = os.path.splitext(source)\n if ext == \".pyf\": # f2py interface file\n new_sources.append(base + target_ext)\n f2py_sources.append(source)\n f2py_targets[source] = new_sources[-1]\n else:\n new_sources.append(source)\n\n if not f2py_sources:\n return new_sources\n\n # a bit of a hack, but I think it'll work. Just include one of\n # the fortranobject.c files that was copied into most \n d,f = os.path.split(f2py_sources[0])\n new_sources.append(os.path.join(d,'fortranobject.c'))\n\n f2py_opts = ['--no-wrap-functions', '--no-latex-doc',\n '--no-makefile','--no-setup']\n for source in f2py_sources:\n target = f2py_targets[source]\n if newer(source,target):\n self.announce(\"f2py-ing %s to %s\" % (source, target))\n f2py2e.run_main(f2py_opts + [source])\n\n return new_sources\n # f2py_sources ()\n\n def get_source_files (self):\n self.check_extensions_list(self.extensions)\n filenames = []\n\n # Get sources and any include files in the same directory.\n for ext in self.extensions:\n filenames.extend(ext.sources)\n filenames.extend(get_headers(get_directories(ext.sources)))\n\n return filenames\n", "methods": [ { "name": "run", "long_name": "run( self )", "filename": "build_ext.py", "nloc": 7, "complexity": 4, "token_count": 68, "parameters": [ "self" ], "start_line": 17, "end_line": 30, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 1 }, { "name": "build_extension", "long_name": "build_extension( self , ext )", "filename": "build_ext.py", "nloc": 15, "complexity": 6, "token_count": 107, "parameters": [ "self", "ext" ], "start_line": 32, "end_line": 49, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 1 }, { "name": "get_source_files", "long_name": "get_source_files( self )", "filename": "build_ext.py", "nloc": 7, "complexity": 2, "token_count": 48, "parameters": [ "self" ], "start_line": 51, "end_line": 60, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 } ], "methods_before": [ { "name": "run", "long_name": "run( self )", "filename": "build_ext.py", "nloc": 7, "complexity": 4, "token_count": 68, "parameters": [ "self" ], "start_line": 26, "end_line": 38, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "preprocess_sources", "long_name": "preprocess_sources( self , sources )", "filename": "build_ext.py", "nloc": 4, "complexity": 1, "token_count": 25, "parameters": [ "self", "sources" ], "start_line": 40, "end_line": 43, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "build_extension", "long_name": "build_extension( self , ext )", "filename": "build_ext.py", "nloc": 15, "complexity": 6, "token_count": 105, "parameters": [ "self", "ext" ], "start_line": 45, "end_line": 63, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "slightly_modified_standard_build_extension", "long_name": "slightly_modified_standard_build_extension( self , ext )", "filename": "build_ext.py", "nloc": 51, "complexity": 11, "token_count": 372, "parameters": [ "self", "ext" ], "start_line": 65, "end_line": 159, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 95, "top_nesting_level": 1 }, { "name": "f2py_sources", "long_name": "f2py_sources( self , sources )", "filename": "build_ext.py", "nloc": 26, "complexity": 6, "token_count": 171, "parameters": [ "self", "sources" ], "start_line": 161, "end_line": 207, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 47, "top_nesting_level": 1 }, { "name": "get_source_files", "long_name": "get_source_files( self )", "filename": "build_ext.py", "nloc": 7, "complexity": 2, "token_count": 48, "parameters": [ "self" ], "start_line": 210, "end_line": 219, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 } ], "changed_methods": [ { "name": "f2py_sources", "long_name": "f2py_sources( self , sources )", "filename": "build_ext.py", "nloc": 26, "complexity": 6, "token_count": 171, "parameters": [ "self", "sources" ], "start_line": 161, "end_line": 207, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 47, "top_nesting_level": 1 }, { "name": "slightly_modified_standard_build_extension", "long_name": "slightly_modified_standard_build_extension( self , ext )", "filename": "build_ext.py", "nloc": 51, "complexity": 11, "token_count": 372, "parameters": [ "self", "ext" ], "start_line": 65, "end_line": 159, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 95, "top_nesting_level": 1 }, { "name": "run", "long_name": "run( self )", "filename": "build_ext.py", "nloc": 7, "complexity": 4, "token_count": 68, "parameters": [ "self" ], "start_line": 17, "end_line": 30, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 1 }, { "name": "build_extension", "long_name": "build_extension( self , ext )", "filename": "build_ext.py", "nloc": 15, "complexity": 6, "token_count": 107, "parameters": [ "self", "ext" ], "start_line": 32, "end_line": 49, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 1 }, { "name": "preprocess_sources", "long_name": "preprocess_sources( self , sources )", "filename": "build_ext.py", "nloc": 4, "complexity": 1, "token_count": 25, "parameters": [ "self", "sources" ], "start_line": 40, "end_line": 43, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 } ], "nloc": 41, "complexity": 12, "token_count": 267, "diff_parsed": { "added": [ "", "", "", " return old_build_ext.build_extension(self,ext)" ], "deleted": [ " The f2py_sources() method is pretty much a copy of the swig_sources()", " method in the standard build_ext class , but modified to use f2py. It", " also.", "", " slightly_modified_standard_build_extension() is a verbatim copy of", " the standard build_extension() method with a single line changed so that", " preprocess_sources() is called instead of just swig_sources(). This new", " function is a nice place to stick any source code preprocessing functions", " needed.", "", "", " def preprocess_sources(self,sources):", " sources = self.swig_sources(sources)", " sources = self.f2py_sources(sources)", " return sources", "", " # f2py support handled slightly_modified..._extenstion.", " return self.slightly_modified_standard_build_extension(ext)", "", " def slightly_modified_standard_build_extension(self, ext):", " \"\"\"", " This is pretty much a verbatim copy of the build_extension()", " function in distutils with a single change to make it possible", " to pre-process f2py as well as swig source files before", " compilation.", " \"\"\"", " sources = ext.sources", " if sources is None or type(sources) not in (ListType, TupleType):", " raise DistutilsSetupError, \\", " (\"in 'ext_modules' option (extension '%s'), \" +", " \"'sources' must be present and must be \" +", " \"a list of source filenames\") % ext.name", " sources = list(sources)", "", " fullname = self.get_ext_fullname(ext.name)", " if self.inplace:", " # ignore build-lib -- put the compiled extension into", " # the source tree along with pure Python modules", "", " modpath = string.split(fullname, '.')", " package = string.join(modpath[0:-1], '.')", " base = modpath[-1]", "", " build_py = self.get_finalized_command('build_py')", " package_dir = build_py.get_package_dir(package)", " ext_filename = os.path.join(package_dir,", " self.get_ext_filename(base))", " else:", " ext_filename = os.path.join(self.build_lib,", " self.get_ext_filename(fullname))", "", " if not (self.force or newer_group(sources, ext_filename, 'newer')):", " self.announce(\"skipping '%s' extension (up-to-date)\" %", " ext.name)", " return", " else:", " self.announce(\"building '%s' extension\" % ext.name)", "", " # I copied this hole stinken function just to change from", " # self.swig_sources to self.preprocess_sources...", " sources = self.preprocess_sources(sources)", "", " # Next, compile the source code to object files.", "", " # XXX not honouring 'define_macros' or 'undef_macros' -- the", " # CCompiler API needs to change to accommodate this, and I", " # want to do one thing at a time!", "", " # Two possible sources for extra compiler arguments:", " # - 'extra_compile_args' in Extension object", " # - CFLAGS environment variable (not particularly", " # elegant, but people seem to expect it and I", " # guess it's useful)", " # The environment variable should take precedence, and", " # any sensible compiler will give precedence to later", " # command line args. Hence we combine them in order:", " extra_args = ext.extra_compile_args or []", "", " macros = ext.define_macros[:]", " for undef in ext.undef_macros:", " macros.append((undef,))", "", " # XXX and if we support CFLAGS, why not CC (compiler", " # executable), CPPFLAGS (pre-processor options), and LDFLAGS", " # (linker options) too?", " # XXX should we use shlex to properly parse CFLAGS?", "", " if os.environ.has_key('CFLAGS'):", " extra_args.extend(string.split(os.environ['CFLAGS']))", "", " objects = self.compiler.compile(sources,", " output_dir=self.build_temp,", " macros=macros,", " include_dirs=ext.include_dirs,", " debug=self.debug,", " extra_postargs=extra_args)", "", " # Now link the object files together into a \"shared object\" --", " # of course, first we have to figure out all the other things", " # that go into the mix.", " if ext.extra_objects:", " objects.extend(ext.extra_objects)", " extra_args = ext.extra_link_args or []", "", "", " self.compiler.link_shared_object(", " objects, ext_filename,", " libraries=self.get_libraries(ext),", " library_dirs=ext.library_dirs,", " runtime_library_dirs=ext.runtime_library_dirs,", " extra_postargs=extra_args,", " export_symbols=self.get_export_symbols(ext),", " debug=self.debug,", " build_temp=self.build_temp)", "", " def f2py_sources (self, sources):", "", " \"\"\"Walk the list of source files in 'sources', looking for f2py", " interface (.pyf) files. Run f2py on all that are found, and", " return a modified 'sources' list with f2py source files replaced", " by the generated C (or C++) files.", " \"\"\"", "", " import f2py2e", "", " new_sources = []", " f2py_sources = []", " f2py_targets = {}", "", " # XXX this drops generated C/C++ files into the source tree, which", " # is fine for developers who want to distribute the generated", " # source -- but there should be an option to put f2py output in", " # the temp dir.", "", " target_ext = 'module.c'", "", " for source in sources:", " (base, ext) = os.path.splitext(source)", " if ext == \".pyf\": # f2py interface file", " new_sources.append(base + target_ext)", " f2py_sources.append(source)", " f2py_targets[source] = new_sources[-1]", " else:", " new_sources.append(source)", "", " if not f2py_sources:", " return new_sources", "", " # a bit of a hack, but I think it'll work. Just include one of", " # the fortranobject.c files that was copied into most", " d,f = os.path.split(f2py_sources[0])", " new_sources.append(os.path.join(d,'fortranobject.c'))", "", " f2py_opts = ['--no-wrap-functions', '--no-latex-doc',", " '--no-makefile','--no-setup']", " for source in f2py_sources:", " target = f2py_targets[source]", " if newer(source,target):", " self.announce(\"f2py-ing %s to %s\" % (source, target))", " f2py2e.run_main(f2py_opts + [source])", "", " return new_sources", " # f2py_sources ()" ] } }, { "old_path": "scipy_distutils/command/build_flib.py", "new_path": "scipy_distutils/command/build_flib.py", "filename": "build_flib.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -125,21 +125,24 @@ def finalize_options (self):\n else:\n self.announce(' using %s Fortran compiler' % fc)\n self.fcompiler = fc\n- self.fortran_libraries = self.distribution.fortran_libraries\n- if self.fortran_libraries:\n+ if self.has_f_libraries():\n+ self.fortran_libraries = self.distribution.fortran_libraries\n self.check_library_list(self.fortran_libraries)\n \n # finalize_options()\n \n+ def has_f_libraries(self):\n+ return self.distribution.has_f_libraries()\n+\n def run (self):\n- if not self.fortran_libraries:\n+ if not self.has_f_libraries():\n return\n self.build_libraries(self.fortran_libraries)\n \n # run ()\n \n def get_library_names(self):\n- if not self.fortran_libraries:\n+ if not self.has_f_libraries():\n return None\n \n lib_names = [] \n@@ -155,7 +158,7 @@ def get_library_names(self):\n # get_library_names ()\n \n def get_library_dirs(self):\n- if not self.fortran_libraries:\n+ if not self.has_f_libraries():\n return []#None\n \n lib_dirs = [] \n@@ -168,7 +171,7 @@ def get_library_dirs(self):\n # get_library_dirs ()\n \n def get_runtime_library_dirs(self):\n- if not self.fortran_libraries:\n+ if not self.has_f_libraries():\n return []#None\n \n lib_dirs = [] \n@@ -553,8 +556,9 @@ class gnu_fortran_compiler(fortran_compiler_base):\n \n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n- self.libraries = ['gcc','g2c']\n- self.library_dirs = self.find_lib_directories()\n+ if sys.platform == 'win32':\n+ self.libraries = ['gcc','g2c']\n+ self.library_dirs = self.find_lib_directories()\n \n if fc is None:\n fc = 'g77'\n@@ -576,9 +580,9 @@ def __init__(self, fc = None, f90c = None):\n def get_opt(self):\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n- opt = ' -O3 '\n+ opt = ' -O3 -funroll-loops '\n \n- # only check for more optimizaiton if g77 can handle\n+ # only check for more optimization if g77 can handle\n # it.\n if self.get_version():\n if self.version[0]=='3': # is g77 3.x.x\n@@ -594,7 +598,8 @@ def get_opt(self):\n opt = opt + ' -march=i486 '\n elif cpu.is_i386():\n opt = opt + ' -march=i386 '\n- \n+ if cpu.is_Intel():\n+ opt = opt + ' -malign-double ' \n return opt\n \n def find_lib_directories(self):\n@@ -606,7 +611,7 @@ def find_lib_directories(self):\n if not exit_status:\n m = re.findall(match,out_text)\n if m:\n-\t\t\t\tlib_dir= m #m[0] \n+ lib_dir= m #m[0] \n return lib_dir\n \n def get_linker_so(self):\n@@ -666,8 +671,8 @@ def get_opt(self):\n opt = opt + ' -tpp5 '\n elif cpu.is_PentiumIV():\n opt = opt + ' -tpp7 -xW '\n- if cpu.has_mmx():\n- opt = opt + ' -xM ' \n+ elif cpu.has_mmx():\n+ opt = opt + ' -xM '\n return opt\n \n \n@@ -704,15 +709,17 @@ def __init__(self, fc = None, f90c = None):\n \n switches = ''\n debug = ' -g -gline -g90 -nan -C '\n- opt = ' -O4 '\n \n self.f77_switches = self.f90_switches = switches\n self.f77_switches = self.f77_switches + ' -fixed '\n self.f77_debug = self.f90_debug = debug\n- self.f77_opt = self.f90_opt = opt\n+ self.f77_opt = self.f90_opt = self.get_opt()\n \n self.ver_cmd = self.f77_compiler+' -V '\n \n+ def get_opt(self):\n+ opt = ' -O4 -target=native '\n+\n def get_linker_so(self):\n return [self.f77_compiler,'-Wl,-shared']\n \n", "added_lines": 23, "deleted_lines": 16, "source_code": "\"\"\" Implements the build_flib command which should go into Distutils\n at some point.\n \n Note:\n Right now, we're dynamically linking to the Fortran libraries on \n some platforms (Sun for sure). This is fine for local installations\n but a bad thing for redistribution because these libraries won't\n live on any machine that doesn't have a fortran compiler installed.\n It is pretty hard (impossible?) to get gcc to pass the right compiler\n flags on Sun to get the linker to use static libs for the fortran\n stuff. Investigate further...\n\nBugs:\n *** Options -e and -x have no effect when used with --help-compiler\n options. E.g. \n ./setup.py build_flib --help-compiler -e g77-3.0\n finds g77-2.95.\n How to extract these options inside the show_compilers function?\n *** Option --force has no effect when switching a compiler. One must\n manually remove .o files that were generated earlier by a\n different compiler.\n *** compiler.is_available() method may not work correctly on nt\n because of lack of knowledge how to get exit status in\n run_command function. However, it may give reasonable results\n based on a version string.\n *** Some vendors provide different compilers for F77 and F90\n compilations. Currently, checking the availability of these\n compilers is based on only checking the availability of the\n corresponding F77 compiler. If it exists, then F90 is assumed\n to exist also.\n\nOpen issues:\n *** User-defined compiler flags. Do we need --fflags?\n\nFortran compilers (as to be used with --fcompiler= option):\n Absoft\n Sun\n SGI\n Gnu\n Intel\n Itanium\n NAG\n VAST\n\"\"\"\n\nimport distutils\nimport distutils.dep_util, distutils.dir_util\nimport os,sys,string\nimport commands,re\nfrom types import *\nfrom distutils.command.build_clib import build_clib\nfrom distutils.errors import *\n\nif os.name == 'nt':\n def run_command(command):\n \"\"\" not sure how to get exit status on nt. \"\"\"\n in_pipe,out_pipe = os.popen4(command)\n in_pipe.close()\n text = out_pipe.read()\n return 0, text\nelse:\n run_command = commands.getstatusoutput\n \ndef show_compilers():\n for compiler_class in all_compilers:\n compiler = compiler_class()\n if compiler.is_available():\n print compiler\n\nclass build_flib (build_clib):\n\n description = \"build f77/f90 libraries used by Python extensions\"\n\n user_options = [\n ('build-flib', 'b',\n \"directory to build f77/f90 libraries to\"),\n ('build-temp', 't',\n \"directory to put temporary build by-products\"),\n ('debug', 'g',\n \"compile with debugging information\"),\n ('force', 'f',\n \"forcibly build everything (ignore file timestamps)\"),\n ('fcompiler=', 'c',\n \"specify the compiler type\"),\n ('fcompiler-exec=', 'e',\n \"specify the path to F77 compiler\"),\n ('f90compiler-exec=', 'x',\n \"specify the path to F90 compiler\"),\n ]\n\n boolean_options = ['debug', 'force']\n\n help_options = [\n ('help-compiler', None,\n \"list available compilers\", show_compilers),\n ]\n\n def initialize_options (self):\n\n self.build_flib = None\n self.build_temp = None\n\n self.fortran_libraries = None\n self.define = None\n self.undef = None\n self.debug = None\n self.force = 0\n self.fcompiler = None\n self.fcompiler_exec = None\n self.f90compiler_exec = None\n\n # initialize_options()\n\n def finalize_options (self):\n self.set_undefined_options('build',\n ('build_temp', 'build_flib'),\n ('build_temp', 'build_temp'),\n ('debug', 'debug'),\n ('force', 'force'))\n fc = find_fortran_compiler(self.fcompiler,\n self.fcompiler_exec,\n self.f90compiler_exec)\n if not fc:\n raise DistutilsOptionError, 'Fortran compiler not available: %s'%(self.fcompiler)\n else:\n self.announce(' using %s Fortran compiler' % fc)\n self.fcompiler = fc\n if self.has_f_libraries():\n self.fortran_libraries = self.distribution.fortran_libraries\n self.check_library_list(self.fortran_libraries)\n\n # finalize_options()\n\n def has_f_libraries(self):\n return self.distribution.has_f_libraries()\n\n def run (self):\n if not self.has_f_libraries():\n return\n self.build_libraries(self.fortran_libraries)\n\n # run ()\n\n def get_library_names(self):\n if not self.has_f_libraries():\n return None\n\n lib_names = [] \n\n for (lib_name, build_info) in self.fortran_libraries:\n lib_names.append(lib_name)\n\n if self.fcompiler is not None:\n lib_names.extend(self.fcompiler.get_libraries())\n \n return lib_names\n\n # get_library_names ()\n\n def get_library_dirs(self):\n if not self.has_f_libraries():\n return []#None\n\n lib_dirs = [] \n\n if self.fcompiler is not None:\n lib_dirs.extend(self.fcompiler.get_library_dirs())\n \n return lib_dirs\n\n # get_library_dirs ()\n\n def get_runtime_library_dirs(self):\n if not self.has_f_libraries():\n return []#None\n\n lib_dirs = [] \n\n if self.fcompiler is not None:\n lib_dirs.extend(self.fcompiler.get_runtime_library_dirs())\n \n return lib_dirs\n\n # get_library_dirs ()\n\n def get_source_files (self):\n self.check_library_list(self.fortran_libraries)\n filenames = []\n\n # Gets source files specified \n for ext in self.fortran_libraries:\n filenames.extend(ext[1]['sources'])\n\n return filenames \n \n def build_libraries (self, fortran_libraries):\n \n fcompiler = self.fcompiler\n \n for (lib_name, build_info) in fortran_libraries:\n sources = build_info.get('sources')\n if sources is None or type(sources) not in (ListType, TupleType):\n raise DistutilsSetupError, \\\n (\"in 'fortran_libraries' option (library '%s'), \" +\n \"'sources' must be present and must be \" +\n \"a list of source filenames\") % lib_name\n sources = list(sources)\n module_dirs = build_info.get('module_dirs')\n module_files = build_info.get('module_files')\n self.announce(\" building '%s' library\" % lib_name)\n \n if module_files:\n fcompiler.build_library(lib_name, module_files,\n temp_dir=self.build_temp)\n \n fcompiler.build_library(lib_name, sources,\n module_dirs, temp_dir=self.build_temp)\n\n # for loop\n\n # build_libraries ()\n\n\nclass fortran_compiler_base:\n\n vendor = None\n ver_match = None\n \n def __init__(self):\n # Default initialization. Constructors of derived classes MUST\n # call this functions.\n self.version = None\n \n self.f77_switches = ''\n self.f77_opt = ''\n self.f77_debug = ''\n \n self.f90_switches = ''\n self.f90_opt = ''\n self.f90_debug = ''\n \n self.libraries = []\n self.library_dirs = []\n\n if self.vendor is None:\n raise DistutilsInternalError,\\\n '%s must define vendor attribute'%(self.__class__)\n if self.ver_match is None:\n raise DistutilsInternalError,\\\n '%s must define ver_match attribute'%(self.__class__)\n\n def to_object(self,dirty_files,module_dirs=None, temp_dir=''):\n files = string.join(dirty_files)\n f90_files = get_f90_files(dirty_files)\n f77_files = get_f77_files(dirty_files)\n if f90_files != []:\n obj1 = self.f90_compile(f90_files,module_dirs,temp_dir = temp_dir)\n else:\n obj1 = []\n if f77_files != []:\n obj2 = self.f77_compile(f77_files, temp_dir = temp_dir)\n else:\n obj2 = []\n return obj1 + obj2\n\n def source_to_object_names(self,source_files, temp_dir=''):\n file_list = map(lambda x: os.path.basename(x),source_files)\n file_base_ext = map(lambda x: os.path.splitext(x),file_list)\n object_list = map(lambda x: x[0] +'.o',file_base_ext)\n object_files = map(lambda x,td=temp_dir: os.path.join(td,x),object_list)\n return object_files\n \n def source_and_object_pairs(self,source_files, temp_dir=''):\n object_files = self.source_to_object_names(source_files,temp_dir)\n file_pairs = zip(source_files,object_files)\n return file_pairs\n \n def f_compile(self,compiler,switches, source_files,\n module_dirs=None, temp_dir=''):\n module_switch = self.build_module_switch(module_dirs)\n file_pairs = self.source_and_object_pairs(source_files,temp_dir)\n object_files = []\n for source,object in file_pairs:\n if distutils.dep_util.newer(source,object):\n cmd = compiler + ' ' + switches + \\\n module_switch + ' -c ' + source + ' -o ' + object \n print cmd\n failure = os.system(cmd)\n if failure:\n raise ValueError, 'failure during compile' \n object_files.append(object)\n return object_files\n #return all object files to make sure everything is archived \n #return map(lambda x: x[1], file_pairs)\n\n def f90_compile(self,source_files,module_dirs=None, temp_dir=''):\n switches = string.join((self.f90_switches, self.f90_opt))\n return self.f_compile(self.f90_compiler,switches,\n source_files, module_dirs,temp_dir)\n\n def f77_compile(self,source_files,module_dirs=None, temp_dir=''):\n switches = string.join((self.f77_switches, self.f77_opt))\n return self.f_compile(self.f77_compiler,switches,\n source_files, module_dirs,temp_dir)\n\n\n def build_module_switch(self, module_dirs):\n return ''\n\n def create_static_lib(self, object_files, library_name,\n output_dir='', debug=None):\n lib_file = os.path.join(output_dir,'lib'+library_name+'.a')\n newer = distutils.dep_util.newer\n # This doesn't work -- no way to know if the file is in the archive\n #object_files = filter(lambda o,lib=lib_file:\\\n # distutils.dep_util.newer(o,lib),object_files)\n objects = string.join(object_files)\n if objects:\n cmd = 'ar -cur %s %s' % (lib_file,objects)\n print cmd\n os.system(cmd)\n\n def build_library(self,library_name,source_list,module_dirs=None,\n temp_dir = ''):\n #make sure the temp directory exists before trying to build files\n import distutils.dir_util\n distutils.dir_util.mkpath(temp_dir)\n #this compiles the files\n object_list = self.to_object(source_list,module_dirs,temp_dir)\n # actually we need to use all the object file names here to\n # make sure the library is always built. It could occur that an\n # object file exists but hasn't been put in the archive. (happens\n # a lot when builds fail once and are restarted).\n object_list = self.source_to_object_names(source_list, temp_dir)\n #self.create_static_lib(object_list,library_name,temp_dir) \n # This is pure bunk...\n # Windows fails for long argument strings on the command line.\n # if objects is real long (> 2048 chars or so on my machine),\n # the command fails (cmd.exe /e:2048 on w2k)\n # for now we'll split linking into to steps which should work for\n objects = object_list[:]\n while objects:\n obj,objects = objects[:20],objects[20:]\n self.create_static_lib(obj,library_name,temp_dir)\n\n def dummy_fortran_files(self):\n import tempfile \n d = tempfile.gettempdir()\n dummy_name = os.path.join(d,'__dummy.f')\n dummy = open(dummy_name,'w')\n dummy.write(\" subroutine dummy()\\n end\\n\")\n dummy.close()\n return (os.path.join(d,'__dummy.f'),os.path.join(d,'__dummy.o'))\n \n def is_available(self):\n return self.get_version()\n \n def get_version(self):\n \"\"\"Return the compiler version. If compiler is not available,\n return empty string.\"\"\"\n # XXX: Is there compilers that have no version? If yes,\n # this test will fail even if the compiler is available.\n if self.version is not None:\n # Finding version is expensive, so return previously found\n # version string.\n return self.version\n self.version = ''\n # works I think only for unix... \n #print 'command:', self.ver_cmd\n exit_status, out_text = run_command(self.ver_cmd)\n #print exit_status, out_text\n if not exit_status:\n m = re.match(self.ver_match,out_text)\n if m:\n self.version = m.group('version')\n return self.version\n\n def get_libraries(self):\n return self.libraries\n def get_library_dirs(self):\n return self.library_dirs\n def get_extra_link_args(self):\n return []\n def get_runtime_library_dirs(self):\n return []\n def get_linker_so(self):\n \"\"\"\n If a compiler requires specific linker then return a list\n containing a linker executable name and linker options.\n Otherwise, return None.\n \"\"\"\n\n def __str__(self):\n return \"%s %s\" % (self.vendor, self.get_version())\n\n\nclass absoft_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Absoft'\n ver_match = r'FORTRAN 77 Compiler (?P[^\\s*,]*).*?Absoft Corp'\n \n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n # got rid of -B108 cause it was generating 2 underscores instead\n # of one on the newest version. Now we use -YEXT_SFX=_ to \n # specify the output format\n if os.name == 'nt':\n self.f90_switches = '-f fixed -YCFRL=1 -YCOM_NAMES=LCS' \\\n ' -YCOM_PFX -YEXT_PFX -YEXT_NAMES=LCS' \\\n ' -YCOM_SFX=_ -YEXT_SFX=_ -YEXT_NAMES=LCS' \n self.f90_opt = '-O -Q100'\n self.f77_switches = '-N22 -N90 -N110'\n self.f77_opt = '-O -Q100'\n self.libraries = ['fio', 'fmath', 'f90math', 'COMDLG32']\n else:\n self.f90_switches = '-ffixed -YCFRL=1 -YCOM_NAMES=LCS' \\\n ' -YCOM_PFX -YEXT_PFX -YEXT_NAMES=LCS' \\\n ' -YCOM_SFX=_ -YEXT_SFX=_ -YEXT_NAMES=LCS' \n self.f90_opt = '-O -B101' \n self.f77_switches = '-N22 -N90 -N110 -B108'\n self.f77_opt = '-O -B101'\n\n self.libraries = ['fio', 'f77math', 'f90math']\n \n try:\n dir = os.environ['ABSOFT'] \n self.library_dirs = [os.path.join(dir,'lib')]\n except KeyError:\n self.library_dirs = []\n\n self.ver_cmd = self.f77_compiler + ' -V -c %s -o %s' % \\\n self.dummy_fortran_files()\n\n def build_module_switch(self,module_dirs):\n res = ''\n if module_dirs:\n for mod in module_dirs:\n res = res + ' -p' + mod\n return res\n\n def get_extra_link_args(self):\n return []\n # Couldn't get this to link for anything using gcc.\n #dr = \"c:\\\\Absoft62\\\\lib\"\n #libs = ['fio.lib', 'COMDLG32.lib','fmath.lib', 'f90math.lib','libcomdlg32.a' ] \n #libs = map(lambda x,dr=dr:os.path.join(dr,x),libs)\n #return libs\n\n\nclass sun_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Sun'\n ver_match = r'f77: (?P[^\\s*,]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc # not tested\n self.f77_switches = ' -pic '\n self.f77_opt = ' -fast -dalign '\n\n self.f90_compiler = f90c\n self.f90_switches = ' -fixed ' # ??? why fixed?\n self.f90_opt = ' -fast -dalign '\n\n self.libraries = ['f90', 'F77', 'M77', 'sunmath', 'm']\n #threaded\n #self.libraries = ['f90', 'F77_mt', 'sunmath_mt', 'm', 'thread']\n #self.libraries = []\n self.library_dirs = self.find_lib_dir()\n #print 'sun:',self.library_dirs\n\n self.ver_cmd = self.f77_compiler + ' -V'\n\n def build_module_switch(self,module_dirs):\n res = ''\n if module_dirs:\n for mod in module_dirs:\n res = res + ' -M' + mod\n return res\n\n def find_lib_dir(self):\n library_dirs = []\n lib_match = r'### f90: Note: LD_RUN_PATH\\s*= '\\\n '(?P[^\\s.]*).*'\n cmd = self.f90_compiler + ' -dryrun dummy.f'\n exit_status, output = run_command(cmd)\n if not exit_status:\n libs = re.findall(lib_match,output)\n if libs:\n library_dirs = string.split(libs[0],':')\n self.get_version() # force version calculation\n compiler_home = os.path.dirname(library_dirs[0])\n library_dirs.append(os.path.join(compiler_home,\n self.version,'lib'))\n return library_dirs\n def get_runtime_library_dirs(self):\n return self.find_lib_dir()\n def get_extra_link_args(self):\n return ['-mimpure-text']\n\n\nclass mips_fortran_compiler(fortran_compiler_base):\n\n vendor = 'SGI'\n ver_match = r'MIPSpro Compilers: Version (?P[^\\s*,]*)'\n \n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc # not tested\n self.f77_switches = ' -n32 -KPIC '\n self.f77_opt = ' -O3 '\n\n self.f90_compiler = f90c\n self.f90_switches = ' -n32 -KPIC -fixedform ' # why fixed ???\n self.f90_opt = ' ' \n \n self.libraries = ['fortran', 'ftn', 'm']\n self.library_dirs = self.find_lib_dir()\n\n self.ver_cmd = self.f77_compiler + ' -version'\n\n def build_module_switch(self,module_dirs):\n res = ''\n return res \n def find_lib_dir(self):\n library_dirs = []\n return library_dirs\n def get_runtime_library_dirs(self):\n\treturn self.find_lib_dir() \n def get_extra_link_args(self):\n\treturn []\n\n\nclass gnu_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Gnu'\n ver_match = r'g77 version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if sys.platform == 'win32':\n self.libraries = ['gcc','g2c']\n self.library_dirs = self.find_lib_directories()\n\n if fc is None:\n fc = 'g77'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n\n switches = ' -Wall -fno-second-underscore '\n\n if os.name != 'nt':\n switches = switches + ' -fpic '\n\n self.f77_switches = switches\n\n self.ver_cmd = self.f77_compiler + ' -v '\n self.f77_opt = self.get_opt()\n\n def get_opt(self):\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n opt = ' -O3 -funroll-loops '\n \n # only check for more optimization if g77 can handle\n # it.\n if self.get_version():\n if self.version[0]=='3': # is g77 3.x.x\n if cpu.is_AthlonK6():\n opt = opt + ' -march=k6 '\n elif cpu.is_AthlonK7():\n opt = opt + ' -march=athlon '\n if cpu.is_i686():\n opt = opt + ' -march=i686 '\n elif cpu.is_i586():\n opt = opt + ' -march=i586 '\n elif cpu.is_i486():\n opt = opt + ' -march=i486 '\n elif cpu.is_i386():\n opt = opt + ' -march=i386 '\n if cpu.is_Intel():\n opt = opt + ' -malign-double ' \n return opt\n \n def find_lib_directories(self):\n lib_dir = []\n match = r'Reading specs from (.*)/specs'\n\n # works I think only for unix... \n exit_status, out_text = run_command('g77 -v')\n if not exit_status:\n m = re.findall(match,out_text)\n if m:\n lib_dir= m #m[0] \n return lib_dir\n\n def get_linker_so(self):\n # win32 linking should be handled by standard linker\n if sys.platform != 'win32':\n return [self.f77_compiler,'-shared']\n \n def f90_compile(self,source_files,module_files,temp_dir=''):\n raise DistutilsExecError, 'f90 not supported by Gnu'\n\n\n#http://developer.intel.com/software/products/compilers/f50/linux/\nclass intel_ia32_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Intel' # Intel(R) Corporation \n ver_match = r'Intel\\(R\\) Fortran Compiler for 32-bit applications, Version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'ifc'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n switches = ' -KPIC '\n\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n if cpu.has_fdiv_bug():\n switches = switches + ' -fdiv_check '\n if cpu.has_f00f_bug():\n switches = switches + ' -0f_check '\n self.f77_switches = self.f90_switches = switches\n self.f77_switches = self.f77_switches + ' -FI '\n\n self.f77_opt = self.f90_opt = self.get_opt()\n \n debug = ' -g -C '\n self.f77_debug = self.f90_debug = debug\n\n self.ver_cmd = self.f77_compiler+' -FI -V -c %s -o %s' %\\\n self.dummy_fortran_files()\n\n def get_opt(self):\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n opt = ' -O3 '\n if cpu.is_PentiumPro() or cpu.is_PentiumII():\n opt = opt + ' -tpp6 -xi '\n elif cpu.is_PentiumIII():\n opt = opt + ' -tpp6 '\n elif cpu.is_Pentium():\n opt = opt + ' -tpp5 '\n elif cpu.is_PentiumIV():\n opt = opt + ' -tpp7 -xW '\n elif cpu.has_mmx():\n opt = opt + ' -xM '\n return opt\n \n\n def get_linker_so(self):\n return [self.f77_compiler,'-shared']\n\n\nclass intel_itanium_fortran_compiler(intel_ia32_fortran_compiler):\n\n vendor = 'Itanium'\n ver_match = r'Intel\\(R\\) Fortran 90 Compiler Itanium\\(TM\\) Compiler for the Itanium\\(TM\\)-based applications, Version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n if fc is None:\n fc = 'efc'\n intel_ia32_fortran_compiler.__init__(self, fc, f90c)\n\n\nclass nag_fortran_compiler(fortran_compiler_base):\n\n vendor = 'NAG'\n ver_match = r'NAGWare Fortran 95 compiler Release (?P[^\\s]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'f95'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n switches = ''\n debug = ' -g -gline -g90 -nan -C '\n\n self.f77_switches = self.f90_switches = switches\n self.f77_switches = self.f77_switches + ' -fixed '\n self.f77_debug = self.f90_debug = debug\n self.f77_opt = self.f90_opt = self.get_opt()\n\n self.ver_cmd = self.f77_compiler+' -V '\n\n def get_opt(self):\n opt = ' -O4 -target=native '\n\n def get_linker_so(self):\n return [self.f77_compiler,'-Wl,-shared']\n\n\nclass vast_fortran_compiler(fortran_compiler_base):\n\n vendor = 'VAST'\n ver_match = r'\\s*Pacific-Sierra Research vf90 (Personal|Professional)\\s+(?P[^\\s]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'g77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n d,b = os.path.split(f90c)\n vf90 = os.path.join(d,'v'+b)\n self.ver_cmd = vf90+' -v '\n\n gnu = gnu_fortran_compiler(fc)\n if not gnu.is_available(): # VAST compiler requires g77.\n self.version = ''\n return\n if not self.is_available():\n return\n\n self.f77_switches = gnu.f77_switches\n self.f77_debug = gnu.f77_debug\n self.f77_opt = gnu.f77_opt \n\n # XXX: need f90 switches, debug, opt\n\n def get_linker_so(self):\n return [self.f90_compiler,'-shared']\n\n\ndef match_extension(files,ext):\n match = re.compile(r'.*[.]('+ext+r')\\Z',re.I).match\n return filter(lambda x,match = match: match(x),files)\n\ndef get_f77_files(files):\n return match_extension(files,'for|f77|ftn|f')\n\ndef get_f90_files(files):\n return match_extension(files,'f90|f95')\n\ndef get_fortran_files(files):\n return match_extension(files,'f90|f95|for|f77|ftn|f')\n\ndef find_fortran_compiler(vendor = None, fc = None, f90c = None):\n fcompiler = None\n for compiler_class in all_compilers:\n if vendor is not None and vendor != compiler_class.vendor:\n continue\n print compiler_class\n compiler = compiler_class(fc,f90c)\n if compiler.is_available():\n fcompiler = compiler\n break\n return fcompiler\n\nall_compilers = [absoft_fortran_compiler,\n mips_fortran_compiler,\n sun_fortran_compiler,\n gnu_fortran_compiler,\n intel_ia32_fortran_compiler,\n intel_itanium_fortran_compiler,\n nag_fortran_compiler,\n vast_fortran_compiler,\n ]\n\nif __name__ == \"__main__\":\n show_compilers()\n", "source_code_before": "\"\"\" Implements the build_flib command which should go into Distutils\n at some point.\n \n Note:\n Right now, we're dynamically linking to the Fortran libraries on \n some platforms (Sun for sure). This is fine for local installations\n but a bad thing for redistribution because these libraries won't\n live on any machine that doesn't have a fortran compiler installed.\n It is pretty hard (impossible?) to get gcc to pass the right compiler\n flags on Sun to get the linker to use static libs for the fortran\n stuff. Investigate further...\n\nBugs:\n *** Options -e and -x have no effect when used with --help-compiler\n options. E.g. \n ./setup.py build_flib --help-compiler -e g77-3.0\n finds g77-2.95.\n How to extract these options inside the show_compilers function?\n *** Option --force has no effect when switching a compiler. One must\n manually remove .o files that were generated earlier by a\n different compiler.\n *** compiler.is_available() method may not work correctly on nt\n because of lack of knowledge how to get exit status in\n run_command function. However, it may give reasonable results\n based on a version string.\n *** Some vendors provide different compilers for F77 and F90\n compilations. Currently, checking the availability of these\n compilers is based on only checking the availability of the\n corresponding F77 compiler. If it exists, then F90 is assumed\n to exist also.\n\nOpen issues:\n *** User-defined compiler flags. Do we need --fflags?\n\nFortran compilers (as to be used with --fcompiler= option):\n Absoft\n Sun\n SGI\n Gnu\n Intel\n Itanium\n NAG\n VAST\n\"\"\"\n\nimport distutils\nimport distutils.dep_util, distutils.dir_util\nimport os,sys,string\nimport commands,re\nfrom types import *\nfrom distutils.command.build_clib import build_clib\nfrom distutils.errors import *\n\nif os.name == 'nt':\n def run_command(command):\n \"\"\" not sure how to get exit status on nt. \"\"\"\n in_pipe,out_pipe = os.popen4(command)\n in_pipe.close()\n text = out_pipe.read()\n return 0, text\nelse:\n run_command = commands.getstatusoutput\n \ndef show_compilers():\n for compiler_class in all_compilers:\n compiler = compiler_class()\n if compiler.is_available():\n print compiler\n\nclass build_flib (build_clib):\n\n description = \"build f77/f90 libraries used by Python extensions\"\n\n user_options = [\n ('build-flib', 'b',\n \"directory to build f77/f90 libraries to\"),\n ('build-temp', 't',\n \"directory to put temporary build by-products\"),\n ('debug', 'g',\n \"compile with debugging information\"),\n ('force', 'f',\n \"forcibly build everything (ignore file timestamps)\"),\n ('fcompiler=', 'c',\n \"specify the compiler type\"),\n ('fcompiler-exec=', 'e',\n \"specify the path to F77 compiler\"),\n ('f90compiler-exec=', 'x',\n \"specify the path to F90 compiler\"),\n ]\n\n boolean_options = ['debug', 'force']\n\n help_options = [\n ('help-compiler', None,\n \"list available compilers\", show_compilers),\n ]\n\n def initialize_options (self):\n\n self.build_flib = None\n self.build_temp = None\n\n self.fortran_libraries = None\n self.define = None\n self.undef = None\n self.debug = None\n self.force = 0\n self.fcompiler = None\n self.fcompiler_exec = None\n self.f90compiler_exec = None\n\n # initialize_options()\n\n def finalize_options (self):\n self.set_undefined_options('build',\n ('build_temp', 'build_flib'),\n ('build_temp', 'build_temp'),\n ('debug', 'debug'),\n ('force', 'force'))\n fc = find_fortran_compiler(self.fcompiler,\n self.fcompiler_exec,\n self.f90compiler_exec)\n if not fc:\n raise DistutilsOptionError, 'Fortran compiler not available: %s'%(self.fcompiler)\n else:\n self.announce(' using %s Fortran compiler' % fc)\n self.fcompiler = fc\n self.fortran_libraries = self.distribution.fortran_libraries\n if self.fortran_libraries:\n self.check_library_list(self.fortran_libraries)\n\n # finalize_options()\n\n def run (self):\n if not self.fortran_libraries:\n return\n self.build_libraries(self.fortran_libraries)\n\n # run ()\n\n def get_library_names(self):\n if not self.fortran_libraries:\n return None\n\n lib_names = [] \n\n for (lib_name, build_info) in self.fortran_libraries:\n lib_names.append(lib_name)\n\n if self.fcompiler is not None:\n lib_names.extend(self.fcompiler.get_libraries())\n \n return lib_names\n\n # get_library_names ()\n\n def get_library_dirs(self):\n if not self.fortran_libraries:\n return []#None\n\n lib_dirs = [] \n\n if self.fcompiler is not None:\n lib_dirs.extend(self.fcompiler.get_library_dirs())\n \n return lib_dirs\n\n # get_library_dirs ()\n\n def get_runtime_library_dirs(self):\n if not self.fortran_libraries:\n return []#None\n\n lib_dirs = [] \n\n if self.fcompiler is not None:\n lib_dirs.extend(self.fcompiler.get_runtime_library_dirs())\n \n return lib_dirs\n\n # get_library_dirs ()\n\n def get_source_files (self):\n self.check_library_list(self.fortran_libraries)\n filenames = []\n\n # Gets source files specified \n for ext in self.fortran_libraries:\n filenames.extend(ext[1]['sources'])\n\n return filenames \n \n def build_libraries (self, fortran_libraries):\n \n fcompiler = self.fcompiler\n \n for (lib_name, build_info) in fortran_libraries:\n sources = build_info.get('sources')\n if sources is None or type(sources) not in (ListType, TupleType):\n raise DistutilsSetupError, \\\n (\"in 'fortran_libraries' option (library '%s'), \" +\n \"'sources' must be present and must be \" +\n \"a list of source filenames\") % lib_name\n sources = list(sources)\n module_dirs = build_info.get('module_dirs')\n module_files = build_info.get('module_files')\n self.announce(\" building '%s' library\" % lib_name)\n \n if module_files:\n fcompiler.build_library(lib_name, module_files,\n temp_dir=self.build_temp)\n \n fcompiler.build_library(lib_name, sources,\n module_dirs, temp_dir=self.build_temp)\n\n # for loop\n\n # build_libraries ()\n\n\nclass fortran_compiler_base:\n\n vendor = None\n ver_match = None\n \n def __init__(self):\n # Default initialization. Constructors of derived classes MUST\n # call this functions.\n self.version = None\n \n self.f77_switches = ''\n self.f77_opt = ''\n self.f77_debug = ''\n \n self.f90_switches = ''\n self.f90_opt = ''\n self.f90_debug = ''\n \n self.libraries = []\n self.library_dirs = []\n\n if self.vendor is None:\n raise DistutilsInternalError,\\\n '%s must define vendor attribute'%(self.__class__)\n if self.ver_match is None:\n raise DistutilsInternalError,\\\n '%s must define ver_match attribute'%(self.__class__)\n\n def to_object(self,dirty_files,module_dirs=None, temp_dir=''):\n files = string.join(dirty_files)\n f90_files = get_f90_files(dirty_files)\n f77_files = get_f77_files(dirty_files)\n if f90_files != []:\n obj1 = self.f90_compile(f90_files,module_dirs,temp_dir = temp_dir)\n else:\n obj1 = []\n if f77_files != []:\n obj2 = self.f77_compile(f77_files, temp_dir = temp_dir)\n else:\n obj2 = []\n return obj1 + obj2\n\n def source_to_object_names(self,source_files, temp_dir=''):\n file_list = map(lambda x: os.path.basename(x),source_files)\n file_base_ext = map(lambda x: os.path.splitext(x),file_list)\n object_list = map(lambda x: x[0] +'.o',file_base_ext)\n object_files = map(lambda x,td=temp_dir: os.path.join(td,x),object_list)\n return object_files\n \n def source_and_object_pairs(self,source_files, temp_dir=''):\n object_files = self.source_to_object_names(source_files,temp_dir)\n file_pairs = zip(source_files,object_files)\n return file_pairs\n \n def f_compile(self,compiler,switches, source_files,\n module_dirs=None, temp_dir=''):\n module_switch = self.build_module_switch(module_dirs)\n file_pairs = self.source_and_object_pairs(source_files,temp_dir)\n object_files = []\n for source,object in file_pairs:\n if distutils.dep_util.newer(source,object):\n cmd = compiler + ' ' + switches + \\\n module_switch + ' -c ' + source + ' -o ' + object \n print cmd\n failure = os.system(cmd)\n if failure:\n raise ValueError, 'failure during compile' \n object_files.append(object)\n return object_files\n #return all object files to make sure everything is archived \n #return map(lambda x: x[1], file_pairs)\n\n def f90_compile(self,source_files,module_dirs=None, temp_dir=''):\n switches = string.join((self.f90_switches, self.f90_opt))\n return self.f_compile(self.f90_compiler,switches,\n source_files, module_dirs,temp_dir)\n\n def f77_compile(self,source_files,module_dirs=None, temp_dir=''):\n switches = string.join((self.f77_switches, self.f77_opt))\n return self.f_compile(self.f77_compiler,switches,\n source_files, module_dirs,temp_dir)\n\n\n def build_module_switch(self, module_dirs):\n return ''\n\n def create_static_lib(self, object_files, library_name,\n output_dir='', debug=None):\n lib_file = os.path.join(output_dir,'lib'+library_name+'.a')\n newer = distutils.dep_util.newer\n # This doesn't work -- no way to know if the file is in the archive\n #object_files = filter(lambda o,lib=lib_file:\\\n # distutils.dep_util.newer(o,lib),object_files)\n objects = string.join(object_files)\n if objects:\n cmd = 'ar -cur %s %s' % (lib_file,objects)\n print cmd\n os.system(cmd)\n\n def build_library(self,library_name,source_list,module_dirs=None,\n temp_dir = ''):\n #make sure the temp directory exists before trying to build files\n import distutils.dir_util\n distutils.dir_util.mkpath(temp_dir)\n #this compiles the files\n object_list = self.to_object(source_list,module_dirs,temp_dir)\n # actually we need to use all the object file names here to\n # make sure the library is always built. It could occur that an\n # object file exists but hasn't been put in the archive. (happens\n # a lot when builds fail once and are restarted).\n object_list = self.source_to_object_names(source_list, temp_dir)\n #self.create_static_lib(object_list,library_name,temp_dir) \n # This is pure bunk...\n # Windows fails for long argument strings on the command line.\n # if objects is real long (> 2048 chars or so on my machine),\n # the command fails (cmd.exe /e:2048 on w2k)\n # for now we'll split linking into to steps which should work for\n objects = object_list[:]\n while objects:\n obj,objects = objects[:20],objects[20:]\n self.create_static_lib(obj,library_name,temp_dir)\n\n def dummy_fortran_files(self):\n import tempfile \n d = tempfile.gettempdir()\n dummy_name = os.path.join(d,'__dummy.f')\n dummy = open(dummy_name,'w')\n dummy.write(\" subroutine dummy()\\n end\\n\")\n dummy.close()\n return (os.path.join(d,'__dummy.f'),os.path.join(d,'__dummy.o'))\n \n def is_available(self):\n return self.get_version()\n \n def get_version(self):\n \"\"\"Return the compiler version. If compiler is not available,\n return empty string.\"\"\"\n # XXX: Is there compilers that have no version? If yes,\n # this test will fail even if the compiler is available.\n if self.version is not None:\n # Finding version is expensive, so return previously found\n # version string.\n return self.version\n self.version = ''\n # works I think only for unix... \n #print 'command:', self.ver_cmd\n exit_status, out_text = run_command(self.ver_cmd)\n #print exit_status, out_text\n if not exit_status:\n m = re.match(self.ver_match,out_text)\n if m:\n self.version = m.group('version')\n return self.version\n\n def get_libraries(self):\n return self.libraries\n def get_library_dirs(self):\n return self.library_dirs\n def get_extra_link_args(self):\n return []\n def get_runtime_library_dirs(self):\n return []\n def get_linker_so(self):\n \"\"\"\n If a compiler requires specific linker then return a list\n containing a linker executable name and linker options.\n Otherwise, return None.\n \"\"\"\n\n def __str__(self):\n return \"%s %s\" % (self.vendor, self.get_version())\n\n\nclass absoft_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Absoft'\n ver_match = r'FORTRAN 77 Compiler (?P[^\\s*,]*).*?Absoft Corp'\n \n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n # got rid of -B108 cause it was generating 2 underscores instead\n # of one on the newest version. Now we use -YEXT_SFX=_ to \n # specify the output format\n if os.name == 'nt':\n self.f90_switches = '-f fixed -YCFRL=1 -YCOM_NAMES=LCS' \\\n ' -YCOM_PFX -YEXT_PFX -YEXT_NAMES=LCS' \\\n ' -YCOM_SFX=_ -YEXT_SFX=_ -YEXT_NAMES=LCS' \n self.f90_opt = '-O -Q100'\n self.f77_switches = '-N22 -N90 -N110'\n self.f77_opt = '-O -Q100'\n self.libraries = ['fio', 'fmath', 'f90math', 'COMDLG32']\n else:\n self.f90_switches = '-ffixed -YCFRL=1 -YCOM_NAMES=LCS' \\\n ' -YCOM_PFX -YEXT_PFX -YEXT_NAMES=LCS' \\\n ' -YCOM_SFX=_ -YEXT_SFX=_ -YEXT_NAMES=LCS' \n self.f90_opt = '-O -B101' \n self.f77_switches = '-N22 -N90 -N110 -B108'\n self.f77_opt = '-O -B101'\n\n self.libraries = ['fio', 'f77math', 'f90math']\n \n try:\n dir = os.environ['ABSOFT'] \n self.library_dirs = [os.path.join(dir,'lib')]\n except KeyError:\n self.library_dirs = []\n\n self.ver_cmd = self.f77_compiler + ' -V -c %s -o %s' % \\\n self.dummy_fortran_files()\n\n def build_module_switch(self,module_dirs):\n res = ''\n if module_dirs:\n for mod in module_dirs:\n res = res + ' -p' + mod\n return res\n\n def get_extra_link_args(self):\n return []\n # Couldn't get this to link for anything using gcc.\n #dr = \"c:\\\\Absoft62\\\\lib\"\n #libs = ['fio.lib', 'COMDLG32.lib','fmath.lib', 'f90math.lib','libcomdlg32.a' ] \n #libs = map(lambda x,dr=dr:os.path.join(dr,x),libs)\n #return libs\n\n\nclass sun_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Sun'\n ver_match = r'f77: (?P[^\\s*,]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc # not tested\n self.f77_switches = ' -pic '\n self.f77_opt = ' -fast -dalign '\n\n self.f90_compiler = f90c\n self.f90_switches = ' -fixed ' # ??? why fixed?\n self.f90_opt = ' -fast -dalign '\n\n self.libraries = ['f90', 'F77', 'M77', 'sunmath', 'm']\n #threaded\n #self.libraries = ['f90', 'F77_mt', 'sunmath_mt', 'm', 'thread']\n #self.libraries = []\n self.library_dirs = self.find_lib_dir()\n #print 'sun:',self.library_dirs\n\n self.ver_cmd = self.f77_compiler + ' -V'\n\n def build_module_switch(self,module_dirs):\n res = ''\n if module_dirs:\n for mod in module_dirs:\n res = res + ' -M' + mod\n return res\n\n def find_lib_dir(self):\n library_dirs = []\n lib_match = r'### f90: Note: LD_RUN_PATH\\s*= '\\\n '(?P[^\\s.]*).*'\n cmd = self.f90_compiler + ' -dryrun dummy.f'\n exit_status, output = run_command(cmd)\n if not exit_status:\n libs = re.findall(lib_match,output)\n if libs:\n library_dirs = string.split(libs[0],':')\n self.get_version() # force version calculation\n compiler_home = os.path.dirname(library_dirs[0])\n library_dirs.append(os.path.join(compiler_home,\n self.version,'lib'))\n return library_dirs\n def get_runtime_library_dirs(self):\n return self.find_lib_dir()\n def get_extra_link_args(self):\n return ['-mimpure-text']\n\n\nclass mips_fortran_compiler(fortran_compiler_base):\n\n vendor = 'SGI'\n ver_match = r'MIPSpro Compilers: Version (?P[^\\s*,]*)'\n \n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc # not tested\n self.f77_switches = ' -n32 -KPIC '\n self.f77_opt = ' -O3 '\n\n self.f90_compiler = f90c\n self.f90_switches = ' -n32 -KPIC -fixedform ' # why fixed ???\n self.f90_opt = ' ' \n \n self.libraries = ['fortran', 'ftn', 'm']\n self.library_dirs = self.find_lib_dir()\n\n self.ver_cmd = self.f77_compiler + ' -version'\n\n def build_module_switch(self,module_dirs):\n res = ''\n return res \n def find_lib_dir(self):\n library_dirs = []\n return library_dirs\n def get_runtime_library_dirs(self):\n\treturn self.find_lib_dir() \n def get_extra_link_args(self):\n\treturn []\n\n\nclass gnu_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Gnu'\n ver_match = r'g77 version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n self.libraries = ['gcc','g2c']\n self.library_dirs = self.find_lib_directories()\n\n if fc is None:\n fc = 'g77'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n\n switches = ' -Wall -fno-second-underscore '\n\n if os.name != 'nt':\n switches = switches + ' -fpic '\n\n self.f77_switches = switches\n\n self.ver_cmd = self.f77_compiler + ' -v '\n self.f77_opt = self.get_opt()\n\n def get_opt(self):\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n opt = ' -O3 '\n \n # only check for more optimizaiton if g77 can handle\n # it.\n if self.get_version():\n if self.version[0]=='3': # is g77 3.x.x\n if cpu.is_AthlonK6():\n opt = opt + ' -march=k6 '\n elif cpu.is_AthlonK7():\n opt = opt + ' -march=athlon '\n if cpu.is_i686():\n opt = opt + ' -march=i686 '\n elif cpu.is_i586():\n opt = opt + ' -march=i586 '\n elif cpu.is_i486():\n opt = opt + ' -march=i486 '\n elif cpu.is_i386():\n opt = opt + ' -march=i386 '\n \n return opt\n \n def find_lib_directories(self):\n lib_dir = []\n match = r'Reading specs from (.*)/specs'\n\n # works I think only for unix... \n exit_status, out_text = run_command('g77 -v')\n if not exit_status:\n m = re.findall(match,out_text)\n if m:\n\t\t\t\tlib_dir= m #m[0] \n return lib_dir\n\n def get_linker_so(self):\n # win32 linking should be handled by standard linker\n if sys.platform != 'win32':\n return [self.f77_compiler,'-shared']\n \n def f90_compile(self,source_files,module_files,temp_dir=''):\n raise DistutilsExecError, 'f90 not supported by Gnu'\n\n\n#http://developer.intel.com/software/products/compilers/f50/linux/\nclass intel_ia32_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Intel' # Intel(R) Corporation \n ver_match = r'Intel\\(R\\) Fortran Compiler for 32-bit applications, Version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'ifc'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n switches = ' -KPIC '\n\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n if cpu.has_fdiv_bug():\n switches = switches + ' -fdiv_check '\n if cpu.has_f00f_bug():\n switches = switches + ' -0f_check '\n self.f77_switches = self.f90_switches = switches\n self.f77_switches = self.f77_switches + ' -FI '\n\n self.f77_opt = self.f90_opt = self.get_opt()\n \n debug = ' -g -C '\n self.f77_debug = self.f90_debug = debug\n\n self.ver_cmd = self.f77_compiler+' -FI -V -c %s -o %s' %\\\n self.dummy_fortran_files()\n\n def get_opt(self):\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n opt = ' -O3 '\n if cpu.is_PentiumPro() or cpu.is_PentiumII():\n opt = opt + ' -tpp6 -xi '\n elif cpu.is_PentiumIII():\n opt = opt + ' -tpp6 '\n elif cpu.is_Pentium():\n opt = opt + ' -tpp5 '\n elif cpu.is_PentiumIV():\n opt = opt + ' -tpp7 -xW '\n if cpu.has_mmx():\n opt = opt + ' -xM ' \n return opt\n \n\n def get_linker_so(self):\n return [self.f77_compiler,'-shared']\n\n\nclass intel_itanium_fortran_compiler(intel_ia32_fortran_compiler):\n\n vendor = 'Itanium'\n ver_match = r'Intel\\(R\\) Fortran 90 Compiler Itanium\\(TM\\) Compiler for the Itanium\\(TM\\)-based applications, Version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n if fc is None:\n fc = 'efc'\n intel_ia32_fortran_compiler.__init__(self, fc, f90c)\n\n\nclass nag_fortran_compiler(fortran_compiler_base):\n\n vendor = 'NAG'\n ver_match = r'NAGWare Fortran 95 compiler Release (?P[^\\s]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'f95'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n switches = ''\n debug = ' -g -gline -g90 -nan -C '\n opt = ' -O4 '\n\n self.f77_switches = self.f90_switches = switches\n self.f77_switches = self.f77_switches + ' -fixed '\n self.f77_debug = self.f90_debug = debug\n self.f77_opt = self.f90_opt = opt\n\n self.ver_cmd = self.f77_compiler+' -V '\n\n def get_linker_so(self):\n return [self.f77_compiler,'-Wl,-shared']\n\n\nclass vast_fortran_compiler(fortran_compiler_base):\n\n vendor = 'VAST'\n ver_match = r'\\s*Pacific-Sierra Research vf90 (Personal|Professional)\\s+(?P[^\\s]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'g77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n d,b = os.path.split(f90c)\n vf90 = os.path.join(d,'v'+b)\n self.ver_cmd = vf90+' -v '\n\n gnu = gnu_fortran_compiler(fc)\n if not gnu.is_available(): # VAST compiler requires g77.\n self.version = ''\n return\n if not self.is_available():\n return\n\n self.f77_switches = gnu.f77_switches\n self.f77_debug = gnu.f77_debug\n self.f77_opt = gnu.f77_opt \n\n # XXX: need f90 switches, debug, opt\n\n def get_linker_so(self):\n return [self.f90_compiler,'-shared']\n\n\ndef match_extension(files,ext):\n match = re.compile(r'.*[.]('+ext+r')\\Z',re.I).match\n return filter(lambda x,match = match: match(x),files)\n\ndef get_f77_files(files):\n return match_extension(files,'for|f77|ftn|f')\n\ndef get_f90_files(files):\n return match_extension(files,'f90|f95')\n\ndef get_fortran_files(files):\n return match_extension(files,'f90|f95|for|f77|ftn|f')\n\ndef find_fortran_compiler(vendor = None, fc = None, f90c = None):\n fcompiler = None\n for compiler_class in all_compilers:\n if vendor is not None and vendor != compiler_class.vendor:\n continue\n print compiler_class\n compiler = compiler_class(fc,f90c)\n if compiler.is_available():\n fcompiler = compiler\n break\n return fcompiler\n\nall_compilers = [absoft_fortran_compiler,\n mips_fortran_compiler,\n sun_fortran_compiler,\n gnu_fortran_compiler,\n intel_ia32_fortran_compiler,\n intel_itanium_fortran_compiler,\n nag_fortran_compiler,\n vast_fortran_compiler,\n ]\n\nif __name__ == \"__main__\":\n show_compilers()\n", "methods": [ { "name": "run_command", "long_name": "run_command( command )", "filename": "build_flib.py", "nloc": 5, "complexity": 1, "token_count": 32, "parameters": [ "command" ], "start_line": 55, "end_line": 60, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "show_compilers", "long_name": "show_compilers( )", "filename": "build_flib.py", "nloc": 5, "complexity": 3, "token_count": 23, "parameters": [], "start_line": 64, "end_line": 68, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 }, { "name": "initialize_options", "long_name": "initialize_options( self )", "filename": "build_flib.py", "nloc": 11, "complexity": 1, "token_count": 55, "parameters": [ "self" ], "start_line": 98, "end_line": 110, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "finalize_options", "long_name": "finalize_options( self )", "filename": "build_flib.py", "nloc": 17, "complexity": 3, "token_count": 104, "parameters": [ "self" ], "start_line": 114, "end_line": 130, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 1 }, { "name": "has_f_libraries", "long_name": "has_f_libraries( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 134, "end_line": 135, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "run", "long_name": "run( self )", "filename": "build_flib.py", "nloc": 4, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 137, "end_line": 140, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "get_library_names", "long_name": "get_library_names( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 4, "token_count": 58, "parameters": [ "self" ], "start_line": 144, "end_line": 156, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "get_library_dirs", "long_name": "get_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 42, "parameters": [ "self" ], "start_line": 160, "end_line": 169, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 42, "parameters": [ "self" ], "start_line": 173, "end_line": 182, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_source_files", "long_name": "get_source_files( self )", "filename": "build_flib.py", "nloc": 6, "complexity": 2, "token_count": 38, "parameters": [ "self" ], "start_line": 186, "end_line": 194, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "build_libraries", "long_name": "build_libraries( self , fortran_libraries )", "filename": "build_flib.py", "nloc": 18, "complexity": 5, "token_count": 122, "parameters": [ "self", "fortran_libraries" ], "start_line": 196, "end_line": 217, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self )", "filename": "build_flib.py", "nloc": 16, "complexity": 3, "token_count": 88, "parameters": [ "self" ], "start_line": 229, "end_line": 250, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "to_object", "long_name": "to_object( self , dirty_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 13, "complexity": 3, "token_count": 89, "parameters": [ "self", "dirty_files", "module_dirs", "temp_dir" ], "start_line": 252, "end_line": 264, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "source_to_object_names", "long_name": "source_to_object_names( self , source_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 6, "complexity": 1, "token_count": 89, "parameters": [ "self", "source_files", "temp_dir" ], "start_line": 266, "end_line": 271, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "source_and_object_pairs", "long_name": "source_and_object_pairs( self , source_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 31, "parameters": [ "self", "source_files", "temp_dir" ], "start_line": 273, "end_line": 276, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f_compile", "long_name": "f_compile( self , compiler , switches , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 15, "complexity": 4, "token_count": 103, "parameters": [ "self", "compiler", "switches", "source_files", "module_dirs", "temp_dir" ], "start_line": 278, "end_line": 292, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "f90_compile", "long_name": "f90_compile( self , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 48, "parameters": [ "self", "source_files", "module_dirs", "temp_dir" ], "start_line": 296, "end_line": 299, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f77_compile", "long_name": "f77_compile( self , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 48, "parameters": [ "self", "source_files", "module_dirs", "temp_dir" ], "start_line": 301, "end_line": 304, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self", "module_dirs" ], "start_line": 307, "end_line": 308, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "create_static_lib", "long_name": "create_static_lib( self , object_files , library_name , output_dir = '' , debug = None )", "filename": "build_flib.py", "nloc": 9, "complexity": 2, "token_count": 68, "parameters": [ "self", "object_files", "library_name", "output_dir", "debug" ], "start_line": 310, "end_line": 321, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 12, "top_nesting_level": 1 }, { "name": "build_library", "long_name": "build_library( self , library_name , source_list , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 10, "complexity": 2, "token_count": 85, "parameters": [ "self", "library_name", "source_list", "module_dirs", "temp_dir" ], "start_line": 323, "end_line": 344, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "dummy_fortran_files", "long_name": "dummy_fortran_files( self )", "filename": "build_flib.py", "nloc": 8, "complexity": 1, "token_count": 69, "parameters": [ "self" ], "start_line": 346, "end_line": 353, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "is_available", "long_name": "is_available( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 355, "end_line": 356, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_version", "long_name": "get_version( self )", "filename": "build_flib.py", "nloc": 10, "complexity": 4, "token_count": 66, "parameters": [ "self" ], "start_line": 358, "end_line": 376, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "get_libraries", "long_name": "get_libraries( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 378, "end_line": 379, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_library_dirs", "long_name": "get_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 380, "end_line": 381, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 382, "end_line": 383, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 384, "end_line": 385, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 1, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 386, "end_line": 391, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "__str__", "long_name": "__str__( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self" ], "start_line": 393, "end_line": 394, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 31, "complexity": 5, "token_count": 177, "parameters": [ "self", "fc", "f90c" ], "start_line": 402, "end_line": 440, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 39, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 6, "complexity": 3, "token_count": 27, "parameters": [ "self", "module_dirs" ], "start_line": 442, "end_line": 447, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 449, "end_line": 450, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 98, "parameters": [ "self", "fc", "f90c" ], "start_line": 463, "end_line": 485, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 6, "complexity": 3, "token_count": 27, "parameters": [ "self", "module_dirs" ], "start_line": 487, "end_line": 492, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "find_lib_dir", "long_name": "find_lib_dir( self )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 99, "parameters": [ "self" ], "start_line": 494, "end_line": 508, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 509, "end_line": 510, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 511, "end_line": 512, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 94, "parameters": [ "self", "fc", "f90c" ], "start_line": 520, "end_line": 538, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 12, "parameters": [ "self", "module_dirs" ], "start_line": 540, "end_line": 542, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "find_lib_dir", "long_name": "find_lib_dir( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 543, "end_line": 545, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 546, "end_line": 547, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 548, "end_line": 549, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 16, "complexity": 5, "token_count": 103, "parameters": [ "self", "fc", "f90c" ], "start_line": 557, "end_line": 578, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 21, "complexity": 10, "token_count": 120, "parameters": [ "self" ], "start_line": 580, "end_line": 603, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 24, "top_nesting_level": 1 }, { "name": "find_lib_directories", "long_name": "find_lib_directories( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 3, "token_count": 43, "parameters": [ "self" ], "start_line": 605, "end_line": 615, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 2, "token_count": 20, "parameters": [ "self" ], "start_line": 617, "end_line": 620, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f90_compile", "long_name": "f90_compile( self , source_files , module_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self", "source_files", "module_files", "temp_dir" ], "start_line": 622, "end_line": 623, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 22, "complexity": 5, "token_count": 140, "parameters": [ "self", "fc", "f90c" ], "start_line": 632, "end_line": 660, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 29, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 15, "complexity": 7, "token_count": 85, "parameters": [ "self" ], "start_line": 662, "end_line": 676, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 679, "end_line": 680, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 4, "complexity": 2, "token_count": 31, "parameters": [ "self", "fc", "f90c" ], "start_line": 688, "end_line": 691, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 100, "parameters": [ "self", "fc", "f90c" ], "start_line": 699, "end_line": 718, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 720, "end_line": 721, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 723, "end_line": 724, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 20, "complexity": 5, "token_count": 128, "parameters": [ "self", "fc", "f90c" ], "start_line": 732, "end_line": 756, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 760, "end_line": 761, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "match_extension", "long_name": "match_extension( files , ext )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 44, "parameters": [ "files", "ext" ], "start_line": 764, "end_line": 766, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "get_f77_files", "long_name": "get_f77_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 768, "end_line": 769, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "get_f90_files", "long_name": "get_f90_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 771, "end_line": 772, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "get_fortran_files", "long_name": "get_fortran_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 774, "end_line": 775, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "find_fortran_compiler", "long_name": "find_fortran_compiler( vendor = None , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 11, "complexity": 5, "token_count": 59, "parameters": [ "vendor", "fc", "f90c" ], "start_line": 777, "end_line": 787, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 } ], "methods_before": [ { "name": "run_command", "long_name": "run_command( command )", "filename": "build_flib.py", "nloc": 5, "complexity": 1, "token_count": 32, "parameters": [ "command" ], "start_line": 55, "end_line": 60, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "show_compilers", "long_name": "show_compilers( )", "filename": "build_flib.py", "nloc": 5, "complexity": 3, "token_count": 23, "parameters": [], "start_line": 64, "end_line": 68, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 }, { "name": "initialize_options", "long_name": "initialize_options( self )", "filename": "build_flib.py", "nloc": 11, "complexity": 1, "token_count": 55, "parameters": [ "self" ], "start_line": 98, "end_line": 110, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "finalize_options", "long_name": "finalize_options( self )", "filename": "build_flib.py", "nloc": 17, "complexity": 3, "token_count": 102, "parameters": [ "self" ], "start_line": 114, "end_line": 130, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 1 }, { "name": "run", "long_name": "run( self )", "filename": "build_flib.py", "nloc": 4, "complexity": 2, "token_count": 20, "parameters": [ "self" ], "start_line": 134, "end_line": 137, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "get_library_names", "long_name": "get_library_names( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 4, "token_count": 56, "parameters": [ "self" ], "start_line": 141, "end_line": 153, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "get_library_dirs", "long_name": "get_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 40, "parameters": [ "self" ], "start_line": 157, "end_line": 166, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 40, "parameters": [ "self" ], "start_line": 170, "end_line": 179, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_source_files", "long_name": "get_source_files( self )", "filename": "build_flib.py", "nloc": 6, "complexity": 2, "token_count": 38, "parameters": [ "self" ], "start_line": 183, "end_line": 191, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "build_libraries", "long_name": "build_libraries( self , fortran_libraries )", "filename": "build_flib.py", "nloc": 18, "complexity": 5, "token_count": 122, "parameters": [ "self", "fortran_libraries" ], "start_line": 193, "end_line": 214, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self )", "filename": "build_flib.py", "nloc": 16, "complexity": 3, "token_count": 88, "parameters": [ "self" ], "start_line": 226, "end_line": 247, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "to_object", "long_name": "to_object( self , dirty_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 13, "complexity": 3, "token_count": 89, "parameters": [ "self", "dirty_files", "module_dirs", "temp_dir" ], "start_line": 249, "end_line": 261, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "source_to_object_names", "long_name": "source_to_object_names( self , source_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 6, "complexity": 1, "token_count": 89, "parameters": [ "self", "source_files", "temp_dir" ], "start_line": 263, "end_line": 268, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "source_and_object_pairs", "long_name": "source_and_object_pairs( self , source_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 31, "parameters": [ "self", "source_files", "temp_dir" ], "start_line": 270, "end_line": 273, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f_compile", "long_name": "f_compile( self , compiler , switches , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 15, "complexity": 4, "token_count": 103, "parameters": [ "self", "compiler", "switches", "source_files", "module_dirs", "temp_dir" ], "start_line": 275, "end_line": 289, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "f90_compile", "long_name": "f90_compile( self , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 48, "parameters": [ "self", "source_files", "module_dirs", "temp_dir" ], "start_line": 293, "end_line": 296, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f77_compile", "long_name": "f77_compile( self , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 48, "parameters": [ "self", "source_files", "module_dirs", "temp_dir" ], "start_line": 298, "end_line": 301, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self", "module_dirs" ], "start_line": 304, "end_line": 305, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "create_static_lib", "long_name": "create_static_lib( self , object_files , library_name , output_dir = '' , debug = None )", "filename": "build_flib.py", "nloc": 9, "complexity": 2, "token_count": 68, "parameters": [ "self", "object_files", "library_name", "output_dir", "debug" ], "start_line": 307, "end_line": 318, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 12, "top_nesting_level": 1 }, { "name": "build_library", "long_name": "build_library( self , library_name , source_list , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 10, "complexity": 2, "token_count": 85, "parameters": [ "self", "library_name", "source_list", "module_dirs", "temp_dir" ], "start_line": 320, "end_line": 341, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "dummy_fortran_files", "long_name": "dummy_fortran_files( self )", "filename": "build_flib.py", "nloc": 8, "complexity": 1, "token_count": 69, "parameters": [ "self" ], "start_line": 343, "end_line": 350, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "is_available", "long_name": "is_available( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 352, "end_line": 353, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_version", "long_name": "get_version( self )", "filename": "build_flib.py", "nloc": 10, "complexity": 4, "token_count": 66, "parameters": [ "self" ], "start_line": 355, "end_line": 373, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "get_libraries", "long_name": "get_libraries( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 375, "end_line": 376, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_library_dirs", "long_name": "get_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 377, "end_line": 378, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 379, "end_line": 380, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 381, "end_line": 382, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 1, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 383, "end_line": 388, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "__str__", "long_name": "__str__( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self" ], "start_line": 390, "end_line": 391, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 31, "complexity": 5, "token_count": 177, "parameters": [ "self", "fc", "f90c" ], "start_line": 399, "end_line": 437, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 39, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 6, "complexity": 3, "token_count": 27, "parameters": [ "self", "module_dirs" ], "start_line": 439, "end_line": 444, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 446, "end_line": 447, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 98, "parameters": [ "self", "fc", "f90c" ], "start_line": 460, "end_line": 482, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 6, "complexity": 3, "token_count": 27, "parameters": [ "self", "module_dirs" ], "start_line": 484, "end_line": 489, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "find_lib_dir", "long_name": "find_lib_dir( self )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 99, "parameters": [ "self" ], "start_line": 491, "end_line": 505, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 506, "end_line": 507, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 508, "end_line": 509, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 94, "parameters": [ "self", "fc", "f90c" ], "start_line": 517, "end_line": 535, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 12, "parameters": [ "self", "module_dirs" ], "start_line": 537, "end_line": 539, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "find_lib_dir", "long_name": "find_lib_dir( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 540, "end_line": 542, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 543, "end_line": 544, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 545, "end_line": 546, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 4, "token_count": 96, "parameters": [ "self", "fc", "f90c" ], "start_line": 554, "end_line": 574, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 21, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 19, "complexity": 9, "token_count": 108, "parameters": [ "self" ], "start_line": 576, "end_line": 598, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "find_lib_directories", "long_name": "find_lib_directories( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 3, "token_count": 43, "parameters": [ "self" ], "start_line": 600, "end_line": 610, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 2, "token_count": 20, "parameters": [ "self" ], "start_line": 612, "end_line": 615, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f90_compile", "long_name": "f90_compile( self , source_files , module_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self", "source_files", "module_files", "temp_dir" ], "start_line": 617, "end_line": 618, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 22, "complexity": 5, "token_count": 140, "parameters": [ "self", "fc", "f90c" ], "start_line": 627, "end_line": 655, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 29, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 15, "complexity": 7, "token_count": 85, "parameters": [ "self" ], "start_line": 657, "end_line": 671, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 674, "end_line": 675, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 4, "complexity": 2, "token_count": 31, "parameters": [ "self", "fc", "f90c" ], "start_line": 683, "end_line": 686, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 16, "complexity": 3, "token_count": 99, "parameters": [ "self", "fc", "f90c" ], "start_line": 694, "end_line": 714, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 21, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 716, "end_line": 717, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 20, "complexity": 5, "token_count": 128, "parameters": [ "self", "fc", "f90c" ], "start_line": 725, "end_line": 749, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 753, "end_line": 754, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "match_extension", "long_name": "match_extension( files , ext )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 44, "parameters": [ "files", "ext" ], "start_line": 757, "end_line": 759, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "get_f77_files", "long_name": "get_f77_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 761, "end_line": 762, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "get_f90_files", "long_name": "get_f90_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 764, "end_line": 765, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "get_fortran_files", "long_name": "get_fortran_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 767, "end_line": 768, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "find_fortran_compiler", "long_name": "find_fortran_compiler( vendor = None , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 11, "complexity": 5, "token_count": 59, "parameters": [ "vendor", "fc", "f90c" ], "start_line": 770, "end_line": 780, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 16, "complexity": 5, "token_count": 103, "parameters": [ "self", "fc", "f90c" ], "start_line": 557, "end_line": 578, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "get_library_dirs", "long_name": "get_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 42, "parameters": [ "self" ], "start_line": 160, "end_line": 169, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "has_f_libraries", "long_name": "has_f_libraries( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 134, "end_line": 135, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 42, "parameters": [ "self" ], "start_line": 173, "end_line": 182, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "finalize_options", "long_name": "finalize_options( self )", "filename": "build_flib.py", "nloc": 17, "complexity": 3, "token_count": 104, "parameters": [ "self" ], "start_line": 114, "end_line": 130, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 21, "complexity": 10, "token_count": 120, "parameters": [ "self" ], "start_line": 580, "end_line": 603, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 24, "top_nesting_level": 1 }, { "name": "find_lib_directories", "long_name": "find_lib_directories( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 3, "token_count": 43, "parameters": [ "self" ], "start_line": 605, "end_line": 615, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 1 }, { "name": "get_library_names", "long_name": "get_library_names( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 4, "token_count": 58, "parameters": [ "self" ], "start_line": 144, "end_line": 156, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "run", "long_name": "run( self )", "filename": "build_flib.py", "nloc": 4, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 137, "end_line": 140, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 } ], "nloc": 579, "complexity": 142, "token_count": 3325, "diff_parsed": { "added": [ " if self.has_f_libraries():", " self.fortran_libraries = self.distribution.fortran_libraries", " def has_f_libraries(self):", " return self.distribution.has_f_libraries()", "", " if not self.has_f_libraries():", " if not self.has_f_libraries():", " if not self.has_f_libraries():", " if not self.has_f_libraries():", " if sys.platform == 'win32':", " self.libraries = ['gcc','g2c']", " self.library_dirs = self.find_lib_directories()", " opt = ' -O3 -funroll-loops '", " # only check for more optimization if g77 can handle", " if cpu.is_Intel():", " opt = opt + ' -malign-double '", " lib_dir= m #m[0]", " elif cpu.has_mmx():", " opt = opt + ' -xM '", " self.f77_opt = self.f90_opt = self.get_opt()", " def get_opt(self):", " opt = ' -O4 -target=native '", "" ], "deleted": [ " self.fortran_libraries = self.distribution.fortran_libraries", " if self.fortran_libraries:", " if not self.fortran_libraries:", " if not self.fortran_libraries:", " if not self.fortran_libraries:", " if not self.fortran_libraries:", " self.libraries = ['gcc','g2c']", " self.library_dirs = self.find_lib_directories()", " opt = ' -O3 '", " # only check for more optimizaiton if g77 can handle", "", "\t\t\t\tlib_dir= m #m[0]", " if cpu.has_mmx():", " opt = opt + ' -xM '", " opt = ' -O4 '", " self.f77_opt = self.f90_opt = opt" ] } }, { "old_path": "scipy_distutils/command/build_py.py", "new_path": "scipy_distutils/command/build_py.py", "filename": "build_py.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -3,6 +3,7 @@\n from fnmatch import fnmatch\n \n def is_setup_script(file):\n+ file = os.path.basename(file)\n return (fnmatch(file,\"setup.py\") or fnmatch(file,\"setup_*.py\"))\n \n class build_py(old_build_py):\n", "added_lines": 1, "deleted_lines": 0, "source_code": "from distutils.command.build_py import *\nfrom distutils.command.build_py import build_py as old_build_py\nfrom fnmatch import fnmatch\n\ndef is_setup_script(file):\n file = os.path.basename(file)\n return (fnmatch(file,\"setup.py\") or fnmatch(file,\"setup_*.py\"))\n \nclass build_py(old_build_py):\n def find_package_modules (self, package, package_dir):\n # we filter all files that are setup.py or setup_xxx.py \n self.check_package(package, package_dir)\n module_files = glob(os.path.join(package_dir, \"*.py\"))\n modules = []\n setup_script = os.path.abspath(self.distribution.script_name)\n\n for f in module_files:\n abs_f = os.path.abspath(f)\n if abs_f != setup_script and not is_setup_script(f):\n module = os.path.splitext(os.path.basename(f))[0]\n modules.append((package, module, f))\n else:\n self.debug_print(\"excluding %s\" % setup_script)\n return modules\n\n", "source_code_before": "from distutils.command.build_py import *\nfrom distutils.command.build_py import build_py as old_build_py\nfrom fnmatch import fnmatch\n\ndef is_setup_script(file):\n return (fnmatch(file,\"setup.py\") or fnmatch(file,\"setup_*.py\"))\n \nclass build_py(old_build_py):\n def find_package_modules (self, package, package_dir):\n # we filter all files that are setup.py or setup_xxx.py \n self.check_package(package, package_dir)\n module_files = glob(os.path.join(package_dir, \"*.py\"))\n modules = []\n setup_script = os.path.abspath(self.distribution.script_name)\n\n for f in module_files:\n abs_f = os.path.abspath(f)\n if abs_f != setup_script and not is_setup_script(f):\n module = os.path.splitext(os.path.basename(f))[0]\n modules.append((package, module, f))\n else:\n self.debug_print(\"excluding %s\" % setup_script)\n return modules\n\n", "methods": [ { "name": "is_setup_script", "long_name": "is_setup_script( file )", "filename": "build_py.py", "nloc": 3, "complexity": 2, "token_count": 31, "parameters": [ "file" ], "start_line": 5, "end_line": 7, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "find_package_modules", "long_name": "find_package_modules( self , package , package_dir )", "filename": "build_py.py", "nloc": 13, "complexity": 4, "token_count": 120, "parameters": [ "self", "package", "package_dir" ], "start_line": 10, "end_line": 24, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 } ], "methods_before": [ { "name": "is_setup_script", "long_name": "is_setup_script( file )", "filename": "build_py.py", "nloc": 2, "complexity": 2, "token_count": 21, "parameters": [ "file" ], "start_line": 5, "end_line": 6, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "find_package_modules", "long_name": "find_package_modules( self , package , package_dir )", "filename": "build_py.py", "nloc": 13, "complexity": 4, "token_count": 120, "parameters": [ "self", "package", "package_dir" ], "start_line": 9, "end_line": 23, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 } ], "changed_methods": [ { "name": "is_setup_script", "long_name": "is_setup_script( file )", "filename": "build_py.py", "nloc": 3, "complexity": 2, "token_count": 31, "parameters": [ "file" ], "start_line": 5, "end_line": 7, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "nloc": 20, "complexity": 6, "token_count": 181, "diff_parsed": { "added": [ " file = os.path.basename(file)" ], "deleted": [] } }, { "old_path": "scipy_distutils/command/cpuinfo.py", "new_path": "scipy_distutils/command/cpuinfo.py", "filename": "cpuinfo.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -1,5 +1,6 @@\n #!/usr/bin/env python\n \"\"\"\n+cpuinfo\n \n Copyright 2001 Pearu Peterson all rights reserved,\n Pearu Peterson \n@@ -17,13 +18,34 @@\n \n __version__ = \"$Id$\"\n \n-import sys,string,re\n+__all__ = ['cpuinfo']\n \n-class cpuinfo:\n+import sys,string,re,types\n+\n+class cpuinfo_base:\n \"\"\"Holds CPU information and provides methods for requiring\n- the availability of CPU features.\n+ the availability of various CPU features.\n \"\"\"\n \n+ def _try_call(self,func):\n+ try:\n+ return func()\n+ except:\n+ pass\n+\n+ def __getattr__(self,name):\n+ if name[0]!='_':\n+ if hasattr(self,'_'+name):\n+ attr = getattr(self,'_'+name)\n+ if type(attr) is types.MethodType:\n+ return lambda func=self._try_call,attr=attr : func(attr)\n+ else:\n+ return lambda : None\n+ raise AttributeError,name \n+\n+\n+class linux_cpuinfo(cpuinfo_base):\n+\n info = None\n \n def __init__(self):\n@@ -31,117 +53,96 @@ def __init__(self):\n return\n info = []\n try:\n- if sys.platform == 'linux2':\n- info.append({})\n- for line in open('/proc/cpuinfo').readlines():\n- name_value = map(string.strip,string.split(line,':',1))\n- if len(name_value)!=2:\n- continue\n- name,value = name_value\n- if info[-1].has_key(name): # next processor\n- info.append({})\n- info[-1][name] = value\n- #XXX How to obtain CPU information on other platforms?\n- except e,m:\n- print '%s: %s (ignoring)' % (e,m)\n- self.info = info\n-\n- def is_Pentium(self):\n- #XXX\n- pass\n-\n- def is_PentiumPro(self):\n- #XXX\n- pass\n-\n- def is_PentiumII(self):\n- try:\n- return re.match(r'.*?Pentium II[^I]',\n- self.info[0]['model name']) is not None\n+ for line in open('/proc/cpuinfo').readlines():\n+ name_value = map(string.strip,string.split(line,':',1))\n+ if len(name_value)!=2:\n+ continue\n+ name,value = name_value\n+ if not info or info[-1].has_key(name): # next processor\n+ info.append({})\n+ info[-1][name] = value\n except:\n- pass\n+ print sys.exc_value,'(ignoring)'\n+ self.__class__.info = info\n \n- def is_PentiumIII(self):\n- #XXX\n- pass\n+ def _not_impl(self): pass\n \n- def is_PentiumIV(self):\n- #XXX\n- pass\n+ # Athlon\n \n- def is_AthlonK6(self):\n- try:\n- return re.match(r'.*?AMD-K6',self.info[0]['model name']) is not None\n- except:\n- pass\n+ def _is_AMD(self):\n+ return self.info[0]['vendor_id']=='AuthenticAMD'\n \n- def is_AthlonK7(self):\n- try:\n- return re.match(r'.*?AMD-K7',self.info[0]['model name']) is not None\n- except:\n- pass\n+ def _is_AthlonK6(self):\n+ return re.match(r'.*?AMD-K6',self.info[0]['model name']) is not None\n \n- def is_AMD(self):\n- try:\n- return self.info[0]['vendor_id']=='AuthenticAMD'\n- except:\n- pass\n+ def _is_AthlonK7(self):\n+ return re.match(r'.*?AMD-K7',self.info[0]['model name']) is not None\n \n- def is_Intel(self):\n- try:\n- return self.info[0]['vendor_id']=='GenuineIntel'\n- except:\n- pass\n+ # Alpha\n \n- def is_Alpha(self):\n- try:\n- return self.info[0]['cpu']=='Alpha'\n- except:\n- pass\n+ def _is_Alpha(self):\n+ return self.info[0]['cpu']=='Alpha'\n \n- def is_i386(self):\n- #XXX\n- pass\n-\n- def is_i486(self):\n- #XXX\n- pass\n-\n- def is_i586(self):\n- if self.is_Intel():\n- try:\n- return self.info[0]['model'] == '5'\n- except:\n- pass\n-\n- def is_i686(self):\n- if self.is_Intel():\n- try:\n- return self.info[0]['model'] == '6'\n- except:\n- pass\n-\n- def is_singleCPU(self):\n- if self.info:\n- return len(self.info) == 1\n-\n- def has_fdiv_bug(self):\n- try:\n- return self.info[0]['fdiv_bug']=='yes'\n- except:\n- pass\n+ def _is_EV4(self):\n+ return self.is_Alpha() and self.info[0]['cpu model'] == 'EV4'\n \n- def has_f00f_bug(self):\n- try:\n- return self.info[0]['f00f_bug']=='yes'\n- except:\n- pass\n+ def _is_EV5(self):\n+ return self.is_Alpha() and self.info[0]['cpu model'] == 'EV5'\n+\n+ def _is_EV56(self):\n+ return self.is_Alpha() and self.info[0]['cpu model'] == 'EV56'\n+\n+ def _is_PCA56(self):\n+ return self.is_Alpha() and self.info[0]['cpu model'] == 'PCA56'\n+\n+ # Intel\n+\n+ #XXX\n+ _is_i386 = _not_impl\n+\n+ def _is_Intel(self):\n+ return self.info[0]['vendor_id']=='GenuineIntel'\n+\n+ def _is_i486(self):\n+ return self.info[0]['cpu']=='i486'\n+\n+ def _is_i586(self):\n+ return self.is_Intel() and self.info[0]['model'] == '5'\n+\n+ def _is_i686(self):\n+ return self.is_Intel() and self.info[0]['model'] == '6'\n+\n+ def _is_Celeron(self):\n+ return re.match(r'.*?Celeron',\n+ self.info[0]['model name']) is not None\n+\n+ #XXX\n+ _is_Pentium = _is_PentiumPro = _is_PentiumIII = _is_PentiumIV = _not_impl\n+\n+ def _is_PentiumII(self):\n+ return re.match(r'.*?Pentium II\\b',\n+ self.info[0]['model name']) is not None\n+\n+ # Varia\n+\n+ def _is_singleCPU(self):\n+ return len(self.info) == 1\n+\n+ def _has_fdiv_bug(self):\n+ return self.info[0]['fdiv_bug']=='yes'\n+\n+ def _has_f00f_bug(self):\n+ return self.info[0]['f00f_bug']=='yes'\n+\n+ def _has_mmx(self):\n+ return re.match(r'.*?\\bmmx',self.info[0]['flags']) is not None\n+\n+if sys.platform[:5] == 'linux': # variations: linux2,linux-i386 (any others?)\n+ cpuinfo = linux_cpuinfo\n+#XXX: other OS's. Eg. use _winreg on Win32. Or os.uname on unices.\n+else:\n+ cpuinfo = cpuinfo_base\n \n- def has_mmx(self):\n- try:\n- return re.match(r'.*?\\bmmx',self.info[0]['flags']) is not None\n- except:\n- pass\n \n \"\"\"\n laptop:\n@@ -156,3 +157,16 @@ def has_mmx(self):\n fiasco:\n [{'max. addr. space #': '127', 'cpu': 'Alpha', 'cpu serial number': 'Linux_is_Great!', 'kernel unaligned acc': '0 (pc=0,va=0)', 'system revision': '0', 'system variation': 'LX164', 'cycle frequency [Hz]': '533185472', 'system serial number': 'MILO-2.0.35-c5.', 'timer frequency [Hz]': '1024.00', 'cpu model': 'EV56', 'platform string': 'N/A', 'cpu revision': '0', 'BogoMIPS': '530.57', 'cpus detected': '0', 'phys. address bits': '40', 'user unaligned acc': '1340 (pc=2000000ec90,va=20001156da4)', 'page size [bytes]': '8192', 'system type': 'EB164', 'cpu variation': '0'}]\n \"\"\"\n+\n+if __name__ == \"__main__\":\n+ cpu = cpuinfo()\n+\n+ cpu.is_blaa()\n+ cpu.is_Intel()\n+ cpu.is_Alpha()\n+\n+ print 'CPU information:',\n+ for name in dir(cpuinfo):\n+ if name[0]=='_' and name[1]!='_' and getattr(cpu,name[1:])():\n+ print name[1:],\n+ print\n", "added_lines": 117, "deleted_lines": 103, "source_code": "#!/usr/bin/env python\n\"\"\"\ncpuinfo\n\nCopyright 2001 Pearu Peterson all rights reserved,\nPearu Peterson \nPermission to use, modify, and distribute this software is given under the\nterms of the LGPL. See http://www.fsf.org\n\nNote: This should be merged into proc at some point. Perhaps proc should\nbe returning classes like this instead of using dictionaries.\n\nNO WARRANTY IS EXPRESSED OR IMPLIED. USE AT YOUR OWN RISK.\n$Revision$\n$Date$\nPearu Peterson\n\"\"\"\n\n__version__ = \"$Id$\"\n\n__all__ = ['cpuinfo']\n\nimport sys,string,re,types\n\nclass cpuinfo_base:\n \"\"\"Holds CPU information and provides methods for requiring\n the availability of various CPU features.\n \"\"\"\n\n def _try_call(self,func):\n try:\n return func()\n except:\n pass\n\n def __getattr__(self,name):\n if name[0]!='_':\n if hasattr(self,'_'+name):\n attr = getattr(self,'_'+name)\n if type(attr) is types.MethodType:\n return lambda func=self._try_call,attr=attr : func(attr)\n else:\n return lambda : None\n raise AttributeError,name \n\n\nclass linux_cpuinfo(cpuinfo_base):\n\n info = None\n \n def __init__(self):\n if self.info is not None:\n return\n info = []\n try:\n for line in open('/proc/cpuinfo').readlines():\n name_value = map(string.strip,string.split(line,':',1))\n if len(name_value)!=2:\n continue\n name,value = name_value\n if not info or info[-1].has_key(name): # next processor\n info.append({})\n info[-1][name] = value\n except:\n print sys.exc_value,'(ignoring)'\n self.__class__.info = info\n\n def _not_impl(self): pass\n\n # Athlon\n\n def _is_AMD(self):\n return self.info[0]['vendor_id']=='AuthenticAMD'\n\n def _is_AthlonK6(self):\n return re.match(r'.*?AMD-K6',self.info[0]['model name']) is not None\n\n def _is_AthlonK7(self):\n return re.match(r'.*?AMD-K7',self.info[0]['model name']) is not None\n\n # Alpha\n\n def _is_Alpha(self):\n return self.info[0]['cpu']=='Alpha'\n\n def _is_EV4(self):\n return self.is_Alpha() and self.info[0]['cpu model'] == 'EV4'\n\n def _is_EV5(self):\n return self.is_Alpha() and self.info[0]['cpu model'] == 'EV5'\n\n def _is_EV56(self):\n return self.is_Alpha() and self.info[0]['cpu model'] == 'EV56'\n\n def _is_PCA56(self):\n return self.is_Alpha() and self.info[0]['cpu model'] == 'PCA56'\n\n # Intel\n\n #XXX\n _is_i386 = _not_impl\n\n def _is_Intel(self):\n return self.info[0]['vendor_id']=='GenuineIntel'\n\n def _is_i486(self):\n return self.info[0]['cpu']=='i486'\n\n def _is_i586(self):\n return self.is_Intel() and self.info[0]['model'] == '5'\n\n def _is_i686(self):\n return self.is_Intel() and self.info[0]['model'] == '6'\n\n def _is_Celeron(self):\n return re.match(r'.*?Celeron',\n self.info[0]['model name']) is not None\n\n #XXX\n _is_Pentium = _is_PentiumPro = _is_PentiumIII = _is_PentiumIV = _not_impl\n\n def _is_PentiumII(self):\n return re.match(r'.*?Pentium II\\b',\n self.info[0]['model name']) is not None\n\n # Varia\n\n def _is_singleCPU(self):\n return len(self.info) == 1\n\n def _has_fdiv_bug(self):\n return self.info[0]['fdiv_bug']=='yes'\n\n def _has_f00f_bug(self):\n return self.info[0]['f00f_bug']=='yes'\n\n def _has_mmx(self):\n return re.match(r'.*?\\bmmx',self.info[0]['flags']) is not None\n\nif sys.platform[:5] == 'linux': # variations: linux2,linux-i386 (any others?)\n cpuinfo = linux_cpuinfo\n#XXX: other OS's. Eg. use _winreg on Win32. Or os.uname on unices.\nelse:\n cpuinfo = cpuinfo_base\n\n\n\"\"\"\nlaptop:\n[{'cache size': '256 KB', 'cpu MHz': '399.129', 'processor': '0', 'fdiv_bug': 'no', 'coma_bug': 'no', 'model': '6', 'cpuid level': '2', 'model name': 'Mobile Pentium II', 'fpu_exception': 'yes', 'hlt_bug': 'no', 'bogomips': '796.26', 'vendor_id': 'GenuineIntel', 'fpu': 'yes', 'wp': 'yes', 'cpu family': '6', 'f00f_bug': 'no', 'stepping': '13', 'flags': 'fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr'}]\n\nkev:\n[{'cache size': '512 KB', 'cpu MHz': '350.799', 'processor': '0', 'fdiv_bug': 'no', 'coma_bug': 'no', 'model': '5', 'cpuid level': '2', 'model name': 'Pentium II (Deschutes)', 'fpu_exception': 'yes', 'hlt_bug': 'no', 'bogomips': '699.59', 'vendor_id': 'GenuineIntel', 'fpu': 'yes', 'wp': 'yes', 'cpu family': '6', 'f00f_bug': 'no', 'stepping': '3', 'flags': 'fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr'}, {'cache size': '512 KB', 'cpu MHz': '350.799', 'processor': '1', 'fdiv_bug': 'no', 'coma_bug': 'no', 'model': '5', 'cpuid level': '2', 'model name': 'Pentium II (Deschutes)', 'fpu_exception': 'yes', 'hlt_bug': 'no', 'bogomips': '701.23', 'vendor_id': 'GenuineIntel', 'fpu': 'yes', 'wp': 'yes', 'cpu family': '6', 'f00f_bug': 'no', 'stepping': '3', 'flags': 'fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr'}]\n\nath:\n[{'cache size': '512 KB', 'cpu MHz': '503.542', 'processor': '0', 'fdiv_bug': 'no', 'coma_bug': 'no', 'model': '1', 'cpuid level': '1', 'model name': 'AMD-K7(tm) Processor', 'fpu_exception': 'yes', 'hlt_bug': 'no', 'bogomips': '1002.70', 'vendor_id': 'AuthenticAMD', 'fpu': 'yes', 'wp': 'yes', 'cpu family': '6', 'f00f_bug': 'no', 'stepping': '2', 'flags': 'fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat mmx syscall mmxext 3dnowext 3dnow'}]\n\nfiasco:\n[{'max. addr. space #': '127', 'cpu': 'Alpha', 'cpu serial number': 'Linux_is_Great!', 'kernel unaligned acc': '0 (pc=0,va=0)', 'system revision': '0', 'system variation': 'LX164', 'cycle frequency [Hz]': '533185472', 'system serial number': 'MILO-2.0.35-c5.', 'timer frequency [Hz]': '1024.00', 'cpu model': 'EV56', 'platform string': 'N/A', 'cpu revision': '0', 'BogoMIPS': '530.57', 'cpus detected': '0', 'phys. address bits': '40', 'user unaligned acc': '1340 (pc=2000000ec90,va=20001156da4)', 'page size [bytes]': '8192', 'system type': 'EB164', 'cpu variation': '0'}]\n\"\"\"\n\nif __name__ == \"__main__\":\n cpu = cpuinfo()\n\n cpu.is_blaa()\n cpu.is_Intel()\n cpu.is_Alpha()\n\n print 'CPU information:',\n for name in dir(cpuinfo):\n if name[0]=='_' and name[1]!='_' and getattr(cpu,name[1:])():\n print name[1:],\n print\n", "source_code_before": "#!/usr/bin/env python\n\"\"\"\n\nCopyright 2001 Pearu Peterson all rights reserved,\nPearu Peterson \nPermission to use, modify, and distribute this software is given under the\nterms of the LGPL. See http://www.fsf.org\n\nNote: This should be merged into proc at some point. Perhaps proc should\nbe returning classes like this instead of using dictionaries.\n\nNO WARRANTY IS EXPRESSED OR IMPLIED. USE AT YOUR OWN RISK.\n$Revision$\n$Date$\nPearu Peterson\n\"\"\"\n\n__version__ = \"$Id$\"\n\nimport sys,string,re\n\nclass cpuinfo:\n \"\"\"Holds CPU information and provides methods for requiring\n the availability of CPU features.\n \"\"\"\n\n info = None\n \n def __init__(self):\n if self.info is not None:\n return\n info = []\n try:\n if sys.platform == 'linux2':\n info.append({})\n for line in open('/proc/cpuinfo').readlines():\n name_value = map(string.strip,string.split(line,':',1))\n if len(name_value)!=2:\n continue\n name,value = name_value\n if info[-1].has_key(name): # next processor\n info.append({})\n info[-1][name] = value\n #XXX How to obtain CPU information on other platforms?\n except e,m:\n print '%s: %s (ignoring)' % (e,m)\n self.info = info\n\n def is_Pentium(self):\n #XXX\n pass\n\n def is_PentiumPro(self):\n #XXX\n pass\n\n def is_PentiumII(self):\n try:\n return re.match(r'.*?Pentium II[^I]',\n self.info[0]['model name']) is not None\n except:\n pass\n\n def is_PentiumIII(self):\n #XXX\n pass\n\n def is_PentiumIV(self):\n #XXX\n pass\n\n def is_AthlonK6(self):\n try:\n return re.match(r'.*?AMD-K6',self.info[0]['model name']) is not None\n except:\n pass\n\n def is_AthlonK7(self):\n try:\n return re.match(r'.*?AMD-K7',self.info[0]['model name']) is not None\n except:\n pass\n\n def is_AMD(self):\n try:\n return self.info[0]['vendor_id']=='AuthenticAMD'\n except:\n pass\n\n def is_Intel(self):\n try:\n return self.info[0]['vendor_id']=='GenuineIntel'\n except:\n pass\n\n def is_Alpha(self):\n try:\n return self.info[0]['cpu']=='Alpha'\n except:\n pass\n\n def is_i386(self):\n #XXX\n pass\n\n def is_i486(self):\n #XXX\n pass\n\n def is_i586(self):\n if self.is_Intel():\n try:\n return self.info[0]['model'] == '5'\n except:\n pass\n\n def is_i686(self):\n if self.is_Intel():\n try:\n return self.info[0]['model'] == '6'\n except:\n pass\n\n def is_singleCPU(self):\n if self.info:\n return len(self.info) == 1\n\n def has_fdiv_bug(self):\n try:\n return self.info[0]['fdiv_bug']=='yes'\n except:\n pass\n\n def has_f00f_bug(self):\n try:\n return self.info[0]['f00f_bug']=='yes'\n except:\n pass\n\n def has_mmx(self):\n try:\n return re.match(r'.*?\\bmmx',self.info[0]['flags']) is not None\n except:\n pass\n\n\"\"\"\nlaptop:\n[{'cache size': '256 KB', 'cpu MHz': '399.129', 'processor': '0', 'fdiv_bug': 'no', 'coma_bug': 'no', 'model': '6', 'cpuid level': '2', 'model name': 'Mobile Pentium II', 'fpu_exception': 'yes', 'hlt_bug': 'no', 'bogomips': '796.26', 'vendor_id': 'GenuineIntel', 'fpu': 'yes', 'wp': 'yes', 'cpu family': '6', 'f00f_bug': 'no', 'stepping': '13', 'flags': 'fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr'}]\n\nkev:\n[{'cache size': '512 KB', 'cpu MHz': '350.799', 'processor': '0', 'fdiv_bug': 'no', 'coma_bug': 'no', 'model': '5', 'cpuid level': '2', 'model name': 'Pentium II (Deschutes)', 'fpu_exception': 'yes', 'hlt_bug': 'no', 'bogomips': '699.59', 'vendor_id': 'GenuineIntel', 'fpu': 'yes', 'wp': 'yes', 'cpu family': '6', 'f00f_bug': 'no', 'stepping': '3', 'flags': 'fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr'}, {'cache size': '512 KB', 'cpu MHz': '350.799', 'processor': '1', 'fdiv_bug': 'no', 'coma_bug': 'no', 'model': '5', 'cpuid level': '2', 'model name': 'Pentium II (Deschutes)', 'fpu_exception': 'yes', 'hlt_bug': 'no', 'bogomips': '701.23', 'vendor_id': 'GenuineIntel', 'fpu': 'yes', 'wp': 'yes', 'cpu family': '6', 'f00f_bug': 'no', 'stepping': '3', 'flags': 'fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr'}]\n\nath:\n[{'cache size': '512 KB', 'cpu MHz': '503.542', 'processor': '0', 'fdiv_bug': 'no', 'coma_bug': 'no', 'model': '1', 'cpuid level': '1', 'model name': 'AMD-K7(tm) Processor', 'fpu_exception': 'yes', 'hlt_bug': 'no', 'bogomips': '1002.70', 'vendor_id': 'AuthenticAMD', 'fpu': 'yes', 'wp': 'yes', 'cpu family': '6', 'f00f_bug': 'no', 'stepping': '2', 'flags': 'fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat mmx syscall mmxext 3dnowext 3dnow'}]\n\nfiasco:\n[{'max. addr. space #': '127', 'cpu': 'Alpha', 'cpu serial number': 'Linux_is_Great!', 'kernel unaligned acc': '0 (pc=0,va=0)', 'system revision': '0', 'system variation': 'LX164', 'cycle frequency [Hz]': '533185472', 'system serial number': 'MILO-2.0.35-c5.', 'timer frequency [Hz]': '1024.00', 'cpu model': 'EV56', 'platform string': 'N/A', 'cpu revision': '0', 'BogoMIPS': '530.57', 'cpus detected': '0', 'phys. address bits': '40', 'user unaligned acc': '1340 (pc=2000000ec90,va=20001156da4)', 'page size [bytes]': '8192', 'system type': 'EB164', 'cpu variation': '0'}]\n\"\"\"\n", "methods": [ { "name": "_try_call", "long_name": "_try_call( self , func )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 16, "parameters": [ "self", "func" ], "start_line": 30, "end_line": 34, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "__getattr__", "long_name": "__getattr__( self , name )", "filename": "cpuinfo.py", "nloc": 9, "complexity": 4, "token_count": 71, "parameters": [ "self", "name" ], "start_line": 36, "end_line": 44, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self )", "filename": "cpuinfo.py", "nloc": 16, "complexity": 7, "token_count": 112, "parameters": [ "self" ], "start_line": 51, "end_line": 66, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "_is_AMD", "long_name": "_is_AMD( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 72, "end_line": 73, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_AthlonK6", "long_name": "_is_AthlonK6( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 75, "end_line": 76, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_AthlonK7", "long_name": "_is_AthlonK7( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 78, "end_line": 79, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_Alpha", "long_name": "_is_Alpha( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 83, "end_line": 84, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_EV4", "long_name": "_is_EV4( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 2, "token_count": 23, "parameters": [ "self" ], "start_line": 86, "end_line": 87, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_EV5", "long_name": "_is_EV5( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 2, "token_count": 23, "parameters": [ "self" ], "start_line": 89, "end_line": 90, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_EV56", "long_name": "_is_EV56( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 2, "token_count": 23, "parameters": [ "self" ], "start_line": 92, "end_line": 93, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_PCA56", "long_name": "_is_PCA56( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 2, "token_count": 23, "parameters": [ "self" ], "start_line": 95, "end_line": 96, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_Intel", "long_name": "_is_Intel( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 103, "end_line": 104, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_i486", "long_name": "_is_i486( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 106, "end_line": 107, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_i586", "long_name": "_is_i586( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 2, "token_count": 23, "parameters": [ "self" ], "start_line": 109, "end_line": 110, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_i686", "long_name": "_is_i686( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 2, "token_count": 23, "parameters": [ "self" ], "start_line": 112, "end_line": 113, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_Celeron", "long_name": "_is_Celeron( self )", "filename": "cpuinfo.py", "nloc": 3, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 115, "end_line": 117, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "_is_PentiumII", "long_name": "_is_PentiumII( self )", "filename": "cpuinfo.py", "nloc": 3, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 122, "end_line": 124, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "_is_singleCPU", "long_name": "_is_singleCPU( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 14, "parameters": [ "self" ], "start_line": 128, "end_line": 129, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_has_fdiv_bug", "long_name": "_has_fdiv_bug( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 131, "end_line": 132, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_has_f00f_bug", "long_name": "_has_f00f_bug( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 134, "end_line": 135, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_has_mmx", "long_name": "_has_mmx( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 137, "end_line": 138, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 } ], "methods_before": [ { "name": "__init__", "long_name": "__init__( self )", "filename": "cpuinfo.py", "nloc": 18, "complexity": 7, "token_count": 126, "parameters": [ "self" ], "start_line": 29, "end_line": 47, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "is_Pentium", "long_name": "is_Pentium( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 49, "end_line": 51, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "is_PentiumPro", "long_name": "is_PentiumPro( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 53, "end_line": 55, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "is_PentiumII", "long_name": "is_PentiumII( self )", "filename": "cpuinfo.py", "nloc": 6, "complexity": 2, "token_count": 31, "parameters": [ "self" ], "start_line": 57, "end_line": 62, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "is_PentiumIII", "long_name": "is_PentiumIII( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 64, "end_line": 66, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "is_PentiumIV", "long_name": "is_PentiumIV( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 68, "end_line": 70, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "is_AthlonK6", "long_name": "is_AthlonK6( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 31, "parameters": [ "self" ], "start_line": 72, "end_line": 76, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "is_AthlonK7", "long_name": "is_AthlonK7( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 31, "parameters": [ "self" ], "start_line": 78, "end_line": 82, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "is_AMD", "long_name": "is_AMD( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 84, "end_line": 88, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "is_Intel", "long_name": "is_Intel( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 90, "end_line": 94, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "is_Alpha", "long_name": "is_Alpha( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 96, "end_line": 100, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "is_i386", "long_name": "is_i386( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 102, "end_line": 104, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "is_i486", "long_name": "is_i486( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 106, "end_line": 108, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "is_i586", "long_name": "is_i586( self )", "filename": "cpuinfo.py", "nloc": 6, "complexity": 3, "token_count": 29, "parameters": [ "self" ], "start_line": 110, "end_line": 115, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "is_i686", "long_name": "is_i686( self )", "filename": "cpuinfo.py", "nloc": 6, "complexity": 3, "token_count": 29, "parameters": [ "self" ], "start_line": 117, "end_line": 122, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "is_singleCPU", "long_name": "is_singleCPU( self )", "filename": "cpuinfo.py", "nloc": 3, "complexity": 2, "token_count": 19, "parameters": [ "self" ], "start_line": 124, "end_line": 126, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "has_fdiv_bug", "long_name": "has_fdiv_bug( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 128, "end_line": 132, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "has_f00f_bug", "long_name": "has_f00f_bug( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 134, "end_line": 138, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "has_mmx", "long_name": "has_mmx( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 31, "parameters": [ "self" ], "start_line": 140, "end_line": 144, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 } ], "changed_methods": [ { "name": "_is_AthlonK7", "long_name": "_is_AthlonK7( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 78, "end_line": 79, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_i686", "long_name": "_is_i686( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 2, "token_count": 23, "parameters": [ "self" ], "start_line": 112, "end_line": 113, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "is_Intel", "long_name": "is_Intel( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 90, "end_line": 94, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "is_i386", "long_name": "is_i386( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 102, "end_line": 104, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "_is_i486", "long_name": "_is_i486( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 106, "end_line": 107, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "is_AthlonK6", "long_name": "is_AthlonK6( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 31, "parameters": [ "self" ], "start_line": 72, "end_line": 76, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "is_i586", "long_name": "is_i586( self )", "filename": "cpuinfo.py", "nloc": 6, "complexity": 3, "token_count": 29, "parameters": [ "self" ], "start_line": 110, "end_line": 115, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "__getattr__", "long_name": "__getattr__( self , name )", "filename": "cpuinfo.py", "nloc": 9, "complexity": 4, "token_count": 71, "parameters": [ "self", "name" ], "start_line": 36, "end_line": 44, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "_is_PentiumII", "long_name": "_is_PentiumII( self )", "filename": "cpuinfo.py", "nloc": 3, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 122, "end_line": 124, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "is_Alpha", "long_name": "is_Alpha( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 96, "end_line": 100, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "_is_PCA56", "long_name": "_is_PCA56( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 2, "token_count": 23, "parameters": [ "self" ], "start_line": 95, "end_line": 96, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "is_PentiumII", "long_name": "is_PentiumII( self )", "filename": "cpuinfo.py", "nloc": 6, "complexity": 2, "token_count": 31, "parameters": [ "self" ], "start_line": 57, "end_line": 62, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "is_PentiumIV", "long_name": "is_PentiumIV( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 68, "end_line": 70, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "is_i486", "long_name": "is_i486( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 106, "end_line": 108, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "_is_EV4", "long_name": "_is_EV4( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 2, "token_count": 23, "parameters": [ "self" ], "start_line": 86, "end_line": 87, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_Alpha", "long_name": "_is_Alpha( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 83, "end_line": 84, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "has_mmx", "long_name": "has_mmx( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 31, "parameters": [ "self" ], "start_line": 140, "end_line": 144, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "_has_mmx", "long_name": "_has_mmx( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 137, "end_line": 138, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_try_call", "long_name": "_try_call( self , func )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 16, "parameters": [ "self", "func" ], "start_line": 30, "end_line": 34, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "_is_EV56", "long_name": "_is_EV56( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 2, "token_count": 23, "parameters": [ "self" ], "start_line": 92, "end_line": 93, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_i586", "long_name": "_is_i586( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 2, "token_count": 23, "parameters": [ "self" ], "start_line": 109, "end_line": 110, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "is_PentiumPro", "long_name": "is_PentiumPro( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 53, "end_line": 55, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "is_singleCPU", "long_name": "is_singleCPU( self )", "filename": "cpuinfo.py", "nloc": 3, "complexity": 2, "token_count": 19, "parameters": [ "self" ], "start_line": 124, "end_line": 126, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "_has_fdiv_bug", "long_name": "_has_fdiv_bug( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 131, "end_line": 132, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "is_PentiumIII", "long_name": "is_PentiumIII( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 64, "end_line": 66, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "has_f00f_bug", "long_name": "has_f00f_bug( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 134, "end_line": 138, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "is_Pentium", "long_name": "is_Pentium( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 49, "end_line": 51, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "_has_f00f_bug", "long_name": "_has_f00f_bug( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 134, "end_line": 135, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_singleCPU", "long_name": "_is_singleCPU( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 14, "parameters": [ "self" ], "start_line": 128, "end_line": 129, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "is_AMD", "long_name": "is_AMD( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 84, "end_line": 88, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "_is_AMD", "long_name": "_is_AMD( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 72, "end_line": 73, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self )", "filename": "cpuinfo.py", "nloc": 16, "complexity": 7, "token_count": 112, "parameters": [ "self" ], "start_line": 51, "end_line": 66, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "has_fdiv_bug", "long_name": "has_fdiv_bug( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 128, "end_line": 132, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "_is_AthlonK6", "long_name": "_is_AthlonK6( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 75, "end_line": 76, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_Celeron", "long_name": "_is_Celeron( self )", "filename": "cpuinfo.py", "nloc": 3, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 115, "end_line": 117, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "is_i686", "long_name": "is_i686( self )", "filename": "cpuinfo.py", "nloc": 6, "complexity": 3, "token_count": 29, "parameters": [ "self" ], "start_line": 117, "end_line": 122, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "_is_Intel", "long_name": "_is_Intel( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 103, "end_line": 104, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "_is_EV5", "long_name": "_is_EV5( self )", "filename": "cpuinfo.py", "nloc": 2, "complexity": 2, "token_count": 23, "parameters": [ "self" ], "start_line": 89, "end_line": 90, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "is_AthlonK7", "long_name": "is_AthlonK7( self )", "filename": "cpuinfo.py", "nloc": 5, "complexity": 2, "token_count": 31, "parameters": [ "self" ], "start_line": 78, "end_line": 82, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 } ], "nloc": 123, "complexity": 37, "token_count": 745, "diff_parsed": { "added": [ "cpuinfo", "__all__ = ['cpuinfo']", "import sys,string,re,types", "", "class cpuinfo_base:", " the availability of various CPU features.", " def _try_call(self,func):", " try:", " return func()", " except:", " pass", "", " def __getattr__(self,name):", " if name[0]!='_':", " if hasattr(self,'_'+name):", " attr = getattr(self,'_'+name)", " if type(attr) is types.MethodType:", " return lambda func=self._try_call,attr=attr : func(attr)", " else:", " return lambda : None", " raise AttributeError,name", "", "", "class linux_cpuinfo(cpuinfo_base):", "", " for line in open('/proc/cpuinfo').readlines():", " name_value = map(string.strip,string.split(line,':',1))", " if len(name_value)!=2:", " continue", " name,value = name_value", " if not info or info[-1].has_key(name): # next processor", " info.append({})", " info[-1][name] = value", " print sys.exc_value,'(ignoring)'", " self.__class__.info = info", " def _not_impl(self): pass", " # Athlon", " def _is_AMD(self):", " return self.info[0]['vendor_id']=='AuthenticAMD'", " def _is_AthlonK6(self):", " return re.match(r'.*?AMD-K6',self.info[0]['model name']) is not None", " def _is_AthlonK7(self):", " return re.match(r'.*?AMD-K7',self.info[0]['model name']) is not None", " # Alpha", " def _is_Alpha(self):", " return self.info[0]['cpu']=='Alpha'", " def _is_EV4(self):", " return self.is_Alpha() and self.info[0]['cpu model'] == 'EV4'", " def _is_EV5(self):", " return self.is_Alpha() and self.info[0]['cpu model'] == 'EV5'", "", " def _is_EV56(self):", " return self.is_Alpha() and self.info[0]['cpu model'] == 'EV56'", "", " def _is_PCA56(self):", " return self.is_Alpha() and self.info[0]['cpu model'] == 'PCA56'", "", " # Intel", "", " #XXX", " _is_i386 = _not_impl", "", " def _is_Intel(self):", " return self.info[0]['vendor_id']=='GenuineIntel'", "", " def _is_i486(self):", " return self.info[0]['cpu']=='i486'", "", " def _is_i586(self):", " return self.is_Intel() and self.info[0]['model'] == '5'", "", " def _is_i686(self):", " return self.is_Intel() and self.info[0]['model'] == '6'", "", " def _is_Celeron(self):", " return re.match(r'.*?Celeron',", " self.info[0]['model name']) is not None", "", " #XXX", " _is_Pentium = _is_PentiumPro = _is_PentiumIII = _is_PentiumIV = _not_impl", "", " def _is_PentiumII(self):", " return re.match(r'.*?Pentium II\\b',", " self.info[0]['model name']) is not None", "", " # Varia", "", " def _is_singleCPU(self):", " return len(self.info) == 1", "", " def _has_fdiv_bug(self):", " return self.info[0]['fdiv_bug']=='yes'", "", " def _has_f00f_bug(self):", " return self.info[0]['f00f_bug']=='yes'", "", " def _has_mmx(self):", " return re.match(r'.*?\\bmmx',self.info[0]['flags']) is not None", "", "if sys.platform[:5] == 'linux': # variations: linux2,linux-i386 (any others?)", " cpuinfo = linux_cpuinfo", "#XXX: other OS's. Eg. use _winreg on Win32. Or os.uname on unices.", "else:", " cpuinfo = cpuinfo_base", "", "if __name__ == \"__main__\":", " cpu = cpuinfo()", "", " cpu.is_blaa()", " cpu.is_Intel()", " cpu.is_Alpha()", "", " print 'CPU information:',", " for name in dir(cpuinfo):", " if name[0]=='_' and name[1]!='_' and getattr(cpu,name[1:])():", " print name[1:],", " print" ], "deleted": [ "import sys,string,re", "class cpuinfo:", " the availability of CPU features.", " if sys.platform == 'linux2':", " info.append({})", " for line in open('/proc/cpuinfo').readlines():", " name_value = map(string.strip,string.split(line,':',1))", " if len(name_value)!=2:", " continue", " name,value = name_value", " if info[-1].has_key(name): # next processor", " info.append({})", " info[-1][name] = value", " #XXX How to obtain CPU information on other platforms?", " except e,m:", " print '%s: %s (ignoring)' % (e,m)", " self.info = info", "", " def is_Pentium(self):", " #XXX", " pass", "", " def is_PentiumPro(self):", " #XXX", " pass", "", " def is_PentiumII(self):", " try:", " return re.match(r'.*?Pentium II[^I]',", " self.info[0]['model name']) is not None", " pass", " def is_PentiumIII(self):", " #XXX", " pass", " def is_PentiumIV(self):", " #XXX", " pass", " def is_AthlonK6(self):", " try:", " return re.match(r'.*?AMD-K6',self.info[0]['model name']) is not None", " except:", " pass", " def is_AthlonK7(self):", " try:", " return re.match(r'.*?AMD-K7',self.info[0]['model name']) is not None", " except:", " pass", " def is_AMD(self):", " try:", " return self.info[0]['vendor_id']=='AuthenticAMD'", " except:", " pass", " def is_Intel(self):", " try:", " return self.info[0]['vendor_id']=='GenuineIntel'", " except:", " pass", " def is_Alpha(self):", " try:", " return self.info[0]['cpu']=='Alpha'", " except:", " pass", " def is_i386(self):", " #XXX", " pass", "", " def is_i486(self):", " #XXX", " pass", "", " def is_i586(self):", " if self.is_Intel():", " try:", " return self.info[0]['model'] == '5'", " except:", " pass", "", " def is_i686(self):", " if self.is_Intel():", " try:", " return self.info[0]['model'] == '6'", " except:", " pass", "", " def is_singleCPU(self):", " if self.info:", " return len(self.info) == 1", "", " def has_fdiv_bug(self):", " try:", " return self.info[0]['fdiv_bug']=='yes'", " except:", " pass", " def has_f00f_bug(self):", " try:", " return self.info[0]['f00f_bug']=='yes'", " except:", " pass", " def has_mmx(self):", " try:", " return re.match(r'.*?\\bmmx',self.info[0]['flags']) is not None", " except:", " pass" ] } }, { "old_path": "scipy_distutils/dist.py", "new_path": "scipy_distutils/dist.py", "filename": "dist.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -10,9 +10,51 @@ def __init__ (self, attrs=None):\n OldDistribution.__init__(self, attrs)\n \n def has_f_libraries(self):\n- print 'has_f_libraries'\n+ if self.fortran_libraries and len(self.fortran_libraries) > 0:\n+ return 1\n+ if hasattr(self,'_been_here_has_f_libraries'):\n+ return 0\n+ if self.has_ext_modules():\n+ # extension module sources may contain fortran files,\n+ # extract them to fortran_libraries.\n+ for ext in self.ext_modules:\n+ self.fortran_sources_to_flib(ext)\n+ self._been_here_has_f_libraries = None\n return self.fortran_libraries and len(self.fortran_libraries) > 0\n \n+ def fortran_sources_to_flib(self, ext):\n+ \"\"\"\n+ Extract fortran files from ext.sources and append them to\n+ fortran_libraries item having the same name as ext.\n+ \"\"\"\n+ sources = []\n+ f_files = []\n+ match = re.compile(r'.*[.](f90|f95|f77|for|ftn|f)\\Z',re.I).match\n+ for file in ext.sources:\n+ if match(file):\n+ f_files.append(file)\n+ else:\n+ sources.append(file)\n+ if not f_files:\n+ return\n+\n+ ext.sources = sources\n+\n+ if self.fortran_libraries is None:\n+ self.fortran_libraries = []\n+\n+ name = ext.name\n+ flib = None\n+ for n,d in self.fortran_libraries:\n+ if n == name:\n+ flib = d\n+ break\n+ if flib is None:\n+ flib = {'sources':[]}\n+ self.fortran_libraries.append((name,flib))\n+\n+ flib['sources'].extend(f_files)\n+\n def check_data_file_list(self):\n \"\"\"Ensure that the list of data_files (presumably provided as a\n command option 'data_files') is valid, i.e. it is a list of\n", "added_lines": 43, "deleted_lines": 1, "source_code": "from distutils.dist import *\nfrom distutils.dist import Distribution as OldDistribution\nfrom distutils.errors import DistutilsSetupError\n\nfrom types import *\n\nclass Distribution (OldDistribution):\n def __init__ (self, attrs=None):\n self.fortran_libraries = None\n OldDistribution.__init__(self, attrs)\n \n def has_f_libraries(self):\n if self.fortran_libraries and len(self.fortran_libraries) > 0:\n return 1\n if hasattr(self,'_been_here_has_f_libraries'):\n return 0\n if self.has_ext_modules():\n # extension module sources may contain fortran files,\n # extract them to fortran_libraries.\n for ext in self.ext_modules:\n self.fortran_sources_to_flib(ext)\n self._been_here_has_f_libraries = None\n return self.fortran_libraries and len(self.fortran_libraries) > 0\n\n def fortran_sources_to_flib(self, ext):\n \"\"\"\n Extract fortran files from ext.sources and append them to\n fortran_libraries item having the same name as ext.\n \"\"\"\n sources = []\n f_files = []\n match = re.compile(r'.*[.](f90|f95|f77|for|ftn|f)\\Z',re.I).match\n for file in ext.sources:\n if match(file):\n f_files.append(file)\n else:\n sources.append(file)\n if not f_files:\n return\n\n ext.sources = sources\n\n if self.fortran_libraries is None:\n self.fortran_libraries = []\n\n name = ext.name\n flib = None\n for n,d in self.fortran_libraries:\n if n == name:\n flib = d\n break\n if flib is None:\n flib = {'sources':[]}\n self.fortran_libraries.append((name,flib))\n\n flib['sources'].extend(f_files)\n\n def check_data_file_list(self):\n \"\"\"Ensure that the list of data_files (presumably provided as a\n command option 'data_files') is valid, i.e. it is a list of\n 2-tuples, where the tuples are (name, list_of_libraries).\n Raise DistutilsSetupError if the structure is invalid anywhere;\n just returns otherwise.\"\"\"\n print 'check_data_file_list'\n if type(self.data_files) is not ListType:\n raise DistutilsSetupError, \\\n \"'data_files' option must be a list of tuples\"\n\n for lib in self.data_files:\n if type(lib) is not TupleType and len(lib) != 2:\n raise DistutilsSetupError, \\\n \"each element of 'data_files' must a 2-tuple\"\n\n if type(lib[0]) is not StringType:\n raise DistutilsSetupError, \\\n \"first element of each tuple in 'data_files' \" + \\\n \"must be a string (the package with the data_file)\"\n\n if type(lib[1]) is not ListType:\n raise DistutilsSetupError, \\\n \"second element of each tuple in 'data_files' \" + \\\n \"must be a list of files.\"\n # for lib\n\n # check_data_file_list ()\n \n def get_data_files (self):\n print 'get_data_files'\n self.check_data_file_list()\n filenames = []\n \n # Gets data files specified\n for ext in self.data_files:\n filenames.extend(ext[1])\n\n return filenames\n", "source_code_before": "from distutils.dist import *\nfrom distutils.dist import Distribution as OldDistribution\nfrom distutils.errors import DistutilsSetupError\n\nfrom types import *\n\nclass Distribution (OldDistribution):\n def __init__ (self, attrs=None):\n self.fortran_libraries = None\n OldDistribution.__init__(self, attrs)\n \n def has_f_libraries(self):\n print 'has_f_libraries'\n return self.fortran_libraries and len(self.fortran_libraries) > 0\n\n def check_data_file_list(self):\n \"\"\"Ensure that the list of data_files (presumably provided as a\n command option 'data_files') is valid, i.e. it is a list of\n 2-tuples, where the tuples are (name, list_of_libraries).\n Raise DistutilsSetupError if the structure is invalid anywhere;\n just returns otherwise.\"\"\"\n print 'check_data_file_list'\n if type(self.data_files) is not ListType:\n raise DistutilsSetupError, \\\n \"'data_files' option must be a list of tuples\"\n\n for lib in self.data_files:\n if type(lib) is not TupleType and len(lib) != 2:\n raise DistutilsSetupError, \\\n \"each element of 'data_files' must a 2-tuple\"\n\n if type(lib[0]) is not StringType:\n raise DistutilsSetupError, \\\n \"first element of each tuple in 'data_files' \" + \\\n \"must be a string (the package with the data_file)\"\n\n if type(lib[1]) is not ListType:\n raise DistutilsSetupError, \\\n \"second element of each tuple in 'data_files' \" + \\\n \"must be a list of files.\"\n # for lib\n\n # check_data_file_list ()\n \n def get_data_files (self):\n print 'get_data_files'\n self.check_data_file_list()\n filenames = []\n \n # Gets data files specified\n for ext in self.data_files:\n filenames.extend(ext[1])\n\n return filenames\n", "methods": [ { "name": "__init__", "long_name": "__init__( self , attrs = None )", "filename": "dist.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self", "attrs" ], "start_line": 8, "end_line": 10, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "has_f_libraries", "long_name": "has_f_libraries( self )", "filename": "dist.py", "nloc": 10, "complexity": 7, "token_count": 69, "parameters": [ "self" ], "start_line": 12, "end_line": 23, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 12, "top_nesting_level": 1 }, { "name": "fortran_sources_to_flib", "long_name": "fortran_sources_to_flib( self , ext )", "filename": "dist.py", "nloc": 24, "complexity": 8, "token_count": 141, "parameters": [ "self", "ext" ], "start_line": 25, "end_line": 56, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 32, "top_nesting_level": 1 }, { "name": "check_data_file_list", "long_name": "check_data_file_list( self )", "filename": "dist.py", "nloc": 17, "complexity": 7, "token_count": 92, "parameters": [ "self" ], "start_line": 58, "end_line": 82, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 1 }, { "name": "get_data_files", "long_name": "get_data_files( self )", "filename": "dist.py", "nloc": 7, "complexity": 2, "token_count": 34, "parameters": [ "self" ], "start_line": 87, "end_line": 96, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 } ], "methods_before": [ { "name": "__init__", "long_name": "__init__( self , attrs = None )", "filename": "dist.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self", "attrs" ], "start_line": 8, "end_line": 10, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "has_f_libraries", "long_name": "has_f_libraries( self )", "filename": "dist.py", "nloc": 3, "complexity": 2, "token_count": 20, "parameters": [ "self" ], "start_line": 12, "end_line": 14, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_data_file_list", "long_name": "check_data_file_list( self )", "filename": "dist.py", "nloc": 17, "complexity": 7, "token_count": 92, "parameters": [ "self" ], "start_line": 16, "end_line": 40, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 1 }, { "name": "get_data_files", "long_name": "get_data_files( self )", "filename": "dist.py", "nloc": 7, "complexity": 2, "token_count": 34, "parameters": [ "self" ], "start_line": 45, "end_line": 54, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 } ], "changed_methods": [ { "name": "fortran_sources_to_flib", "long_name": "fortran_sources_to_flib( self , ext )", "filename": "dist.py", "nloc": 24, "complexity": 8, "token_count": 141, "parameters": [ "self", "ext" ], "start_line": 25, "end_line": 56, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 32, "top_nesting_level": 1 }, { "name": "has_f_libraries", "long_name": "has_f_libraries( self )", "filename": "dist.py", "nloc": 10, "complexity": 7, "token_count": 69, "parameters": [ "self" ], "start_line": 12, "end_line": 23, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 12, "top_nesting_level": 1 } ], "nloc": 66, "complexity": 25, "token_count": 393, "diff_parsed": { "added": [ " if self.fortran_libraries and len(self.fortran_libraries) > 0:", " return 1", " if hasattr(self,'_been_here_has_f_libraries'):", " return 0", " if self.has_ext_modules():", " # extension module sources may contain fortran files,", " # extract them to fortran_libraries.", " for ext in self.ext_modules:", " self.fortran_sources_to_flib(ext)", " self._been_here_has_f_libraries = None", " def fortran_sources_to_flib(self, ext):", " \"\"\"", " Extract fortran files from ext.sources and append them to", " fortran_libraries item having the same name as ext.", " \"\"\"", " sources = []", " f_files = []", " match = re.compile(r'.*[.](f90|f95|f77|for|ftn|f)\\Z',re.I).match", " for file in ext.sources:", " if match(file):", " f_files.append(file)", " else:", " sources.append(file)", " if not f_files:", " return", "", " ext.sources = sources", "", " if self.fortran_libraries is None:", " self.fortran_libraries = []", "", " name = ext.name", " flib = None", " for n,d in self.fortran_libraries:", " if n == name:", " flib = d", " break", " if flib is None:", " flib = {'sources':[]}", " self.fortran_libraries.append((name,flib))", "", " flib['sources'].extend(f_files)", "" ], "deleted": [ " print 'has_f_libraries'" ] } }, { "old_path": "scipy_distutils/setup.py", "new_path": "scipy_distutils/setup.py", "filename": "setup.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -13,7 +13,7 @@ def install_package():\n os.chdir(path)\n try:\n setup (name = \"scipy_distutils\",\n- version = \"0.1\",\n+ version = \"0.2\",\n description = \"Changes to distutils needed for SciPy -- mostly Fortran support\",\n author = \"Travis Oliphant, Eric Jones, and Pearu Peterson\",\n licence = \"BSD Style\",\n", "added_lines": 1, "deleted_lines": 1, "source_code": "#!/usr/bin/env python\nimport os\nfrom distutils.core import setup\nfrom misc_util import get_path \n \ndef install_package():\n \"\"\" Install the scipy_distutils. The dance with the current directory is done\n to fool distutils into thinking it is run from the scipy_distutils directory\n even if it was invoked from another script located in a different location.\n \"\"\"\n path = get_path(__name__)\n old_path = os.getcwd()\n os.chdir(path)\n try:\n setup (name = \"scipy_distutils\",\n version = \"0.2\",\n description = \"Changes to distutils needed for SciPy -- mostly Fortran support\",\n author = \"Travis Oliphant, Eric Jones, and Pearu Peterson\",\n licence = \"BSD Style\",\n url = 'http://www.scipy.org',\n packages = ['scipy_distutils','scipy_distutils.command'],\n package_dir = {'scipy_distutils':path}\n )\n finally:\n os.chdir(old_path)\n \nif __name__ == '__main__':\n install_package()\n", "source_code_before": "#!/usr/bin/env python\nimport os\nfrom distutils.core import setup\nfrom misc_util import get_path \n \ndef install_package():\n \"\"\" Install the scipy_distutils. The dance with the current directory is done\n to fool distutils into thinking it is run from the scipy_distutils directory\n even if it was invoked from another script located in a different location.\n \"\"\"\n path = get_path(__name__)\n old_path = os.getcwd()\n os.chdir(path)\n try:\n setup (name = \"scipy_distutils\",\n version = \"0.1\",\n description = \"Changes to distutils needed for SciPy -- mostly Fortran support\",\n author = \"Travis Oliphant, Eric Jones, and Pearu Peterson\",\n licence = \"BSD Style\",\n url = 'http://www.scipy.org',\n packages = ['scipy_distutils','scipy_distutils.command'],\n package_dir = {'scipy_distutils':path}\n )\n finally:\n os.chdir(old_path)\n \nif __name__ == '__main__':\n install_package()\n", "methods": [ { "name": "install_package", "long_name": "install_package( )", "filename": "setup.py", "nloc": 16, "complexity": 2, "token_count": 76, "parameters": [], "start_line": 6, "end_line": 25, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 } ], "methods_before": [ { "name": "install_package", "long_name": "install_package( )", "filename": "setup.py", "nloc": 16, "complexity": 2, "token_count": 76, "parameters": [], "start_line": 6, "end_line": 25, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "install_package", "long_name": "install_package( )", "filename": "setup.py", "nloc": 16, "complexity": 2, "token_count": 76, "parameters": [], "start_line": 6, "end_line": 25, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 } ], "nloc": 21, "complexity": 2, "token_count": 97, "diff_parsed": { "added": [ " version = \"0.2\"," ], "deleted": [ " version = \"0.1\"," ] } } ] }, { "hash": "b63f8e5ed4d3276640e73072fd4b074d357d45e5", "msg": "fixed get_opt for NAG compiler", "author": { "name": "Pearu Peterson", "email": "pearu.peterson@gmail.com" }, "committer": { "name": "Pearu Peterson", "email": "pearu.peterson@gmail.com" }, "author_date": "2002-01-04T10:10:32+00:00", "author_timezone": 0, "committer_date": "2002-01-04T10:10:32+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "424101955d2f074aa32b21ac24bad2d767936094" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 0, "insertions": 1, "lines": 1, "files": 1, "dmm_unit_size": 1.0, "dmm_unit_complexity": 1.0, "dmm_unit_interfacing": 1.0, "modified_files": [ { "old_path": "scipy_distutils/command/build_flib.py", "new_path": "scipy_distutils/command/build_flib.py", "filename": "build_flib.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -719,6 +719,7 @@ def __init__(self, fc = None, f90c = None):\n \n def get_opt(self):\n opt = ' -O4 -target=native '\n+ return opt\n \n def get_linker_so(self):\n return [self.f77_compiler,'-Wl,-shared']\n", "added_lines": 1, "deleted_lines": 0, "source_code": "\"\"\" Implements the build_flib command which should go into Distutils\n at some point.\n \n Note:\n Right now, we're dynamically linking to the Fortran libraries on \n some platforms (Sun for sure). This is fine for local installations\n but a bad thing for redistribution because these libraries won't\n live on any machine that doesn't have a fortran compiler installed.\n It is pretty hard (impossible?) to get gcc to pass the right compiler\n flags on Sun to get the linker to use static libs for the fortran\n stuff. Investigate further...\n\nBugs:\n *** Options -e and -x have no effect when used with --help-compiler\n options. E.g. \n ./setup.py build_flib --help-compiler -e g77-3.0\n finds g77-2.95.\n How to extract these options inside the show_compilers function?\n *** Option --force has no effect when switching a compiler. One must\n manually remove .o files that were generated earlier by a\n different compiler.\n *** compiler.is_available() method may not work correctly on nt\n because of lack of knowledge how to get exit status in\n run_command function. However, it may give reasonable results\n based on a version string.\n *** Some vendors provide different compilers for F77 and F90\n compilations. Currently, checking the availability of these\n compilers is based on only checking the availability of the\n corresponding F77 compiler. If it exists, then F90 is assumed\n to exist also.\n\nOpen issues:\n *** User-defined compiler flags. Do we need --fflags?\n\nFortran compilers (as to be used with --fcompiler= option):\n Absoft\n Sun\n SGI\n Gnu\n Intel\n Itanium\n NAG\n VAST\n\"\"\"\n\nimport distutils\nimport distutils.dep_util, distutils.dir_util\nimport os,sys,string\nimport commands,re\nfrom types import *\nfrom distutils.command.build_clib import build_clib\nfrom distutils.errors import *\n\nif os.name == 'nt':\n def run_command(command):\n \"\"\" not sure how to get exit status on nt. \"\"\"\n in_pipe,out_pipe = os.popen4(command)\n in_pipe.close()\n text = out_pipe.read()\n return 0, text\nelse:\n run_command = commands.getstatusoutput\n \ndef show_compilers():\n for compiler_class in all_compilers:\n compiler = compiler_class()\n if compiler.is_available():\n print compiler\n\nclass build_flib (build_clib):\n\n description = \"build f77/f90 libraries used by Python extensions\"\n\n user_options = [\n ('build-flib', 'b',\n \"directory to build f77/f90 libraries to\"),\n ('build-temp', 't',\n \"directory to put temporary build by-products\"),\n ('debug', 'g',\n \"compile with debugging information\"),\n ('force', 'f',\n \"forcibly build everything (ignore file timestamps)\"),\n ('fcompiler=', 'c',\n \"specify the compiler type\"),\n ('fcompiler-exec=', 'e',\n \"specify the path to F77 compiler\"),\n ('f90compiler-exec=', 'x',\n \"specify the path to F90 compiler\"),\n ]\n\n boolean_options = ['debug', 'force']\n\n help_options = [\n ('help-compiler', None,\n \"list available compilers\", show_compilers),\n ]\n\n def initialize_options (self):\n\n self.build_flib = None\n self.build_temp = None\n\n self.fortran_libraries = None\n self.define = None\n self.undef = None\n self.debug = None\n self.force = 0\n self.fcompiler = None\n self.fcompiler_exec = None\n self.f90compiler_exec = None\n\n # initialize_options()\n\n def finalize_options (self):\n self.set_undefined_options('build',\n ('build_temp', 'build_flib'),\n ('build_temp', 'build_temp'),\n ('debug', 'debug'),\n ('force', 'force'))\n fc = find_fortran_compiler(self.fcompiler,\n self.fcompiler_exec,\n self.f90compiler_exec)\n if not fc:\n raise DistutilsOptionError, 'Fortran compiler not available: %s'%(self.fcompiler)\n else:\n self.announce(' using %s Fortran compiler' % fc)\n self.fcompiler = fc\n if self.has_f_libraries():\n self.fortran_libraries = self.distribution.fortran_libraries\n self.check_library_list(self.fortran_libraries)\n\n # finalize_options()\n\n def has_f_libraries(self):\n return self.distribution.has_f_libraries()\n\n def run (self):\n if not self.has_f_libraries():\n return\n self.build_libraries(self.fortran_libraries)\n\n # run ()\n\n def get_library_names(self):\n if not self.has_f_libraries():\n return None\n\n lib_names = [] \n\n for (lib_name, build_info) in self.fortran_libraries:\n lib_names.append(lib_name)\n\n if self.fcompiler is not None:\n lib_names.extend(self.fcompiler.get_libraries())\n \n return lib_names\n\n # get_library_names ()\n\n def get_library_dirs(self):\n if not self.has_f_libraries():\n return []#None\n\n lib_dirs = [] \n\n if self.fcompiler is not None:\n lib_dirs.extend(self.fcompiler.get_library_dirs())\n \n return lib_dirs\n\n # get_library_dirs ()\n\n def get_runtime_library_dirs(self):\n if not self.has_f_libraries():\n return []#None\n\n lib_dirs = [] \n\n if self.fcompiler is not None:\n lib_dirs.extend(self.fcompiler.get_runtime_library_dirs())\n \n return lib_dirs\n\n # get_library_dirs ()\n\n def get_source_files (self):\n self.check_library_list(self.fortran_libraries)\n filenames = []\n\n # Gets source files specified \n for ext in self.fortran_libraries:\n filenames.extend(ext[1]['sources'])\n\n return filenames \n \n def build_libraries (self, fortran_libraries):\n \n fcompiler = self.fcompiler\n \n for (lib_name, build_info) in fortran_libraries:\n sources = build_info.get('sources')\n if sources is None or type(sources) not in (ListType, TupleType):\n raise DistutilsSetupError, \\\n (\"in 'fortran_libraries' option (library '%s'), \" +\n \"'sources' must be present and must be \" +\n \"a list of source filenames\") % lib_name\n sources = list(sources)\n module_dirs = build_info.get('module_dirs')\n module_files = build_info.get('module_files')\n self.announce(\" building '%s' library\" % lib_name)\n \n if module_files:\n fcompiler.build_library(lib_name, module_files,\n temp_dir=self.build_temp)\n \n fcompiler.build_library(lib_name, sources,\n module_dirs, temp_dir=self.build_temp)\n\n # for loop\n\n # build_libraries ()\n\n\nclass fortran_compiler_base:\n\n vendor = None\n ver_match = None\n \n def __init__(self):\n # Default initialization. Constructors of derived classes MUST\n # call this functions.\n self.version = None\n \n self.f77_switches = ''\n self.f77_opt = ''\n self.f77_debug = ''\n \n self.f90_switches = ''\n self.f90_opt = ''\n self.f90_debug = ''\n \n self.libraries = []\n self.library_dirs = []\n\n if self.vendor is None:\n raise DistutilsInternalError,\\\n '%s must define vendor attribute'%(self.__class__)\n if self.ver_match is None:\n raise DistutilsInternalError,\\\n '%s must define ver_match attribute'%(self.__class__)\n\n def to_object(self,dirty_files,module_dirs=None, temp_dir=''):\n files = string.join(dirty_files)\n f90_files = get_f90_files(dirty_files)\n f77_files = get_f77_files(dirty_files)\n if f90_files != []:\n obj1 = self.f90_compile(f90_files,module_dirs,temp_dir = temp_dir)\n else:\n obj1 = []\n if f77_files != []:\n obj2 = self.f77_compile(f77_files, temp_dir = temp_dir)\n else:\n obj2 = []\n return obj1 + obj2\n\n def source_to_object_names(self,source_files, temp_dir=''):\n file_list = map(lambda x: os.path.basename(x),source_files)\n file_base_ext = map(lambda x: os.path.splitext(x),file_list)\n object_list = map(lambda x: x[0] +'.o',file_base_ext)\n object_files = map(lambda x,td=temp_dir: os.path.join(td,x),object_list)\n return object_files\n \n def source_and_object_pairs(self,source_files, temp_dir=''):\n object_files = self.source_to_object_names(source_files,temp_dir)\n file_pairs = zip(source_files,object_files)\n return file_pairs\n \n def f_compile(self,compiler,switches, source_files,\n module_dirs=None, temp_dir=''):\n module_switch = self.build_module_switch(module_dirs)\n file_pairs = self.source_and_object_pairs(source_files,temp_dir)\n object_files = []\n for source,object in file_pairs:\n if distutils.dep_util.newer(source,object):\n cmd = compiler + ' ' + switches + \\\n module_switch + ' -c ' + source + ' -o ' + object \n print cmd\n failure = os.system(cmd)\n if failure:\n raise ValueError, 'failure during compile' \n object_files.append(object)\n return object_files\n #return all object files to make sure everything is archived \n #return map(lambda x: x[1], file_pairs)\n\n def f90_compile(self,source_files,module_dirs=None, temp_dir=''):\n switches = string.join((self.f90_switches, self.f90_opt))\n return self.f_compile(self.f90_compiler,switches,\n source_files, module_dirs,temp_dir)\n\n def f77_compile(self,source_files,module_dirs=None, temp_dir=''):\n switches = string.join((self.f77_switches, self.f77_opt))\n return self.f_compile(self.f77_compiler,switches,\n source_files, module_dirs,temp_dir)\n\n\n def build_module_switch(self, module_dirs):\n return ''\n\n def create_static_lib(self, object_files, library_name,\n output_dir='', debug=None):\n lib_file = os.path.join(output_dir,'lib'+library_name+'.a')\n newer = distutils.dep_util.newer\n # This doesn't work -- no way to know if the file is in the archive\n #object_files = filter(lambda o,lib=lib_file:\\\n # distutils.dep_util.newer(o,lib),object_files)\n objects = string.join(object_files)\n if objects:\n cmd = 'ar -cur %s %s' % (lib_file,objects)\n print cmd\n os.system(cmd)\n\n def build_library(self,library_name,source_list,module_dirs=None,\n temp_dir = ''):\n #make sure the temp directory exists before trying to build files\n import distutils.dir_util\n distutils.dir_util.mkpath(temp_dir)\n #this compiles the files\n object_list = self.to_object(source_list,module_dirs,temp_dir)\n # actually we need to use all the object file names here to\n # make sure the library is always built. It could occur that an\n # object file exists but hasn't been put in the archive. (happens\n # a lot when builds fail once and are restarted).\n object_list = self.source_to_object_names(source_list, temp_dir)\n #self.create_static_lib(object_list,library_name,temp_dir) \n # This is pure bunk...\n # Windows fails for long argument strings on the command line.\n # if objects is real long (> 2048 chars or so on my machine),\n # the command fails (cmd.exe /e:2048 on w2k)\n # for now we'll split linking into to steps which should work for\n objects = object_list[:]\n while objects:\n obj,objects = objects[:20],objects[20:]\n self.create_static_lib(obj,library_name,temp_dir)\n\n def dummy_fortran_files(self):\n import tempfile \n d = tempfile.gettempdir()\n dummy_name = os.path.join(d,'__dummy.f')\n dummy = open(dummy_name,'w')\n dummy.write(\" subroutine dummy()\\n end\\n\")\n dummy.close()\n return (os.path.join(d,'__dummy.f'),os.path.join(d,'__dummy.o'))\n \n def is_available(self):\n return self.get_version()\n \n def get_version(self):\n \"\"\"Return the compiler version. If compiler is not available,\n return empty string.\"\"\"\n # XXX: Is there compilers that have no version? If yes,\n # this test will fail even if the compiler is available.\n if self.version is not None:\n # Finding version is expensive, so return previously found\n # version string.\n return self.version\n self.version = ''\n # works I think only for unix... \n #print 'command:', self.ver_cmd\n exit_status, out_text = run_command(self.ver_cmd)\n #print exit_status, out_text\n if not exit_status:\n m = re.match(self.ver_match,out_text)\n if m:\n self.version = m.group('version')\n return self.version\n\n def get_libraries(self):\n return self.libraries\n def get_library_dirs(self):\n return self.library_dirs\n def get_extra_link_args(self):\n return []\n def get_runtime_library_dirs(self):\n return []\n def get_linker_so(self):\n \"\"\"\n If a compiler requires specific linker then return a list\n containing a linker executable name and linker options.\n Otherwise, return None.\n \"\"\"\n\n def __str__(self):\n return \"%s %s\" % (self.vendor, self.get_version())\n\n\nclass absoft_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Absoft'\n ver_match = r'FORTRAN 77 Compiler (?P[^\\s*,]*).*?Absoft Corp'\n \n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n # got rid of -B108 cause it was generating 2 underscores instead\n # of one on the newest version. Now we use -YEXT_SFX=_ to \n # specify the output format\n if os.name == 'nt':\n self.f90_switches = '-f fixed -YCFRL=1 -YCOM_NAMES=LCS' \\\n ' -YCOM_PFX -YEXT_PFX -YEXT_NAMES=LCS' \\\n ' -YCOM_SFX=_ -YEXT_SFX=_ -YEXT_NAMES=LCS' \n self.f90_opt = '-O -Q100'\n self.f77_switches = '-N22 -N90 -N110'\n self.f77_opt = '-O -Q100'\n self.libraries = ['fio', 'fmath', 'f90math', 'COMDLG32']\n else:\n self.f90_switches = '-ffixed -YCFRL=1 -YCOM_NAMES=LCS' \\\n ' -YCOM_PFX -YEXT_PFX -YEXT_NAMES=LCS' \\\n ' -YCOM_SFX=_ -YEXT_SFX=_ -YEXT_NAMES=LCS' \n self.f90_opt = '-O -B101' \n self.f77_switches = '-N22 -N90 -N110 -B108'\n self.f77_opt = '-O -B101'\n\n self.libraries = ['fio', 'f77math', 'f90math']\n \n try:\n dir = os.environ['ABSOFT'] \n self.library_dirs = [os.path.join(dir,'lib')]\n except KeyError:\n self.library_dirs = []\n\n self.ver_cmd = self.f77_compiler + ' -V -c %s -o %s' % \\\n self.dummy_fortran_files()\n\n def build_module_switch(self,module_dirs):\n res = ''\n if module_dirs:\n for mod in module_dirs:\n res = res + ' -p' + mod\n return res\n\n def get_extra_link_args(self):\n return []\n # Couldn't get this to link for anything using gcc.\n #dr = \"c:\\\\Absoft62\\\\lib\"\n #libs = ['fio.lib', 'COMDLG32.lib','fmath.lib', 'f90math.lib','libcomdlg32.a' ] \n #libs = map(lambda x,dr=dr:os.path.join(dr,x),libs)\n #return libs\n\n\nclass sun_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Sun'\n ver_match = r'f77: (?P[^\\s*,]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc # not tested\n self.f77_switches = ' -pic '\n self.f77_opt = ' -fast -dalign '\n\n self.f90_compiler = f90c\n self.f90_switches = ' -fixed ' # ??? why fixed?\n self.f90_opt = ' -fast -dalign '\n\n self.libraries = ['f90', 'F77', 'M77', 'sunmath', 'm']\n #threaded\n #self.libraries = ['f90', 'F77_mt', 'sunmath_mt', 'm', 'thread']\n #self.libraries = []\n self.library_dirs = self.find_lib_dir()\n #print 'sun:',self.library_dirs\n\n self.ver_cmd = self.f77_compiler + ' -V'\n\n def build_module_switch(self,module_dirs):\n res = ''\n if module_dirs:\n for mod in module_dirs:\n res = res + ' -M' + mod\n return res\n\n def find_lib_dir(self):\n library_dirs = []\n lib_match = r'### f90: Note: LD_RUN_PATH\\s*= '\\\n '(?P[^\\s.]*).*'\n cmd = self.f90_compiler + ' -dryrun dummy.f'\n exit_status, output = run_command(cmd)\n if not exit_status:\n libs = re.findall(lib_match,output)\n if libs:\n library_dirs = string.split(libs[0],':')\n self.get_version() # force version calculation\n compiler_home = os.path.dirname(library_dirs[0])\n library_dirs.append(os.path.join(compiler_home,\n self.version,'lib'))\n return library_dirs\n def get_runtime_library_dirs(self):\n return self.find_lib_dir()\n def get_extra_link_args(self):\n return ['-mimpure-text']\n\n\nclass mips_fortran_compiler(fortran_compiler_base):\n\n vendor = 'SGI'\n ver_match = r'MIPSpro Compilers: Version (?P[^\\s*,]*)'\n \n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc # not tested\n self.f77_switches = ' -n32 -KPIC '\n self.f77_opt = ' -O3 '\n\n self.f90_compiler = f90c\n self.f90_switches = ' -n32 -KPIC -fixedform ' # why fixed ???\n self.f90_opt = ' ' \n \n self.libraries = ['fortran', 'ftn', 'm']\n self.library_dirs = self.find_lib_dir()\n\n self.ver_cmd = self.f77_compiler + ' -version'\n\n def build_module_switch(self,module_dirs):\n res = ''\n return res \n def find_lib_dir(self):\n library_dirs = []\n return library_dirs\n def get_runtime_library_dirs(self):\n\treturn self.find_lib_dir() \n def get_extra_link_args(self):\n\treturn []\n\n\nclass gnu_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Gnu'\n ver_match = r'g77 version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if sys.platform == 'win32':\n self.libraries = ['gcc','g2c']\n self.library_dirs = self.find_lib_directories()\n\n if fc is None:\n fc = 'g77'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n\n switches = ' -Wall -fno-second-underscore '\n\n if os.name != 'nt':\n switches = switches + ' -fpic '\n\n self.f77_switches = switches\n\n self.ver_cmd = self.f77_compiler + ' -v '\n self.f77_opt = self.get_opt()\n\n def get_opt(self):\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n opt = ' -O3 -funroll-loops '\n \n # only check for more optimization if g77 can handle\n # it.\n if self.get_version():\n if self.version[0]=='3': # is g77 3.x.x\n if cpu.is_AthlonK6():\n opt = opt + ' -march=k6 '\n elif cpu.is_AthlonK7():\n opt = opt + ' -march=athlon '\n if cpu.is_i686():\n opt = opt + ' -march=i686 '\n elif cpu.is_i586():\n opt = opt + ' -march=i586 '\n elif cpu.is_i486():\n opt = opt + ' -march=i486 '\n elif cpu.is_i386():\n opt = opt + ' -march=i386 '\n if cpu.is_Intel():\n opt = opt + ' -malign-double ' \n return opt\n \n def find_lib_directories(self):\n lib_dir = []\n match = r'Reading specs from (.*)/specs'\n\n # works I think only for unix... \n exit_status, out_text = run_command('g77 -v')\n if not exit_status:\n m = re.findall(match,out_text)\n if m:\n lib_dir= m #m[0] \n return lib_dir\n\n def get_linker_so(self):\n # win32 linking should be handled by standard linker\n if sys.platform != 'win32':\n return [self.f77_compiler,'-shared']\n \n def f90_compile(self,source_files,module_files,temp_dir=''):\n raise DistutilsExecError, 'f90 not supported by Gnu'\n\n\n#http://developer.intel.com/software/products/compilers/f50/linux/\nclass intel_ia32_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Intel' # Intel(R) Corporation \n ver_match = r'Intel\\(R\\) Fortran Compiler for 32-bit applications, Version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'ifc'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n switches = ' -KPIC '\n\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n if cpu.has_fdiv_bug():\n switches = switches + ' -fdiv_check '\n if cpu.has_f00f_bug():\n switches = switches + ' -0f_check '\n self.f77_switches = self.f90_switches = switches\n self.f77_switches = self.f77_switches + ' -FI '\n\n self.f77_opt = self.f90_opt = self.get_opt()\n \n debug = ' -g -C '\n self.f77_debug = self.f90_debug = debug\n\n self.ver_cmd = self.f77_compiler+' -FI -V -c %s -o %s' %\\\n self.dummy_fortran_files()\n\n def get_opt(self):\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n opt = ' -O3 '\n if cpu.is_PentiumPro() or cpu.is_PentiumII():\n opt = opt + ' -tpp6 -xi '\n elif cpu.is_PentiumIII():\n opt = opt + ' -tpp6 '\n elif cpu.is_Pentium():\n opt = opt + ' -tpp5 '\n elif cpu.is_PentiumIV():\n opt = opt + ' -tpp7 -xW '\n elif cpu.has_mmx():\n opt = opt + ' -xM '\n return opt\n \n\n def get_linker_so(self):\n return [self.f77_compiler,'-shared']\n\n\nclass intel_itanium_fortran_compiler(intel_ia32_fortran_compiler):\n\n vendor = 'Itanium'\n ver_match = r'Intel\\(R\\) Fortran 90 Compiler Itanium\\(TM\\) Compiler for the Itanium\\(TM\\)-based applications, Version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n if fc is None:\n fc = 'efc'\n intel_ia32_fortran_compiler.__init__(self, fc, f90c)\n\n\nclass nag_fortran_compiler(fortran_compiler_base):\n\n vendor = 'NAG'\n ver_match = r'NAGWare Fortran 95 compiler Release (?P[^\\s]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'f95'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n switches = ''\n debug = ' -g -gline -g90 -nan -C '\n\n self.f77_switches = self.f90_switches = switches\n self.f77_switches = self.f77_switches + ' -fixed '\n self.f77_debug = self.f90_debug = debug\n self.f77_opt = self.f90_opt = self.get_opt()\n\n self.ver_cmd = self.f77_compiler+' -V '\n\n def get_opt(self):\n opt = ' -O4 -target=native '\n return opt\n\n def get_linker_so(self):\n return [self.f77_compiler,'-Wl,-shared']\n\n\nclass vast_fortran_compiler(fortran_compiler_base):\n\n vendor = 'VAST'\n ver_match = r'\\s*Pacific-Sierra Research vf90 (Personal|Professional)\\s+(?P[^\\s]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'g77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n d,b = os.path.split(f90c)\n vf90 = os.path.join(d,'v'+b)\n self.ver_cmd = vf90+' -v '\n\n gnu = gnu_fortran_compiler(fc)\n if not gnu.is_available(): # VAST compiler requires g77.\n self.version = ''\n return\n if not self.is_available():\n return\n\n self.f77_switches = gnu.f77_switches\n self.f77_debug = gnu.f77_debug\n self.f77_opt = gnu.f77_opt \n\n # XXX: need f90 switches, debug, opt\n\n def get_linker_so(self):\n return [self.f90_compiler,'-shared']\n\n\ndef match_extension(files,ext):\n match = re.compile(r'.*[.]('+ext+r')\\Z',re.I).match\n return filter(lambda x,match = match: match(x),files)\n\ndef get_f77_files(files):\n return match_extension(files,'for|f77|ftn|f')\n\ndef get_f90_files(files):\n return match_extension(files,'f90|f95')\n\ndef get_fortran_files(files):\n return match_extension(files,'f90|f95|for|f77|ftn|f')\n\ndef find_fortran_compiler(vendor = None, fc = None, f90c = None):\n fcompiler = None\n for compiler_class in all_compilers:\n if vendor is not None and vendor != compiler_class.vendor:\n continue\n print compiler_class\n compiler = compiler_class(fc,f90c)\n if compiler.is_available():\n fcompiler = compiler\n break\n return fcompiler\n\nall_compilers = [absoft_fortran_compiler,\n mips_fortran_compiler,\n sun_fortran_compiler,\n gnu_fortran_compiler,\n intel_ia32_fortran_compiler,\n intel_itanium_fortran_compiler,\n nag_fortran_compiler,\n vast_fortran_compiler,\n ]\n\nif __name__ == \"__main__\":\n show_compilers()\n", "source_code_before": "\"\"\" Implements the build_flib command which should go into Distutils\n at some point.\n \n Note:\n Right now, we're dynamically linking to the Fortran libraries on \n some platforms (Sun for sure). This is fine for local installations\n but a bad thing for redistribution because these libraries won't\n live on any machine that doesn't have a fortran compiler installed.\n It is pretty hard (impossible?) to get gcc to pass the right compiler\n flags on Sun to get the linker to use static libs for the fortran\n stuff. Investigate further...\n\nBugs:\n *** Options -e and -x have no effect when used with --help-compiler\n options. E.g. \n ./setup.py build_flib --help-compiler -e g77-3.0\n finds g77-2.95.\n How to extract these options inside the show_compilers function?\n *** Option --force has no effect when switching a compiler. One must\n manually remove .o files that were generated earlier by a\n different compiler.\n *** compiler.is_available() method may not work correctly on nt\n because of lack of knowledge how to get exit status in\n run_command function. However, it may give reasonable results\n based on a version string.\n *** Some vendors provide different compilers for F77 and F90\n compilations. Currently, checking the availability of these\n compilers is based on only checking the availability of the\n corresponding F77 compiler. If it exists, then F90 is assumed\n to exist also.\n\nOpen issues:\n *** User-defined compiler flags. Do we need --fflags?\n\nFortran compilers (as to be used with --fcompiler= option):\n Absoft\n Sun\n SGI\n Gnu\n Intel\n Itanium\n NAG\n VAST\n\"\"\"\n\nimport distutils\nimport distutils.dep_util, distutils.dir_util\nimport os,sys,string\nimport commands,re\nfrom types import *\nfrom distutils.command.build_clib import build_clib\nfrom distutils.errors import *\n\nif os.name == 'nt':\n def run_command(command):\n \"\"\" not sure how to get exit status on nt. \"\"\"\n in_pipe,out_pipe = os.popen4(command)\n in_pipe.close()\n text = out_pipe.read()\n return 0, text\nelse:\n run_command = commands.getstatusoutput\n \ndef show_compilers():\n for compiler_class in all_compilers:\n compiler = compiler_class()\n if compiler.is_available():\n print compiler\n\nclass build_flib (build_clib):\n\n description = \"build f77/f90 libraries used by Python extensions\"\n\n user_options = [\n ('build-flib', 'b',\n \"directory to build f77/f90 libraries to\"),\n ('build-temp', 't',\n \"directory to put temporary build by-products\"),\n ('debug', 'g',\n \"compile with debugging information\"),\n ('force', 'f',\n \"forcibly build everything (ignore file timestamps)\"),\n ('fcompiler=', 'c',\n \"specify the compiler type\"),\n ('fcompiler-exec=', 'e',\n \"specify the path to F77 compiler\"),\n ('f90compiler-exec=', 'x',\n \"specify the path to F90 compiler\"),\n ]\n\n boolean_options = ['debug', 'force']\n\n help_options = [\n ('help-compiler', None,\n \"list available compilers\", show_compilers),\n ]\n\n def initialize_options (self):\n\n self.build_flib = None\n self.build_temp = None\n\n self.fortran_libraries = None\n self.define = None\n self.undef = None\n self.debug = None\n self.force = 0\n self.fcompiler = None\n self.fcompiler_exec = None\n self.f90compiler_exec = None\n\n # initialize_options()\n\n def finalize_options (self):\n self.set_undefined_options('build',\n ('build_temp', 'build_flib'),\n ('build_temp', 'build_temp'),\n ('debug', 'debug'),\n ('force', 'force'))\n fc = find_fortran_compiler(self.fcompiler,\n self.fcompiler_exec,\n self.f90compiler_exec)\n if not fc:\n raise DistutilsOptionError, 'Fortran compiler not available: %s'%(self.fcompiler)\n else:\n self.announce(' using %s Fortran compiler' % fc)\n self.fcompiler = fc\n if self.has_f_libraries():\n self.fortran_libraries = self.distribution.fortran_libraries\n self.check_library_list(self.fortran_libraries)\n\n # finalize_options()\n\n def has_f_libraries(self):\n return self.distribution.has_f_libraries()\n\n def run (self):\n if not self.has_f_libraries():\n return\n self.build_libraries(self.fortran_libraries)\n\n # run ()\n\n def get_library_names(self):\n if not self.has_f_libraries():\n return None\n\n lib_names = [] \n\n for (lib_name, build_info) in self.fortran_libraries:\n lib_names.append(lib_name)\n\n if self.fcompiler is not None:\n lib_names.extend(self.fcompiler.get_libraries())\n \n return lib_names\n\n # get_library_names ()\n\n def get_library_dirs(self):\n if not self.has_f_libraries():\n return []#None\n\n lib_dirs = [] \n\n if self.fcompiler is not None:\n lib_dirs.extend(self.fcompiler.get_library_dirs())\n \n return lib_dirs\n\n # get_library_dirs ()\n\n def get_runtime_library_dirs(self):\n if not self.has_f_libraries():\n return []#None\n\n lib_dirs = [] \n\n if self.fcompiler is not None:\n lib_dirs.extend(self.fcompiler.get_runtime_library_dirs())\n \n return lib_dirs\n\n # get_library_dirs ()\n\n def get_source_files (self):\n self.check_library_list(self.fortran_libraries)\n filenames = []\n\n # Gets source files specified \n for ext in self.fortran_libraries:\n filenames.extend(ext[1]['sources'])\n\n return filenames \n \n def build_libraries (self, fortran_libraries):\n \n fcompiler = self.fcompiler\n \n for (lib_name, build_info) in fortran_libraries:\n sources = build_info.get('sources')\n if sources is None or type(sources) not in (ListType, TupleType):\n raise DistutilsSetupError, \\\n (\"in 'fortran_libraries' option (library '%s'), \" +\n \"'sources' must be present and must be \" +\n \"a list of source filenames\") % lib_name\n sources = list(sources)\n module_dirs = build_info.get('module_dirs')\n module_files = build_info.get('module_files')\n self.announce(\" building '%s' library\" % lib_name)\n \n if module_files:\n fcompiler.build_library(lib_name, module_files,\n temp_dir=self.build_temp)\n \n fcompiler.build_library(lib_name, sources,\n module_dirs, temp_dir=self.build_temp)\n\n # for loop\n\n # build_libraries ()\n\n\nclass fortran_compiler_base:\n\n vendor = None\n ver_match = None\n \n def __init__(self):\n # Default initialization. Constructors of derived classes MUST\n # call this functions.\n self.version = None\n \n self.f77_switches = ''\n self.f77_opt = ''\n self.f77_debug = ''\n \n self.f90_switches = ''\n self.f90_opt = ''\n self.f90_debug = ''\n \n self.libraries = []\n self.library_dirs = []\n\n if self.vendor is None:\n raise DistutilsInternalError,\\\n '%s must define vendor attribute'%(self.__class__)\n if self.ver_match is None:\n raise DistutilsInternalError,\\\n '%s must define ver_match attribute'%(self.__class__)\n\n def to_object(self,dirty_files,module_dirs=None, temp_dir=''):\n files = string.join(dirty_files)\n f90_files = get_f90_files(dirty_files)\n f77_files = get_f77_files(dirty_files)\n if f90_files != []:\n obj1 = self.f90_compile(f90_files,module_dirs,temp_dir = temp_dir)\n else:\n obj1 = []\n if f77_files != []:\n obj2 = self.f77_compile(f77_files, temp_dir = temp_dir)\n else:\n obj2 = []\n return obj1 + obj2\n\n def source_to_object_names(self,source_files, temp_dir=''):\n file_list = map(lambda x: os.path.basename(x),source_files)\n file_base_ext = map(lambda x: os.path.splitext(x),file_list)\n object_list = map(lambda x: x[0] +'.o',file_base_ext)\n object_files = map(lambda x,td=temp_dir: os.path.join(td,x),object_list)\n return object_files\n \n def source_and_object_pairs(self,source_files, temp_dir=''):\n object_files = self.source_to_object_names(source_files,temp_dir)\n file_pairs = zip(source_files,object_files)\n return file_pairs\n \n def f_compile(self,compiler,switches, source_files,\n module_dirs=None, temp_dir=''):\n module_switch = self.build_module_switch(module_dirs)\n file_pairs = self.source_and_object_pairs(source_files,temp_dir)\n object_files = []\n for source,object in file_pairs:\n if distutils.dep_util.newer(source,object):\n cmd = compiler + ' ' + switches + \\\n module_switch + ' -c ' + source + ' -o ' + object \n print cmd\n failure = os.system(cmd)\n if failure:\n raise ValueError, 'failure during compile' \n object_files.append(object)\n return object_files\n #return all object files to make sure everything is archived \n #return map(lambda x: x[1], file_pairs)\n\n def f90_compile(self,source_files,module_dirs=None, temp_dir=''):\n switches = string.join((self.f90_switches, self.f90_opt))\n return self.f_compile(self.f90_compiler,switches,\n source_files, module_dirs,temp_dir)\n\n def f77_compile(self,source_files,module_dirs=None, temp_dir=''):\n switches = string.join((self.f77_switches, self.f77_opt))\n return self.f_compile(self.f77_compiler,switches,\n source_files, module_dirs,temp_dir)\n\n\n def build_module_switch(self, module_dirs):\n return ''\n\n def create_static_lib(self, object_files, library_name,\n output_dir='', debug=None):\n lib_file = os.path.join(output_dir,'lib'+library_name+'.a')\n newer = distutils.dep_util.newer\n # This doesn't work -- no way to know if the file is in the archive\n #object_files = filter(lambda o,lib=lib_file:\\\n # distutils.dep_util.newer(o,lib),object_files)\n objects = string.join(object_files)\n if objects:\n cmd = 'ar -cur %s %s' % (lib_file,objects)\n print cmd\n os.system(cmd)\n\n def build_library(self,library_name,source_list,module_dirs=None,\n temp_dir = ''):\n #make sure the temp directory exists before trying to build files\n import distutils.dir_util\n distutils.dir_util.mkpath(temp_dir)\n #this compiles the files\n object_list = self.to_object(source_list,module_dirs,temp_dir)\n # actually we need to use all the object file names here to\n # make sure the library is always built. It could occur that an\n # object file exists but hasn't been put in the archive. (happens\n # a lot when builds fail once and are restarted).\n object_list = self.source_to_object_names(source_list, temp_dir)\n #self.create_static_lib(object_list,library_name,temp_dir) \n # This is pure bunk...\n # Windows fails for long argument strings on the command line.\n # if objects is real long (> 2048 chars or so on my machine),\n # the command fails (cmd.exe /e:2048 on w2k)\n # for now we'll split linking into to steps which should work for\n objects = object_list[:]\n while objects:\n obj,objects = objects[:20],objects[20:]\n self.create_static_lib(obj,library_name,temp_dir)\n\n def dummy_fortran_files(self):\n import tempfile \n d = tempfile.gettempdir()\n dummy_name = os.path.join(d,'__dummy.f')\n dummy = open(dummy_name,'w')\n dummy.write(\" subroutine dummy()\\n end\\n\")\n dummy.close()\n return (os.path.join(d,'__dummy.f'),os.path.join(d,'__dummy.o'))\n \n def is_available(self):\n return self.get_version()\n \n def get_version(self):\n \"\"\"Return the compiler version. If compiler is not available,\n return empty string.\"\"\"\n # XXX: Is there compilers that have no version? If yes,\n # this test will fail even if the compiler is available.\n if self.version is not None:\n # Finding version is expensive, so return previously found\n # version string.\n return self.version\n self.version = ''\n # works I think only for unix... \n #print 'command:', self.ver_cmd\n exit_status, out_text = run_command(self.ver_cmd)\n #print exit_status, out_text\n if not exit_status:\n m = re.match(self.ver_match,out_text)\n if m:\n self.version = m.group('version')\n return self.version\n\n def get_libraries(self):\n return self.libraries\n def get_library_dirs(self):\n return self.library_dirs\n def get_extra_link_args(self):\n return []\n def get_runtime_library_dirs(self):\n return []\n def get_linker_so(self):\n \"\"\"\n If a compiler requires specific linker then return a list\n containing a linker executable name and linker options.\n Otherwise, return None.\n \"\"\"\n\n def __str__(self):\n return \"%s %s\" % (self.vendor, self.get_version())\n\n\nclass absoft_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Absoft'\n ver_match = r'FORTRAN 77 Compiler (?P[^\\s*,]*).*?Absoft Corp'\n \n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n # got rid of -B108 cause it was generating 2 underscores instead\n # of one on the newest version. Now we use -YEXT_SFX=_ to \n # specify the output format\n if os.name == 'nt':\n self.f90_switches = '-f fixed -YCFRL=1 -YCOM_NAMES=LCS' \\\n ' -YCOM_PFX -YEXT_PFX -YEXT_NAMES=LCS' \\\n ' -YCOM_SFX=_ -YEXT_SFX=_ -YEXT_NAMES=LCS' \n self.f90_opt = '-O -Q100'\n self.f77_switches = '-N22 -N90 -N110'\n self.f77_opt = '-O -Q100'\n self.libraries = ['fio', 'fmath', 'f90math', 'COMDLG32']\n else:\n self.f90_switches = '-ffixed -YCFRL=1 -YCOM_NAMES=LCS' \\\n ' -YCOM_PFX -YEXT_PFX -YEXT_NAMES=LCS' \\\n ' -YCOM_SFX=_ -YEXT_SFX=_ -YEXT_NAMES=LCS' \n self.f90_opt = '-O -B101' \n self.f77_switches = '-N22 -N90 -N110 -B108'\n self.f77_opt = '-O -B101'\n\n self.libraries = ['fio', 'f77math', 'f90math']\n \n try:\n dir = os.environ['ABSOFT'] \n self.library_dirs = [os.path.join(dir,'lib')]\n except KeyError:\n self.library_dirs = []\n\n self.ver_cmd = self.f77_compiler + ' -V -c %s -o %s' % \\\n self.dummy_fortran_files()\n\n def build_module_switch(self,module_dirs):\n res = ''\n if module_dirs:\n for mod in module_dirs:\n res = res + ' -p' + mod\n return res\n\n def get_extra_link_args(self):\n return []\n # Couldn't get this to link for anything using gcc.\n #dr = \"c:\\\\Absoft62\\\\lib\"\n #libs = ['fio.lib', 'COMDLG32.lib','fmath.lib', 'f90math.lib','libcomdlg32.a' ] \n #libs = map(lambda x,dr=dr:os.path.join(dr,x),libs)\n #return libs\n\n\nclass sun_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Sun'\n ver_match = r'f77: (?P[^\\s*,]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc # not tested\n self.f77_switches = ' -pic '\n self.f77_opt = ' -fast -dalign '\n\n self.f90_compiler = f90c\n self.f90_switches = ' -fixed ' # ??? why fixed?\n self.f90_opt = ' -fast -dalign '\n\n self.libraries = ['f90', 'F77', 'M77', 'sunmath', 'm']\n #threaded\n #self.libraries = ['f90', 'F77_mt', 'sunmath_mt', 'm', 'thread']\n #self.libraries = []\n self.library_dirs = self.find_lib_dir()\n #print 'sun:',self.library_dirs\n\n self.ver_cmd = self.f77_compiler + ' -V'\n\n def build_module_switch(self,module_dirs):\n res = ''\n if module_dirs:\n for mod in module_dirs:\n res = res + ' -M' + mod\n return res\n\n def find_lib_dir(self):\n library_dirs = []\n lib_match = r'### f90: Note: LD_RUN_PATH\\s*= '\\\n '(?P[^\\s.]*).*'\n cmd = self.f90_compiler + ' -dryrun dummy.f'\n exit_status, output = run_command(cmd)\n if not exit_status:\n libs = re.findall(lib_match,output)\n if libs:\n library_dirs = string.split(libs[0],':')\n self.get_version() # force version calculation\n compiler_home = os.path.dirname(library_dirs[0])\n library_dirs.append(os.path.join(compiler_home,\n self.version,'lib'))\n return library_dirs\n def get_runtime_library_dirs(self):\n return self.find_lib_dir()\n def get_extra_link_args(self):\n return ['-mimpure-text']\n\n\nclass mips_fortran_compiler(fortran_compiler_base):\n\n vendor = 'SGI'\n ver_match = r'MIPSpro Compilers: Version (?P[^\\s*,]*)'\n \n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc # not tested\n self.f77_switches = ' -n32 -KPIC '\n self.f77_opt = ' -O3 '\n\n self.f90_compiler = f90c\n self.f90_switches = ' -n32 -KPIC -fixedform ' # why fixed ???\n self.f90_opt = ' ' \n \n self.libraries = ['fortran', 'ftn', 'm']\n self.library_dirs = self.find_lib_dir()\n\n self.ver_cmd = self.f77_compiler + ' -version'\n\n def build_module_switch(self,module_dirs):\n res = ''\n return res \n def find_lib_dir(self):\n library_dirs = []\n return library_dirs\n def get_runtime_library_dirs(self):\n\treturn self.find_lib_dir() \n def get_extra_link_args(self):\n\treturn []\n\n\nclass gnu_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Gnu'\n ver_match = r'g77 version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if sys.platform == 'win32':\n self.libraries = ['gcc','g2c']\n self.library_dirs = self.find_lib_directories()\n\n if fc is None:\n fc = 'g77'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n\n switches = ' -Wall -fno-second-underscore '\n\n if os.name != 'nt':\n switches = switches + ' -fpic '\n\n self.f77_switches = switches\n\n self.ver_cmd = self.f77_compiler + ' -v '\n self.f77_opt = self.get_opt()\n\n def get_opt(self):\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n opt = ' -O3 -funroll-loops '\n \n # only check for more optimization if g77 can handle\n # it.\n if self.get_version():\n if self.version[0]=='3': # is g77 3.x.x\n if cpu.is_AthlonK6():\n opt = opt + ' -march=k6 '\n elif cpu.is_AthlonK7():\n opt = opt + ' -march=athlon '\n if cpu.is_i686():\n opt = opt + ' -march=i686 '\n elif cpu.is_i586():\n opt = opt + ' -march=i586 '\n elif cpu.is_i486():\n opt = opt + ' -march=i486 '\n elif cpu.is_i386():\n opt = opt + ' -march=i386 '\n if cpu.is_Intel():\n opt = opt + ' -malign-double ' \n return opt\n \n def find_lib_directories(self):\n lib_dir = []\n match = r'Reading specs from (.*)/specs'\n\n # works I think only for unix... \n exit_status, out_text = run_command('g77 -v')\n if not exit_status:\n m = re.findall(match,out_text)\n if m:\n lib_dir= m #m[0] \n return lib_dir\n\n def get_linker_so(self):\n # win32 linking should be handled by standard linker\n if sys.platform != 'win32':\n return [self.f77_compiler,'-shared']\n \n def f90_compile(self,source_files,module_files,temp_dir=''):\n raise DistutilsExecError, 'f90 not supported by Gnu'\n\n\n#http://developer.intel.com/software/products/compilers/f50/linux/\nclass intel_ia32_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Intel' # Intel(R) Corporation \n ver_match = r'Intel\\(R\\) Fortran Compiler for 32-bit applications, Version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'ifc'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n switches = ' -KPIC '\n\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n if cpu.has_fdiv_bug():\n switches = switches + ' -fdiv_check '\n if cpu.has_f00f_bug():\n switches = switches + ' -0f_check '\n self.f77_switches = self.f90_switches = switches\n self.f77_switches = self.f77_switches + ' -FI '\n\n self.f77_opt = self.f90_opt = self.get_opt()\n \n debug = ' -g -C '\n self.f77_debug = self.f90_debug = debug\n\n self.ver_cmd = self.f77_compiler+' -FI -V -c %s -o %s' %\\\n self.dummy_fortran_files()\n\n def get_opt(self):\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n opt = ' -O3 '\n if cpu.is_PentiumPro() or cpu.is_PentiumII():\n opt = opt + ' -tpp6 -xi '\n elif cpu.is_PentiumIII():\n opt = opt + ' -tpp6 '\n elif cpu.is_Pentium():\n opt = opt + ' -tpp5 '\n elif cpu.is_PentiumIV():\n opt = opt + ' -tpp7 -xW '\n elif cpu.has_mmx():\n opt = opt + ' -xM '\n return opt\n \n\n def get_linker_so(self):\n return [self.f77_compiler,'-shared']\n\n\nclass intel_itanium_fortran_compiler(intel_ia32_fortran_compiler):\n\n vendor = 'Itanium'\n ver_match = r'Intel\\(R\\) Fortran 90 Compiler Itanium\\(TM\\) Compiler for the Itanium\\(TM\\)-based applications, Version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n if fc is None:\n fc = 'efc'\n intel_ia32_fortran_compiler.__init__(self, fc, f90c)\n\n\nclass nag_fortran_compiler(fortran_compiler_base):\n\n vendor = 'NAG'\n ver_match = r'NAGWare Fortran 95 compiler Release (?P[^\\s]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'f95'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n switches = ''\n debug = ' -g -gline -g90 -nan -C '\n\n self.f77_switches = self.f90_switches = switches\n self.f77_switches = self.f77_switches + ' -fixed '\n self.f77_debug = self.f90_debug = debug\n self.f77_opt = self.f90_opt = self.get_opt()\n\n self.ver_cmd = self.f77_compiler+' -V '\n\n def get_opt(self):\n opt = ' -O4 -target=native '\n\n def get_linker_so(self):\n return [self.f77_compiler,'-Wl,-shared']\n\n\nclass vast_fortran_compiler(fortran_compiler_base):\n\n vendor = 'VAST'\n ver_match = r'\\s*Pacific-Sierra Research vf90 (Personal|Professional)\\s+(?P[^\\s]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'g77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n d,b = os.path.split(f90c)\n vf90 = os.path.join(d,'v'+b)\n self.ver_cmd = vf90+' -v '\n\n gnu = gnu_fortran_compiler(fc)\n if not gnu.is_available(): # VAST compiler requires g77.\n self.version = ''\n return\n if not self.is_available():\n return\n\n self.f77_switches = gnu.f77_switches\n self.f77_debug = gnu.f77_debug\n self.f77_opt = gnu.f77_opt \n\n # XXX: need f90 switches, debug, opt\n\n def get_linker_so(self):\n return [self.f90_compiler,'-shared']\n\n\ndef match_extension(files,ext):\n match = re.compile(r'.*[.]('+ext+r')\\Z',re.I).match\n return filter(lambda x,match = match: match(x),files)\n\ndef get_f77_files(files):\n return match_extension(files,'for|f77|ftn|f')\n\ndef get_f90_files(files):\n return match_extension(files,'f90|f95')\n\ndef get_fortran_files(files):\n return match_extension(files,'f90|f95|for|f77|ftn|f')\n\ndef find_fortran_compiler(vendor = None, fc = None, f90c = None):\n fcompiler = None\n for compiler_class in all_compilers:\n if vendor is not None and vendor != compiler_class.vendor:\n continue\n print compiler_class\n compiler = compiler_class(fc,f90c)\n if compiler.is_available():\n fcompiler = compiler\n break\n return fcompiler\n\nall_compilers = [absoft_fortran_compiler,\n mips_fortran_compiler,\n sun_fortran_compiler,\n gnu_fortran_compiler,\n intel_ia32_fortran_compiler,\n intel_itanium_fortran_compiler,\n nag_fortran_compiler,\n vast_fortran_compiler,\n ]\n\nif __name__ == \"__main__\":\n show_compilers()\n", "methods": [ { "name": "run_command", "long_name": "run_command( command )", "filename": "build_flib.py", "nloc": 5, "complexity": 1, "token_count": 32, "parameters": [ "command" ], "start_line": 55, "end_line": 60, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "show_compilers", "long_name": "show_compilers( )", "filename": "build_flib.py", "nloc": 5, "complexity": 3, "token_count": 23, "parameters": [], "start_line": 64, "end_line": 68, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 }, { "name": "initialize_options", "long_name": "initialize_options( self )", "filename": "build_flib.py", "nloc": 11, "complexity": 1, "token_count": 55, "parameters": [ "self" ], "start_line": 98, "end_line": 110, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "finalize_options", "long_name": "finalize_options( self )", "filename": "build_flib.py", "nloc": 17, "complexity": 3, "token_count": 104, "parameters": [ "self" ], "start_line": 114, "end_line": 130, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 1 }, { "name": "has_f_libraries", "long_name": "has_f_libraries( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 134, "end_line": 135, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "run", "long_name": "run( self )", "filename": "build_flib.py", "nloc": 4, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 137, "end_line": 140, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "get_library_names", "long_name": "get_library_names( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 4, "token_count": 58, "parameters": [ "self" ], "start_line": 144, "end_line": 156, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "get_library_dirs", "long_name": "get_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 42, "parameters": [ "self" ], "start_line": 160, "end_line": 169, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 42, "parameters": [ "self" ], "start_line": 173, "end_line": 182, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_source_files", "long_name": "get_source_files( self )", "filename": "build_flib.py", "nloc": 6, "complexity": 2, "token_count": 38, "parameters": [ "self" ], "start_line": 186, "end_line": 194, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "build_libraries", "long_name": "build_libraries( self , fortran_libraries )", "filename": "build_flib.py", "nloc": 18, "complexity": 5, "token_count": 122, "parameters": [ "self", "fortran_libraries" ], "start_line": 196, "end_line": 217, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self )", "filename": "build_flib.py", "nloc": 16, "complexity": 3, "token_count": 88, "parameters": [ "self" ], "start_line": 229, "end_line": 250, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "to_object", "long_name": "to_object( self , dirty_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 13, "complexity": 3, "token_count": 89, "parameters": [ "self", "dirty_files", "module_dirs", "temp_dir" ], "start_line": 252, "end_line": 264, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "source_to_object_names", "long_name": "source_to_object_names( self , source_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 6, "complexity": 1, "token_count": 89, "parameters": [ "self", "source_files", "temp_dir" ], "start_line": 266, "end_line": 271, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "source_and_object_pairs", "long_name": "source_and_object_pairs( self , source_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 31, "parameters": [ "self", "source_files", "temp_dir" ], "start_line": 273, "end_line": 276, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f_compile", "long_name": "f_compile( self , compiler , switches , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 15, "complexity": 4, "token_count": 103, "parameters": [ "self", "compiler", "switches", "source_files", "module_dirs", "temp_dir" ], "start_line": 278, "end_line": 292, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "f90_compile", "long_name": "f90_compile( self , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 48, "parameters": [ "self", "source_files", "module_dirs", "temp_dir" ], "start_line": 296, "end_line": 299, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f77_compile", "long_name": "f77_compile( self , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 48, "parameters": [ "self", "source_files", "module_dirs", "temp_dir" ], "start_line": 301, "end_line": 304, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self", "module_dirs" ], "start_line": 307, "end_line": 308, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "create_static_lib", "long_name": "create_static_lib( self , object_files , library_name , output_dir = '' , debug = None )", "filename": "build_flib.py", "nloc": 9, "complexity": 2, "token_count": 68, "parameters": [ "self", "object_files", "library_name", "output_dir", "debug" ], "start_line": 310, "end_line": 321, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 12, "top_nesting_level": 1 }, { "name": "build_library", "long_name": "build_library( self , library_name , source_list , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 10, "complexity": 2, "token_count": 85, "parameters": [ "self", "library_name", "source_list", "module_dirs", "temp_dir" ], "start_line": 323, "end_line": 344, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "dummy_fortran_files", "long_name": "dummy_fortran_files( self )", "filename": "build_flib.py", "nloc": 8, "complexity": 1, "token_count": 69, "parameters": [ "self" ], "start_line": 346, "end_line": 353, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "is_available", "long_name": "is_available( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 355, "end_line": 356, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_version", "long_name": "get_version( self )", "filename": "build_flib.py", "nloc": 10, "complexity": 4, "token_count": 66, "parameters": [ "self" ], "start_line": 358, "end_line": 376, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "get_libraries", "long_name": "get_libraries( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 378, "end_line": 379, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_library_dirs", "long_name": "get_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 380, "end_line": 381, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 382, "end_line": 383, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 384, "end_line": 385, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 1, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 386, "end_line": 391, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "__str__", "long_name": "__str__( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self" ], "start_line": 393, "end_line": 394, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 31, "complexity": 5, "token_count": 177, "parameters": [ "self", "fc", "f90c" ], "start_line": 402, "end_line": 440, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 39, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 6, "complexity": 3, "token_count": 27, "parameters": [ "self", "module_dirs" ], "start_line": 442, "end_line": 447, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 449, "end_line": 450, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 98, "parameters": [ "self", "fc", "f90c" ], "start_line": 463, "end_line": 485, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 6, "complexity": 3, "token_count": 27, "parameters": [ "self", "module_dirs" ], "start_line": 487, "end_line": 492, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "find_lib_dir", "long_name": "find_lib_dir( self )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 99, "parameters": [ "self" ], "start_line": 494, "end_line": 508, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 509, "end_line": 510, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 511, "end_line": 512, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 94, "parameters": [ "self", "fc", "f90c" ], "start_line": 520, "end_line": 538, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 12, "parameters": [ "self", "module_dirs" ], "start_line": 540, "end_line": 542, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "find_lib_dir", "long_name": "find_lib_dir( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 543, "end_line": 545, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 546, "end_line": 547, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 548, "end_line": 549, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 16, "complexity": 5, "token_count": 103, "parameters": [ "self", "fc", "f90c" ], "start_line": 557, "end_line": 578, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 21, "complexity": 10, "token_count": 120, "parameters": [ "self" ], "start_line": 580, "end_line": 603, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 24, "top_nesting_level": 1 }, { "name": "find_lib_directories", "long_name": "find_lib_directories( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 3, "token_count": 43, "parameters": [ "self" ], "start_line": 605, "end_line": 615, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 2, "token_count": 20, "parameters": [ "self" ], "start_line": 617, "end_line": 620, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f90_compile", "long_name": "f90_compile( self , source_files , module_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self", "source_files", "module_files", "temp_dir" ], "start_line": 622, "end_line": 623, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 22, "complexity": 5, "token_count": 140, "parameters": [ "self", "fc", "f90c" ], "start_line": 632, "end_line": 660, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 29, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 15, "complexity": 7, "token_count": 85, "parameters": [ "self" ], "start_line": 662, "end_line": 676, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 679, "end_line": 680, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 4, "complexity": 2, "token_count": 31, "parameters": [ "self", "fc", "f90c" ], "start_line": 688, "end_line": 691, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 100, "parameters": [ "self", "fc", "f90c" ], "start_line": 699, "end_line": 718, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 720, "end_line": 722, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 724, "end_line": 725, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 20, "complexity": 5, "token_count": 128, "parameters": [ "self", "fc", "f90c" ], "start_line": 733, "end_line": 757, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 761, "end_line": 762, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "match_extension", "long_name": "match_extension( files , ext )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 44, "parameters": [ "files", "ext" ], "start_line": 765, "end_line": 767, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "get_f77_files", "long_name": "get_f77_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 769, "end_line": 770, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "get_f90_files", "long_name": "get_f90_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 772, "end_line": 773, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "get_fortran_files", "long_name": "get_fortran_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 775, "end_line": 776, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "find_fortran_compiler", "long_name": "find_fortran_compiler( vendor = None , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 11, "complexity": 5, "token_count": 59, "parameters": [ "vendor", "fc", "f90c" ], "start_line": 778, "end_line": 788, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 } ], "methods_before": [ { "name": "run_command", "long_name": "run_command( command )", "filename": "build_flib.py", "nloc": 5, "complexity": 1, "token_count": 32, "parameters": [ "command" ], "start_line": 55, "end_line": 60, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "show_compilers", "long_name": "show_compilers( )", "filename": "build_flib.py", "nloc": 5, "complexity": 3, "token_count": 23, "parameters": [], "start_line": 64, "end_line": 68, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 }, { "name": "initialize_options", "long_name": "initialize_options( self )", "filename": "build_flib.py", "nloc": 11, "complexity": 1, "token_count": 55, "parameters": [ "self" ], "start_line": 98, "end_line": 110, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "finalize_options", "long_name": "finalize_options( self )", "filename": "build_flib.py", "nloc": 17, "complexity": 3, "token_count": 104, "parameters": [ "self" ], "start_line": 114, "end_line": 130, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 1 }, { "name": "has_f_libraries", "long_name": "has_f_libraries( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 134, "end_line": 135, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "run", "long_name": "run( self )", "filename": "build_flib.py", "nloc": 4, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 137, "end_line": 140, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "get_library_names", "long_name": "get_library_names( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 4, "token_count": 58, "parameters": [ "self" ], "start_line": 144, "end_line": 156, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "get_library_dirs", "long_name": "get_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 42, "parameters": [ "self" ], "start_line": 160, "end_line": 169, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 42, "parameters": [ "self" ], "start_line": 173, "end_line": 182, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_source_files", "long_name": "get_source_files( self )", "filename": "build_flib.py", "nloc": 6, "complexity": 2, "token_count": 38, "parameters": [ "self" ], "start_line": 186, "end_line": 194, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "build_libraries", "long_name": "build_libraries( self , fortran_libraries )", "filename": "build_flib.py", "nloc": 18, "complexity": 5, "token_count": 122, "parameters": [ "self", "fortran_libraries" ], "start_line": 196, "end_line": 217, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self )", "filename": "build_flib.py", "nloc": 16, "complexity": 3, "token_count": 88, "parameters": [ "self" ], "start_line": 229, "end_line": 250, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "to_object", "long_name": "to_object( self , dirty_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 13, "complexity": 3, "token_count": 89, "parameters": [ "self", "dirty_files", "module_dirs", "temp_dir" ], "start_line": 252, "end_line": 264, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "source_to_object_names", "long_name": "source_to_object_names( self , source_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 6, "complexity": 1, "token_count": 89, "parameters": [ "self", "source_files", "temp_dir" ], "start_line": 266, "end_line": 271, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "source_and_object_pairs", "long_name": "source_and_object_pairs( self , source_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 31, "parameters": [ "self", "source_files", "temp_dir" ], "start_line": 273, "end_line": 276, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f_compile", "long_name": "f_compile( self , compiler , switches , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 15, "complexity": 4, "token_count": 103, "parameters": [ "self", "compiler", "switches", "source_files", "module_dirs", "temp_dir" ], "start_line": 278, "end_line": 292, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "f90_compile", "long_name": "f90_compile( self , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 48, "parameters": [ "self", "source_files", "module_dirs", "temp_dir" ], "start_line": 296, "end_line": 299, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f77_compile", "long_name": "f77_compile( self , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 48, "parameters": [ "self", "source_files", "module_dirs", "temp_dir" ], "start_line": 301, "end_line": 304, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self", "module_dirs" ], "start_line": 307, "end_line": 308, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "create_static_lib", "long_name": "create_static_lib( self , object_files , library_name , output_dir = '' , debug = None )", "filename": "build_flib.py", "nloc": 9, "complexity": 2, "token_count": 68, "parameters": [ "self", "object_files", "library_name", "output_dir", "debug" ], "start_line": 310, "end_line": 321, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 12, "top_nesting_level": 1 }, { "name": "build_library", "long_name": "build_library( self , library_name , source_list , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 10, "complexity": 2, "token_count": 85, "parameters": [ "self", "library_name", "source_list", "module_dirs", "temp_dir" ], "start_line": 323, "end_line": 344, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "dummy_fortran_files", "long_name": "dummy_fortran_files( self )", "filename": "build_flib.py", "nloc": 8, "complexity": 1, "token_count": 69, "parameters": [ "self" ], "start_line": 346, "end_line": 353, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "is_available", "long_name": "is_available( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 355, "end_line": 356, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_version", "long_name": "get_version( self )", "filename": "build_flib.py", "nloc": 10, "complexity": 4, "token_count": 66, "parameters": [ "self" ], "start_line": 358, "end_line": 376, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "get_libraries", "long_name": "get_libraries( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 378, "end_line": 379, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_library_dirs", "long_name": "get_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 380, "end_line": 381, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 382, "end_line": 383, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 384, "end_line": 385, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 1, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 386, "end_line": 391, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "__str__", "long_name": "__str__( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self" ], "start_line": 393, "end_line": 394, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 31, "complexity": 5, "token_count": 177, "parameters": [ "self", "fc", "f90c" ], "start_line": 402, "end_line": 440, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 39, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 6, "complexity": 3, "token_count": 27, "parameters": [ "self", "module_dirs" ], "start_line": 442, "end_line": 447, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 449, "end_line": 450, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 98, "parameters": [ "self", "fc", "f90c" ], "start_line": 463, "end_line": 485, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 6, "complexity": 3, "token_count": 27, "parameters": [ "self", "module_dirs" ], "start_line": 487, "end_line": 492, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "find_lib_dir", "long_name": "find_lib_dir( self )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 99, "parameters": [ "self" ], "start_line": 494, "end_line": 508, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 509, "end_line": 510, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 511, "end_line": 512, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 94, "parameters": [ "self", "fc", "f90c" ], "start_line": 520, "end_line": 538, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 12, "parameters": [ "self", "module_dirs" ], "start_line": 540, "end_line": 542, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "find_lib_dir", "long_name": "find_lib_dir( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 543, "end_line": 545, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 546, "end_line": 547, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 548, "end_line": 549, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 16, "complexity": 5, "token_count": 103, "parameters": [ "self", "fc", "f90c" ], "start_line": 557, "end_line": 578, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 21, "complexity": 10, "token_count": 120, "parameters": [ "self" ], "start_line": 580, "end_line": 603, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 24, "top_nesting_level": 1 }, { "name": "find_lib_directories", "long_name": "find_lib_directories( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 3, "token_count": 43, "parameters": [ "self" ], "start_line": 605, "end_line": 615, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 2, "token_count": 20, "parameters": [ "self" ], "start_line": 617, "end_line": 620, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f90_compile", "long_name": "f90_compile( self , source_files , module_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self", "source_files", "module_files", "temp_dir" ], "start_line": 622, "end_line": 623, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 22, "complexity": 5, "token_count": 140, "parameters": [ "self", "fc", "f90c" ], "start_line": 632, "end_line": 660, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 29, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 15, "complexity": 7, "token_count": 85, "parameters": [ "self" ], "start_line": 662, "end_line": 676, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 679, "end_line": 680, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 4, "complexity": 2, "token_count": 31, "parameters": [ "self", "fc", "f90c" ], "start_line": 688, "end_line": 691, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 100, "parameters": [ "self", "fc", "f90c" ], "start_line": 699, "end_line": 718, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 720, "end_line": 721, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 723, "end_line": 724, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 20, "complexity": 5, "token_count": 128, "parameters": [ "self", "fc", "f90c" ], "start_line": 732, "end_line": 756, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 760, "end_line": 761, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "match_extension", "long_name": "match_extension( files , ext )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 44, "parameters": [ "files", "ext" ], "start_line": 764, "end_line": 766, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "get_f77_files", "long_name": "get_f77_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 768, "end_line": 769, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "get_f90_files", "long_name": "get_f90_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 771, "end_line": 772, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "get_fortran_files", "long_name": "get_fortran_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 774, "end_line": 775, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "find_fortran_compiler", "long_name": "find_fortran_compiler( vendor = None , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 11, "complexity": 5, "token_count": 59, "parameters": [ "vendor", "fc", "f90c" ], "start_line": 777, "end_line": 787, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 720, "end_line": 722, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 } ], "nloc": 580, "complexity": 142, "token_count": 3327, "diff_parsed": { "added": [ " return opt" ], "deleted": [] } } ] }, { "hash": "a603ba140acaf24a365343c9c9b48904745e4386", "msg": "changed tempdir to gettempdir(). fixed bug introduced in latest testing frenzy", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-04T15:32:32+00:00", "author_timezone": 0, "committer_date": "2002-01-04T15:32:32+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "b63f8e5ed4d3276640e73072fd4b074d357d45e5" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 30, "insertions": 30, "lines": 60, "files": 4, "dmm_unit_size": 0.0, "dmm_unit_complexity": 1.0, "dmm_unit_interfacing": 1.0, "modified_files": [ { "old_path": "weave/catalog.py", "new_path": "weave/catalog.py", "filename": "catalog.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -218,7 +218,7 @@ class catalog:\n fragment. A default directory is also searched for catalog functions. \n On unix, the default directory is usually '~/.pythonxx_compiled' where \n xx is the version of Python used. On windows, it is the directory \n- returned by temfile.tempdir(). Functions closer to the front are of \n+ returned by temfile.gettempdir(). Functions closer to the front are of \n the variable list are guaranteed to be closer to the front of the \n function list so that they will be called first. See \n get_cataloged_functions() for more info on how the search order is \n", "added_lines": 1, "deleted_lines": 1, "source_code": "\"\"\" Track relationships between compiled extension functions & code fragments\n\n catalog keeps track of which compiled(or even standard) functions are \n related to which code fragments. It also stores these relationships\n to disk so they are remembered between Python sessions. When \n \n a = 1\n compiler.inline('printf(\"printed from C: %d\",a);',['a'] )\n \n is called, inline() first looks to see if it has seen the code \n 'printf(\"printed from C\");' before. If not, it calls \n \n catalog.get_functions('printf(\"printed from C: %d\", a);')\n \n which returns a list of all the function objects that have been compiled\n for the code fragment. Multiple functions can occur because the code\n could be compiled for different types for 'a' (although not likely in\n this case). The catalog first looks in its cache and quickly returns\n a list of the functions if possible. If the cache lookup fails, it then\n looks through possibly multiple catalog files on disk and fills its\n cache with all the functions that match the code fragment. \n \n In case where the code fragment hasn't been compiled, inline() compiles\n the code and then adds it to the catalog:\n \n function = \n catalog.add_function('printf(\"printed from C: %d\", a);',function)\n \n add_function() adds function to the front of the cache. function,\n along with the path information to its module, are also stored in a\n persistent catalog for future use by python sessions. \n\"\"\" \n\nimport os,sys,string\nimport shelve\n\ndef getmodule(object):\n \"\"\" Discover the name of the module where object was defined.\n \n This is an augmented version of inspect.getmodule that can discover \n the parent module for extension functions.\n \"\"\"\n import inspect\n value = inspect.getmodule(object)\n if value is None:\n #walk trough all modules looking for function\n for name,mod in sys.modules.items():\n # try except used because of some comparison failures\n # in wxPoint code. Need to review this\n try:\n if mod and object in mod.__dict__.values():\n value = mod\n # if it is a built-in module, keep looking to see\n # if a non-builtin also has it. Otherwise quit and\n # consider the module found. (ain't perfect, but will \n # have to do for now).\n if string.find('(built-in)',str(mod)) is -1:\n break\n \n except TypeError:\n pass \n return value\n\ndef expr_to_filename(expr):\n \"\"\" Convert an arbitrary expr string to a valid file name.\n \n The name is based on the md5 check sum for the string and\n Something that was a little more human readable would be \n nice, but the computer doesn't seem to care.\n \"\"\"\n import md5\n base = 'sc_'\n return base + md5.new(expr).hexdigest()\n\ndef unique_file(d,expr):\n \"\"\" Generate a unqiue file name based on expr in directory d\n \n This is meant for use with building extension modules, so\n a file name is considered unique if none of the following\n extension '.cpp','.o','.so','module.so','.py', or '.pyd'\n exists in directory d. The fully qualified path to the\n new name is returned. You'll need to append your own\n extension to it before creating files.\n \"\"\"\n files = os.listdir(d)\n #base = 'scipy_compile'\n base = expr_to_filename(expr)\n for i in range(1000000):\n fname = base + `i`\n if not (fname+'.cpp' in files or\n fname+'.o' in files or\n fname+'.so' in files or\n fname+'module.so' in files or\n fname+'.py' in files or\n fname+'.pyd' in files):\n break\n return os.path.join(d,fname)\n \ndef default_dir():\n \"\"\" Return a default location to store compiled files and catalogs.\n \n XX is the Python version number in all paths listed below\n On windows, the default location is the temporary directory\n returned by gettempdir()/pythonXX.\n \n On Unix, ~/.pythonXX_compiled is the default location. If it doesn't\n exist, it is created. The directory is marked rwx------.\n \n If for some reason it isn't possible to build a default directory\n in the user's home, /tmp/_pythonXX_compiled is used. If it \n doesn't exist, it is created. The directory is marked rwx------\n to try and keep people from being able to sneak a bad module\n in on you. \n \"\"\"\n import tempfile \n python_name = \"python%d%d_compiled\" % tuple(sys.version_info[:2]) \n if sys.platform != 'win32':\n try:\n path = os.path.join(os.environ['HOME'],'.' + python_name)\n except KeyError:\n temp_dir = `os.getuid()` + '_' + python_name\n path = os.path.join(tempfile.gettempdir(),temp_dir) \n else:\n path = os.path.join(tempfile.gettempdir(),python_name)\n \n if not os.path.exists(path):\n os.mkdir(path)\n os.chmod(path,0700) # make it only accessible by this user.\n if not os.access(path,os.W_OK):\n print 'warning: default directory is not write accessible.'\n print 'defualt:', path\n return path\n\ndef default_temp_dir():\n path = os.path.join(default_dir(),'temp')\n if not os.path.exists(path):\n os.mkdir(path)\n os.chmod(path,0700) # make it only accessible by this user.\n if not os.access(path,os.W_OK):\n print 'warning: default directory is not write accessible.'\n print 'defualt:', path\n return path\n\n \ndef os_dependent_catalog_name():\n \"\"\" Generate catalog name dependent on OS and Python version being used.\n \n This allows multiple platforms to have catalog files in the\n same directory without stepping on each other. For now, it \n bases the name of the value returned by sys.platform and the\n version of python being run. If this isn't enough to descriminate\n on some platforms, we can try to add other info. It has \n occured to me that if we get fancy enough to optimize for different\n architectures, then chip type might be added to the catalog name also.\n \"\"\"\n version = '%d%d' % sys.version_info[:2]\n return sys.platform+version+'compiled_catalog'\n \ndef catalog_path(module_path):\n \"\"\" Return the full path name for the catalog file in the given directory.\n \n module_path can either be a file name or a path name. If it is a \n file name, the catalog file name in its parent directory is returned.\n If it is a directory, the catalog file in that directory is returned.\n\n If module_path doesn't exist, None is returned. Note though, that the\n catalog file does *not* have to exist, only its parent. '~', shell\n variables, and relative ('.' and '..') paths are all acceptable.\n \n catalog file names are os dependent (based on sys.platform), so this \n should support multiple platforms sharing the same disk space \n (NFS mounts). See os_dependent_catalog_name() for more info.\n \"\"\"\n module_path = os.path.expanduser(module_path)\n module_path = os.path.expandvars(module_path)\n module_path = os.path.abspath(module_path)\n if not os.path.exists(module_path):\n catalog_file = None\n elif not os.path.isdir(module_path):\n module_path,dummy = os.path.split(module_path)\n catalog_file = os.path.join(module_path,os_dependent_catalog_name())\n else: \n catalog_file = os.path.join(module_path,os_dependent_catalog_name())\n return catalog_file\n\ndef get_catalog(module_path,mode='r'):\n \"\"\" Return a function catalog (shelve object) from the path module_path\n\n If module_path is a directory, the function catalog returned is\n from that directory. If module_path is an actual module_name,\n then the function catalog returned is from its parent directory.\n mode uses the standard 'c' = create, 'r' = read, 'w' = write\n file open modes.\n \n See catalog_path() for more information on module_path.\n \"\"\"\n catalog_file = catalog_path(module_path)\n #print catalog_file\n #sh = shelve.open(catalog_file,mode)\n try:\n sh = shelve.open(catalog_file,mode)\n except: # not sure how to pin down which error to catch yet\n sh = None\n return sh\n\nclass catalog:\n \"\"\" Stores information about compiled functions both in cache and on disk.\n \n catalog stores (code, list_of_function) pairs so that all the functions\n that have been compiled for code are available for calling (usually in\n inline or blitz).\n \n catalog keeps a dictionary of previously accessed code values cached \n for quick access. It also handles the looking up of functions compiled \n in previously called Python sessions on disk in function catalogs. \n catalog searches the directories in the PYTHONCOMPILED environment \n variable in order loading functions that correspond to the given code \n fragment. A default directory is also searched for catalog functions. \n On unix, the default directory is usually '~/.pythonxx_compiled' where \n xx is the version of Python used. On windows, it is the directory \n returned by temfile.gettempdir(). Functions closer to the front are of \n the variable list are guaranteed to be closer to the front of the \n function list so that they will be called first. See \n get_cataloged_functions() for more info on how the search order is \n traversed.\n \n Catalog also handles storing information about compiled functions to\n a catalog. When writing this information, the first writable catalog\n file in PYTHONCOMPILED path is used. If a writable catalog is not\n found, it is written to the catalog in the default directory. This\n directory should always be writable.\n \"\"\"\n def __init__(self,user_path_list=None):\n \"\"\" Create a catalog for storing/searching for compiled functions. \n \n user_path_list contains directories that should be searched \n first for function catalogs. They will come before the path\n entries in the PYTHONCOMPILED environment varilable.\n \"\"\"\n if type(user_path_list) == type('string'):\n self.user_path_list = [user_path_list]\n elif user_path_list:\n self.user_path_list = user_path_list\n else:\n self.user_path_list = []\n self.cache = {}\n self.module_dir = None\n self.paths_added = 0\n \n def set_module_directory(self,module_dir):\n \"\"\" Set the path that will replace 'MODULE' in catalog searches.\n \n You should call clear_module_directory() when your finished\n working with it.\n \"\"\"\n self.module_dir = module_dir\n def get_module_directory(self):\n \"\"\" Return the path used to replace the 'MODULE' in searches.\n \"\"\"\n return self.module_dir\n def clear_module_directory(self):\n \"\"\" Reset 'MODULE' path to None so that it is ignored in searches. \n \"\"\"\n self.module_dir = None\n \n def get_environ_path(self):\n \"\"\" Return list of paths from 'PYTHONCOMPILED' environment variable.\n \n On Unix the path in PYTHONCOMPILED is a ':' separated list of\n directories. On Windows, a ';' separated list is used. \n \"\"\"\n paths = []\n if os.environ.has_key('PYTHONCOMPILED'):\n path_string = os.environ['PYTHONCOMPILED'] \n if sys.platform == 'win32':\n #probably should also look in registry\n paths = path_string.split(';')\n else: \n paths = path_string.split(':')\n return paths \n\n def build_search_order(self):\n \"\"\" Returns a list of paths that are searched for catalogs. \n \n Values specified in the catalog constructor are searched first,\n then values found in the PYTHONCOMPILED environment variable.\n The directory returned by default_dir() is always returned at\n the end of the list.\n \n There is a 'magic' path name called 'MODULE' that is replaced\n by the directory defined by set_module_directory(). If the\n module directory hasn't been set, 'MODULE' is ignored.\n \"\"\"\n \n paths = self.user_path_list + self.get_environ_path()\n search_order = []\n for path in paths:\n if path == 'MODULE':\n if self.module_dir:\n search_order.append(self.module_dir)\n else:\n search_order.append(path)\n search_order.append(default_dir())\n return search_order\n\n def get_catalog_files(self):\n \"\"\" Returns catalog file list in correct search order.\n \n Some of the catalog files may not currently exists.\n However, all will be valid locations for a catalog\n to be created (if you have write permission).\n \"\"\"\n files = map(catalog_path,self.build_search_order())\n files = filter(lambda x: x is not None,files)\n return files\n\n def get_existing_files(self):\n \"\"\" Returns all existing catalog file list in correct search order.\n \"\"\"\n files = self.get_catalog_files()\n existing_files = filter(os.path.exists,files)\n return existing_files\n\n def get_writable_file(self,existing_only=0):\n \"\"\" Return the name of the first writable catalog file.\n \n Its parent directory must also be writable. This is so that\n compiled modules can be written to the same directory.\n \"\"\"\n # note: both file and its parent directory must be writeable\n if existing_only:\n files = self.get_existing_files()\n else:\n files = self.get_catalog_files()\n # filter for (file exists and is writable) OR directory is writable\n def file_test(x):\n from os import access, F_OK, W_OK\n return (access(x,F_OK) and access(x,W_OK) or\n access(os.path.dirname(x),W_OK))\n writable = filter(file_test,files)\n if writable:\n file = writable[0]\n else:\n file = None\n return file\n \n def get_writable_dir(self):\n \"\"\" Return the parent directory of first writable catalog file.\n \n The returned directory has write access.\n \"\"\"\n return os.path.dirname(self.get_writable_file())\n \n def unique_module_name(self,code,module_dir=None):\n \"\"\" Return full path to unique file name that in writable location.\n \n The directory for the file is the first writable directory in \n the catalog search path. The unique file name is derived from\n the code fragment. If, module_dir is specified, it is used\n to replace 'MODULE' in the search path.\n \"\"\"\n if module_dir is not None:\n self.set_module_directory(module_dir)\n try:\n d = self.get_writable_dir()\n finally:\n if module_dir is not None:\n self.clear_module_directory()\n return unique_file(d,code)\n\n def path_key(self,code):\n \"\"\" Return key for path information for functions associated with code.\n \"\"\"\n return '__path__' + code\n \n def configure_path(self,cat,code):\n \"\"\" Add the python path for the given code to the sys.path\n \n unconfigure_path() should be called as soon as possible after\n imports associated with code are finished so that sys.path \n is restored to normal.\n \"\"\"\n try:\n paths = cat[self.path_key(code)]\n self.paths_added = len(paths)\n sys.path = paths + sys.path\n except:\n self.paths_added = 0 \n \n def unconfigure_path(self):\n \"\"\" Restores sys.path to normal after calls to configure_path()\n \n Remove the previously added paths from sys.path\n \"\"\"\n sys.path = sys.path[self.paths_added:]\n self.paths_added = 0\n\n def get_cataloged_functions(self,code):\n \"\"\" Load all functions associated with code from catalog search path.\n \n Sometimes there can be trouble loading a function listed in a\n catalog file because the actual module that holds the function \n has been moved or deleted. When this happens, that catalog file\n is \"repaired\", meaning the entire entry for this function is \n removed from the file. This only affects the catalog file that\n has problems -- not the others in the search path.\n \n The \"repair\" behavior may not be needed, but I'll keep it for now.\n \"\"\"\n mode = 'r'\n cat = None\n function_list = []\n for path in self.build_search_order():\n cat = get_catalog(path,mode)\n if cat is not None and cat.has_key(code):\n # set up the python path so that modules for this\n # function can be loaded.\n self.configure_path(cat,code)\n try: \n function_list += cat[code]\n except: #SystemError and ImportError so far seen \n # problems loading a function from the catalog. Try to\n # repair the cause.\n cat.close()\n self.repair_catalog(path,code)\n self.unconfigure_path() \n return function_list\n\n\n def repair_catalog(self,catalog_path,code):\n \"\"\" Remove entry for code from catalog_path\n \n Occasionally catalog entries could get corrupted. An example\n would be when a module that had functions in the catalog was\n deleted or moved on the disk. The best current repair method is \n just to trash the entire catalog entry for this piece of code. \n This may loose function entries that are valid, but thats life.\n \n catalog_path must be writable for repair. If it isn't, the\n function exists with a warning. \n \"\"\"\n writable_cat = None\n if not os.path.exists(catalog_path):\n return\n try:\n writable_cat = get_catalog(catalog_path,'w')\n except:\n print 'warning: unable to repair catalog entry\\n %s\\n in\\n %s' % \\\n (code,catalog_path)\n return \n if writable_cat.has_key(code):\n print 'repairing catalog by removing key'\n del writable_cat[code] \n del writable_cat[self.path_key(code)] \n \n def get_functions_fast(self,code):\n \"\"\" Return list of functions for code from the cache.\n \n Return an empty list if the code entry is not found.\n \"\"\"\n return self.cache.get(code,[])\n \n def get_functions(self,code,module_dir=None):\n \"\"\" Return the list of functions associated with this code fragment.\n \n The cache is first searched for the function. If an entry\n in the cache is not found, then catalog files on disk are \n searched for the entry. This is slooooow, but only happens\n once per code object. All the functions found in catalog files\n on a cache miss are loaded into the cache to speed up future calls.\n The search order is as follows:\n \n 1. user specified path (from catalog initialization)\n 2. directories from the PYTHONCOMPILED environment variable\n 3. The temporary directory on your platform.\n\n The path specified by module_dir will replace the 'MODULE' \n place holder in the catalog search path. See build_search_order()\n for more info on the search path. \n \"\"\" \n # Fast!! try cache first.\n if self.cache.has_key(code):\n return self.cache[code]\n \n # 2. Slow!! read previously compiled functions from disk.\n try:\n self.set_module_directory(module_dir)\n function_list = self.get_cataloged_functions(code)\n if code:\n function_list\n # put function_list in cache to save future lookups.\n if function_list:\n self.cache[code] = function_list\n # return function_list, empty or otherwise.\n finally:\n self.clear_module_directory()\n return function_list\n\n def add_function(self,code,function,module_dir=None):\n \"\"\" Adds a function to the catalog.\n \n The function is added to the cache as well as the first\n writable file catalog found in the search path. If no\n code entry exists in the cache, the on disk catalogs\n are loaded into the cache and function is added to the\n beginning of the function list.\n \n The path specified by module_dir will replace the 'MODULE' \n place holder in the catalog search path. See build_search_order()\n for more info on the search path. \n \"\"\" \n\n # 1. put it in the cache.\n if self.cache.has_key(code):\n if function not in self.cache[code]:\n self.cache[code].insert(0,function)\n else: \n # Load functions and put this one up front\n self.cache[code] = self.get_functions(code) \n self.fast_cache(code,function)\n \n # 2. Store the function entry to disk. \n try:\n self.set_module_directory(module_dir)\n self.add_function_persistent(code,function)\n finally:\n self.clear_module_directory()\n \n def add_function_persistent(self,code,function):\n \"\"\" Store the code->function relationship to disk.\n \n Two pieces of information are needed for loading functions\n from disk -- the function pickle (which conveniently stores\n the module name, etc.) and the path to its module's directory.\n The latter is needed so that the function can be loaded no\n matter what the user's Python path is.\n \"\"\" \n # add function to data in first writable catalog\n mode = 'cw' # create, write\n cat_file = self.get_writable_dir()\n cat = get_catalog(cat_file,mode)\n if cat is None:\n cat_dir = default_dir()\n cat = get_catalog(cat_file,mode)\n if cat is None:\n cat_dir = default_dir() \n cat_file = catalog_path(cat_dir)\n print 'problems with default catalog -- removing'\n os.remove(cat_file)\n cat = get_catalog(cat_dir,mode)\n if cat is None:\n raise ValueError, 'Failed to access a catalog for storing functions' \n function_list = [function] + cat.get(code,[])\n cat[code] = function_list\n \n # now add needed path information for loading function\n module = getmodule(function)\n try:\n # built in modules don't have the __file__ extension, so this\n # will fail. Just pass in this case since path additions aren't\n # needed for built-in modules.\n mod_path,f=os.path.split(os.path.abspath(module.__file__))\n pkey = self.path_key(code)\n cat[pkey] = [mod_path] + cat.get(pkey,[])\n except:\n pass\n\n def fast_cache(self,code,function):\n \"\"\" Move function to the front of the cache entry for code\n \n If future calls to the function have the same type signature,\n this will speed up access significantly because the first\n function call is correct.\n \n Note: The cache added to the inline_tools module is significantly\n faster than always calling get_functions, so this isn't\n as necessary as it used to be. Still, it's probably worth\n doing. \n \"\"\"\n try:\n if self.cache[code][0] == function:\n return\n except: # KeyError, IndexError \n pass\n try:\n self.cache[code].remove(function)\n except ValueError:\n pass\n # put new function at the beginning of the list to search.\n self.cache[code].insert(0,function)\n \ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n", "source_code_before": "\"\"\" Track relationships between compiled extension functions & code fragments\n\n catalog keeps track of which compiled(or even standard) functions are \n related to which code fragments. It also stores these relationships\n to disk so they are remembered between Python sessions. When \n \n a = 1\n compiler.inline('printf(\"printed from C: %d\",a);',['a'] )\n \n is called, inline() first looks to see if it has seen the code \n 'printf(\"printed from C\");' before. If not, it calls \n \n catalog.get_functions('printf(\"printed from C: %d\", a);')\n \n which returns a list of all the function objects that have been compiled\n for the code fragment. Multiple functions can occur because the code\n could be compiled for different types for 'a' (although not likely in\n this case). The catalog first looks in its cache and quickly returns\n a list of the functions if possible. If the cache lookup fails, it then\n looks through possibly multiple catalog files on disk and fills its\n cache with all the functions that match the code fragment. \n \n In case where the code fragment hasn't been compiled, inline() compiles\n the code and then adds it to the catalog:\n \n function = \n catalog.add_function('printf(\"printed from C: %d\", a);',function)\n \n add_function() adds function to the front of the cache. function,\n along with the path information to its module, are also stored in a\n persistent catalog for future use by python sessions. \n\"\"\" \n\nimport os,sys,string\nimport shelve\n\ndef getmodule(object):\n \"\"\" Discover the name of the module where object was defined.\n \n This is an augmented version of inspect.getmodule that can discover \n the parent module for extension functions.\n \"\"\"\n import inspect\n value = inspect.getmodule(object)\n if value is None:\n #walk trough all modules looking for function\n for name,mod in sys.modules.items():\n # try except used because of some comparison failures\n # in wxPoint code. Need to review this\n try:\n if mod and object in mod.__dict__.values():\n value = mod\n # if it is a built-in module, keep looking to see\n # if a non-builtin also has it. Otherwise quit and\n # consider the module found. (ain't perfect, but will \n # have to do for now).\n if string.find('(built-in)',str(mod)) is -1:\n break\n \n except TypeError:\n pass \n return value\n\ndef expr_to_filename(expr):\n \"\"\" Convert an arbitrary expr string to a valid file name.\n \n The name is based on the md5 check sum for the string and\n Something that was a little more human readable would be \n nice, but the computer doesn't seem to care.\n \"\"\"\n import md5\n base = 'sc_'\n return base + md5.new(expr).hexdigest()\n\ndef unique_file(d,expr):\n \"\"\" Generate a unqiue file name based on expr in directory d\n \n This is meant for use with building extension modules, so\n a file name is considered unique if none of the following\n extension '.cpp','.o','.so','module.so','.py', or '.pyd'\n exists in directory d. The fully qualified path to the\n new name is returned. You'll need to append your own\n extension to it before creating files.\n \"\"\"\n files = os.listdir(d)\n #base = 'scipy_compile'\n base = expr_to_filename(expr)\n for i in range(1000000):\n fname = base + `i`\n if not (fname+'.cpp' in files or\n fname+'.o' in files or\n fname+'.so' in files or\n fname+'module.so' in files or\n fname+'.py' in files or\n fname+'.pyd' in files):\n break\n return os.path.join(d,fname)\n \ndef default_dir():\n \"\"\" Return a default location to store compiled files and catalogs.\n \n XX is the Python version number in all paths listed below\n On windows, the default location is the temporary directory\n returned by gettempdir()/pythonXX.\n \n On Unix, ~/.pythonXX_compiled is the default location. If it doesn't\n exist, it is created. The directory is marked rwx------.\n \n If for some reason it isn't possible to build a default directory\n in the user's home, /tmp/_pythonXX_compiled is used. If it \n doesn't exist, it is created. The directory is marked rwx------\n to try and keep people from being able to sneak a bad module\n in on you. \n \"\"\"\n import tempfile \n python_name = \"python%d%d_compiled\" % tuple(sys.version_info[:2]) \n if sys.platform != 'win32':\n try:\n path = os.path.join(os.environ['HOME'],'.' + python_name)\n except KeyError:\n temp_dir = `os.getuid()` + '_' + python_name\n path = os.path.join(tempfile.gettempdir(),temp_dir) \n else:\n path = os.path.join(tempfile.gettempdir(),python_name)\n \n if not os.path.exists(path):\n os.mkdir(path)\n os.chmod(path,0700) # make it only accessible by this user.\n if not os.access(path,os.W_OK):\n print 'warning: default directory is not write accessible.'\n print 'defualt:', path\n return path\n\ndef default_temp_dir():\n path = os.path.join(default_dir(),'temp')\n if not os.path.exists(path):\n os.mkdir(path)\n os.chmod(path,0700) # make it only accessible by this user.\n if not os.access(path,os.W_OK):\n print 'warning: default directory is not write accessible.'\n print 'defualt:', path\n return path\n\n \ndef os_dependent_catalog_name():\n \"\"\" Generate catalog name dependent on OS and Python version being used.\n \n This allows multiple platforms to have catalog files in the\n same directory without stepping on each other. For now, it \n bases the name of the value returned by sys.platform and the\n version of python being run. If this isn't enough to descriminate\n on some platforms, we can try to add other info. It has \n occured to me that if we get fancy enough to optimize for different\n architectures, then chip type might be added to the catalog name also.\n \"\"\"\n version = '%d%d' % sys.version_info[:2]\n return sys.platform+version+'compiled_catalog'\n \ndef catalog_path(module_path):\n \"\"\" Return the full path name for the catalog file in the given directory.\n \n module_path can either be a file name or a path name. If it is a \n file name, the catalog file name in its parent directory is returned.\n If it is a directory, the catalog file in that directory is returned.\n\n If module_path doesn't exist, None is returned. Note though, that the\n catalog file does *not* have to exist, only its parent. '~', shell\n variables, and relative ('.' and '..') paths are all acceptable.\n \n catalog file names are os dependent (based on sys.platform), so this \n should support multiple platforms sharing the same disk space \n (NFS mounts). See os_dependent_catalog_name() for more info.\n \"\"\"\n module_path = os.path.expanduser(module_path)\n module_path = os.path.expandvars(module_path)\n module_path = os.path.abspath(module_path)\n if not os.path.exists(module_path):\n catalog_file = None\n elif not os.path.isdir(module_path):\n module_path,dummy = os.path.split(module_path)\n catalog_file = os.path.join(module_path,os_dependent_catalog_name())\n else: \n catalog_file = os.path.join(module_path,os_dependent_catalog_name())\n return catalog_file\n\ndef get_catalog(module_path,mode='r'):\n \"\"\" Return a function catalog (shelve object) from the path module_path\n\n If module_path is a directory, the function catalog returned is\n from that directory. If module_path is an actual module_name,\n then the function catalog returned is from its parent directory.\n mode uses the standard 'c' = create, 'r' = read, 'w' = write\n file open modes.\n \n See catalog_path() for more information on module_path.\n \"\"\"\n catalog_file = catalog_path(module_path)\n #print catalog_file\n #sh = shelve.open(catalog_file,mode)\n try:\n sh = shelve.open(catalog_file,mode)\n except: # not sure how to pin down which error to catch yet\n sh = None\n return sh\n\nclass catalog:\n \"\"\" Stores information about compiled functions both in cache and on disk.\n \n catalog stores (code, list_of_function) pairs so that all the functions\n that have been compiled for code are available for calling (usually in\n inline or blitz).\n \n catalog keeps a dictionary of previously accessed code values cached \n for quick access. It also handles the looking up of functions compiled \n in previously called Python sessions on disk in function catalogs. \n catalog searches the directories in the PYTHONCOMPILED environment \n variable in order loading functions that correspond to the given code \n fragment. A default directory is also searched for catalog functions. \n On unix, the default directory is usually '~/.pythonxx_compiled' where \n xx is the version of Python used. On windows, it is the directory \n returned by temfile.tempdir(). Functions closer to the front are of \n the variable list are guaranteed to be closer to the front of the \n function list so that they will be called first. See \n get_cataloged_functions() for more info on how the search order is \n traversed.\n \n Catalog also handles storing information about compiled functions to\n a catalog. When writing this information, the first writable catalog\n file in PYTHONCOMPILED path is used. If a writable catalog is not\n found, it is written to the catalog in the default directory. This\n directory should always be writable.\n \"\"\"\n def __init__(self,user_path_list=None):\n \"\"\" Create a catalog for storing/searching for compiled functions. \n \n user_path_list contains directories that should be searched \n first for function catalogs. They will come before the path\n entries in the PYTHONCOMPILED environment varilable.\n \"\"\"\n if type(user_path_list) == type('string'):\n self.user_path_list = [user_path_list]\n elif user_path_list:\n self.user_path_list = user_path_list\n else:\n self.user_path_list = []\n self.cache = {}\n self.module_dir = None\n self.paths_added = 0\n \n def set_module_directory(self,module_dir):\n \"\"\" Set the path that will replace 'MODULE' in catalog searches.\n \n You should call clear_module_directory() when your finished\n working with it.\n \"\"\"\n self.module_dir = module_dir\n def get_module_directory(self):\n \"\"\" Return the path used to replace the 'MODULE' in searches.\n \"\"\"\n return self.module_dir\n def clear_module_directory(self):\n \"\"\" Reset 'MODULE' path to None so that it is ignored in searches. \n \"\"\"\n self.module_dir = None\n \n def get_environ_path(self):\n \"\"\" Return list of paths from 'PYTHONCOMPILED' environment variable.\n \n On Unix the path in PYTHONCOMPILED is a ':' separated list of\n directories. On Windows, a ';' separated list is used. \n \"\"\"\n paths = []\n if os.environ.has_key('PYTHONCOMPILED'):\n path_string = os.environ['PYTHONCOMPILED'] \n if sys.platform == 'win32':\n #probably should also look in registry\n paths = path_string.split(';')\n else: \n paths = path_string.split(':')\n return paths \n\n def build_search_order(self):\n \"\"\" Returns a list of paths that are searched for catalogs. \n \n Values specified in the catalog constructor are searched first,\n then values found in the PYTHONCOMPILED environment variable.\n The directory returned by default_dir() is always returned at\n the end of the list.\n \n There is a 'magic' path name called 'MODULE' that is replaced\n by the directory defined by set_module_directory(). If the\n module directory hasn't been set, 'MODULE' is ignored.\n \"\"\"\n \n paths = self.user_path_list + self.get_environ_path()\n search_order = []\n for path in paths:\n if path == 'MODULE':\n if self.module_dir:\n search_order.append(self.module_dir)\n else:\n search_order.append(path)\n search_order.append(default_dir())\n return search_order\n\n def get_catalog_files(self):\n \"\"\" Returns catalog file list in correct search order.\n \n Some of the catalog files may not currently exists.\n However, all will be valid locations for a catalog\n to be created (if you have write permission).\n \"\"\"\n files = map(catalog_path,self.build_search_order())\n files = filter(lambda x: x is not None,files)\n return files\n\n def get_existing_files(self):\n \"\"\" Returns all existing catalog file list in correct search order.\n \"\"\"\n files = self.get_catalog_files()\n existing_files = filter(os.path.exists,files)\n return existing_files\n\n def get_writable_file(self,existing_only=0):\n \"\"\" Return the name of the first writable catalog file.\n \n Its parent directory must also be writable. This is so that\n compiled modules can be written to the same directory.\n \"\"\"\n # note: both file and its parent directory must be writeable\n if existing_only:\n files = self.get_existing_files()\n else:\n files = self.get_catalog_files()\n # filter for (file exists and is writable) OR directory is writable\n def file_test(x):\n from os import access, F_OK, W_OK\n return (access(x,F_OK) and access(x,W_OK) or\n access(os.path.dirname(x),W_OK))\n writable = filter(file_test,files)\n if writable:\n file = writable[0]\n else:\n file = None\n return file\n \n def get_writable_dir(self):\n \"\"\" Return the parent directory of first writable catalog file.\n \n The returned directory has write access.\n \"\"\"\n return os.path.dirname(self.get_writable_file())\n \n def unique_module_name(self,code,module_dir=None):\n \"\"\" Return full path to unique file name that in writable location.\n \n The directory for the file is the first writable directory in \n the catalog search path. The unique file name is derived from\n the code fragment. If, module_dir is specified, it is used\n to replace 'MODULE' in the search path.\n \"\"\"\n if module_dir is not None:\n self.set_module_directory(module_dir)\n try:\n d = self.get_writable_dir()\n finally:\n if module_dir is not None:\n self.clear_module_directory()\n return unique_file(d,code)\n\n def path_key(self,code):\n \"\"\" Return key for path information for functions associated with code.\n \"\"\"\n return '__path__' + code\n \n def configure_path(self,cat,code):\n \"\"\" Add the python path for the given code to the sys.path\n \n unconfigure_path() should be called as soon as possible after\n imports associated with code are finished so that sys.path \n is restored to normal.\n \"\"\"\n try:\n paths = cat[self.path_key(code)]\n self.paths_added = len(paths)\n sys.path = paths + sys.path\n except:\n self.paths_added = 0 \n \n def unconfigure_path(self):\n \"\"\" Restores sys.path to normal after calls to configure_path()\n \n Remove the previously added paths from sys.path\n \"\"\"\n sys.path = sys.path[self.paths_added:]\n self.paths_added = 0\n\n def get_cataloged_functions(self,code):\n \"\"\" Load all functions associated with code from catalog search path.\n \n Sometimes there can be trouble loading a function listed in a\n catalog file because the actual module that holds the function \n has been moved or deleted. When this happens, that catalog file\n is \"repaired\", meaning the entire entry for this function is \n removed from the file. This only affects the catalog file that\n has problems -- not the others in the search path.\n \n The \"repair\" behavior may not be needed, but I'll keep it for now.\n \"\"\"\n mode = 'r'\n cat = None\n function_list = []\n for path in self.build_search_order():\n cat = get_catalog(path,mode)\n if cat is not None and cat.has_key(code):\n # set up the python path so that modules for this\n # function can be loaded.\n self.configure_path(cat,code)\n try: \n function_list += cat[code]\n except: #SystemError and ImportError so far seen \n # problems loading a function from the catalog. Try to\n # repair the cause.\n cat.close()\n self.repair_catalog(path,code)\n self.unconfigure_path() \n return function_list\n\n\n def repair_catalog(self,catalog_path,code):\n \"\"\" Remove entry for code from catalog_path\n \n Occasionally catalog entries could get corrupted. An example\n would be when a module that had functions in the catalog was\n deleted or moved on the disk. The best current repair method is \n just to trash the entire catalog entry for this piece of code. \n This may loose function entries that are valid, but thats life.\n \n catalog_path must be writable for repair. If it isn't, the\n function exists with a warning. \n \"\"\"\n writable_cat = None\n if not os.path.exists(catalog_path):\n return\n try:\n writable_cat = get_catalog(catalog_path,'w')\n except:\n print 'warning: unable to repair catalog entry\\n %s\\n in\\n %s' % \\\n (code,catalog_path)\n return \n if writable_cat.has_key(code):\n print 'repairing catalog by removing key'\n del writable_cat[code] \n del writable_cat[self.path_key(code)] \n \n def get_functions_fast(self,code):\n \"\"\" Return list of functions for code from the cache.\n \n Return an empty list if the code entry is not found.\n \"\"\"\n return self.cache.get(code,[])\n \n def get_functions(self,code,module_dir=None):\n \"\"\" Return the list of functions associated with this code fragment.\n \n The cache is first searched for the function. If an entry\n in the cache is not found, then catalog files on disk are \n searched for the entry. This is slooooow, but only happens\n once per code object. All the functions found in catalog files\n on a cache miss are loaded into the cache to speed up future calls.\n The search order is as follows:\n \n 1. user specified path (from catalog initialization)\n 2. directories from the PYTHONCOMPILED environment variable\n 3. The temporary directory on your platform.\n\n The path specified by module_dir will replace the 'MODULE' \n place holder in the catalog search path. See build_search_order()\n for more info on the search path. \n \"\"\" \n # Fast!! try cache first.\n if self.cache.has_key(code):\n return self.cache[code]\n \n # 2. Slow!! read previously compiled functions from disk.\n try:\n self.set_module_directory(module_dir)\n function_list = self.get_cataloged_functions(code)\n if code:\n function_list\n # put function_list in cache to save future lookups.\n if function_list:\n self.cache[code] = function_list\n # return function_list, empty or otherwise.\n finally:\n self.clear_module_directory()\n return function_list\n\n def add_function(self,code,function,module_dir=None):\n \"\"\" Adds a function to the catalog.\n \n The function is added to the cache as well as the first\n writable file catalog found in the search path. If no\n code entry exists in the cache, the on disk catalogs\n are loaded into the cache and function is added to the\n beginning of the function list.\n \n The path specified by module_dir will replace the 'MODULE' \n place holder in the catalog search path. See build_search_order()\n for more info on the search path. \n \"\"\" \n\n # 1. put it in the cache.\n if self.cache.has_key(code):\n if function not in self.cache[code]:\n self.cache[code].insert(0,function)\n else: \n # Load functions and put this one up front\n self.cache[code] = self.get_functions(code) \n self.fast_cache(code,function)\n \n # 2. Store the function entry to disk. \n try:\n self.set_module_directory(module_dir)\n self.add_function_persistent(code,function)\n finally:\n self.clear_module_directory()\n \n def add_function_persistent(self,code,function):\n \"\"\" Store the code->function relationship to disk.\n \n Two pieces of information are needed for loading functions\n from disk -- the function pickle (which conveniently stores\n the module name, etc.) and the path to its module's directory.\n The latter is needed so that the function can be loaded no\n matter what the user's Python path is.\n \"\"\" \n # add function to data in first writable catalog\n mode = 'cw' # create, write\n cat_file = self.get_writable_dir()\n cat = get_catalog(cat_file,mode)\n if cat is None:\n cat_dir = default_dir()\n cat = get_catalog(cat_file,mode)\n if cat is None:\n cat_dir = default_dir() \n cat_file = catalog_path(cat_dir)\n print 'problems with default catalog -- removing'\n os.remove(cat_file)\n cat = get_catalog(cat_dir,mode)\n if cat is None:\n raise ValueError, 'Failed to access a catalog for storing functions' \n function_list = [function] + cat.get(code,[])\n cat[code] = function_list\n \n # now add needed path information for loading function\n module = getmodule(function)\n try:\n # built in modules don't have the __file__ extension, so this\n # will fail. Just pass in this case since path additions aren't\n # needed for built-in modules.\n mod_path,f=os.path.split(os.path.abspath(module.__file__))\n pkey = self.path_key(code)\n cat[pkey] = [mod_path] + cat.get(pkey,[])\n except:\n pass\n\n def fast_cache(self,code,function):\n \"\"\" Move function to the front of the cache entry for code\n \n If future calls to the function have the same type signature,\n this will speed up access significantly because the first\n function call is correct.\n \n Note: The cache added to the inline_tools module is significantly\n faster than always calling get_functions, so this isn't\n as necessary as it used to be. Still, it's probably worth\n doing. \n \"\"\"\n try:\n if self.cache[code][0] == function:\n return\n except: # KeyError, IndexError \n pass\n try:\n self.cache[code].remove(function)\n except ValueError:\n pass\n # put new function at the beginning of the list to search.\n self.cache[code].insert(0,function)\n \ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n", "methods": [ { "name": "getmodule", "long_name": "getmodule( object )", "filename": "catalog.py", "nloc": 13, "complexity": 7, "token_count": 75, "parameters": [ "object" ], "start_line": 37, "end_line": 62, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "expr_to_filename", "long_name": "expr_to_filename( expr )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 24, "parameters": [ "expr" ], "start_line": 64, "end_line": 73, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "unique_file", "long_name": "unique_file( d , expr )", "filename": "catalog.py", "nloc": 13, "complexity": 8, "token_count": 89, "parameters": [ "d", "expr" ], "start_line": 75, "end_line": 97, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 0 }, { "name": "default_dir", "long_name": "default_dir( )", "filename": "catalog.py", "nloc": 18, "complexity": 5, "token_count": 145, "parameters": [], "start_line": 99, "end_line": 132, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 34, "top_nesting_level": 0 }, { "name": "default_temp_dir", "long_name": "default_temp_dir( )", "filename": "catalog.py", "nloc": 9, "complexity": 3, "token_count": 64, "parameters": [], "start_line": 134, "end_line": 142, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 0 }, { "name": "os_dependent_catalog_name", "long_name": "os_dependent_catalog_name( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 145, "end_line": 157, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 0 }, { "name": "catalog_path", "long_name": "catalog_path( module_path )", "filename": "catalog.py", "nloc": 12, "complexity": 3, "token_count": 105, "parameters": [ "module_path" ], "start_line": 159, "end_line": 184, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "get_catalog", "long_name": "get_catalog( module_path , mode = 'r' )", "filename": "catalog.py", "nloc": 7, "complexity": 2, "token_count": 35, "parameters": [ "module_path", "mode" ], "start_line": 186, "end_line": 204, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 0 }, { "name": "__init__", "long_name": "__init__( self , user_path_list = None )", "filename": "catalog.py", "nloc": 10, "complexity": 3, "token_count": 60, "parameters": [ "self", "user_path_list" ], "start_line": 233, "end_line": 248, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "set_module_directory", "long_name": "set_module_directory( self , module_dir )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self", "module_dir" ], "start_line": 250, "end_line": 256, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "get_module_directory", "long_name": "get_module_directory( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 257, "end_line": 260, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "clear_module_directory", "long_name": "clear_module_directory( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 261, "end_line": 264, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "get_environ_path", "long_name": "get_environ_path( self )", "filename": "catalog.py", "nloc": 9, "complexity": 3, "token_count": 55, "parameters": [ "self" ], "start_line": 266, "end_line": 280, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "build_search_order", "long_name": "build_search_order( self )", "filename": "catalog.py", "nloc": 11, "complexity": 4, "token_count": 62, "parameters": [ "self" ], "start_line": 282, "end_line": 304, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "get_catalog_files", "long_name": "get_catalog_files( self )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 34, "parameters": [ "self" ], "start_line": 306, "end_line": 315, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_existing_files", "long_name": "get_existing_files( self )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 27, "parameters": [ "self" ], "start_line": 317, "end_line": 322, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_writable_file.file_test", "long_name": "get_writable_file.file_test( x )", "filename": "catalog.py", "nloc": 4, "complexity": 3, "token_count": 43, "parameters": [ "x" ], "start_line": 336, "end_line": 339, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 2 }, { "name": "get_writable_file", "long_name": "get_writable_file( self , existing_only = 0 )", "filename": "catalog.py", "nloc": 12, "complexity": 3, "token_count": 55, "parameters": [ "self", "existing_only" ], "start_line": 324, "end_line": 345, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "get_writable_dir", "long_name": "get_writable_dir( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self" ], "start_line": 347, "end_line": 352, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "unique_module_name", "long_name": "unique_module_name( self , code , module_dir = None )", "filename": "catalog.py", "nloc": 9, "complexity": 4, "token_count": 53, "parameters": [ "self", "code", "module_dir" ], "start_line": 354, "end_line": 369, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "path_key", "long_name": "path_key( self , code )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "self", "code" ], "start_line": 371, "end_line": 374, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "configure_path", "long_name": "configure_path( self , cat , code )", "filename": "catalog.py", "nloc": 7, "complexity": 2, "token_count": 47, "parameters": [ "self", "cat", "code" ], "start_line": 376, "end_line": 388, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "unconfigure_path", "long_name": "unconfigure_path( self )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 390, "end_line": 396, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "get_cataloged_functions", "long_name": "get_cataloged_functions( self , code )", "filename": "catalog.py", "nloc": 15, "complexity": 5, "token_count": 86, "parameters": [ "self", "code" ], "start_line": 398, "end_line": 427, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 30, "top_nesting_level": 1 }, { "name": "repair_catalog", "long_name": "repair_catalog( self , catalog_path , code )", "filename": "catalog.py", "nloc": 14, "complexity": 4, "token_count": 72, "parameters": [ "self", "catalog_path", "code" ], "start_line": 430, "end_line": 454, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 1 }, { "name": "get_functions_fast", "long_name": "get_functions_fast( self , code )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 20, "parameters": [ "self", "code" ], "start_line": 456, "end_line": 461, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_functions", "long_name": "get_functions( self , code , module_dir = None )", "filename": "catalog.py", "nloc": 13, "complexity": 5, "token_count": 69, "parameters": [ "self", "code", "module_dir" ], "start_line": 463, "end_line": 497, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 35, "top_nesting_level": 1 }, { "name": "add_function", "long_name": "add_function( self , code , function , module_dir = None )", "filename": "catalog.py", "nloc": 12, "complexity": 4, "token_count": 94, "parameters": [ "self", "code", "function", "module_dir" ], "start_line": 499, "end_line": 527, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 29, "top_nesting_level": 1 }, { "name": "add_function_persistent", "long_name": "add_function_persistent( self , code , function )", "filename": "catalog.py", "nloc": 24, "complexity": 5, "token_count": 166, "parameters": [ "self", "code", "function" ], "start_line": 529, "end_line": 566, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 38, "top_nesting_level": 1 }, { "name": "fast_cache", "long_name": "fast_cache( self , code , function )", "filename": "catalog.py", "nloc": 11, "complexity": 4, "token_count": 59, "parameters": [ "self", "code", "function" ], "start_line": 568, "end_line": 590, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "test", "long_name": "test( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 592, "end_line": 594, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 596, "end_line": 598, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "methods_before": [ { "name": "getmodule", "long_name": "getmodule( object )", "filename": "catalog.py", "nloc": 13, "complexity": 7, "token_count": 75, "parameters": [ "object" ], "start_line": 37, "end_line": 62, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "expr_to_filename", "long_name": "expr_to_filename( expr )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 24, "parameters": [ "expr" ], "start_line": 64, "end_line": 73, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "unique_file", "long_name": "unique_file( d , expr )", "filename": "catalog.py", "nloc": 13, "complexity": 8, "token_count": 89, "parameters": [ "d", "expr" ], "start_line": 75, "end_line": 97, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 0 }, { "name": "default_dir", "long_name": "default_dir( )", "filename": "catalog.py", "nloc": 18, "complexity": 5, "token_count": 145, "parameters": [], "start_line": 99, "end_line": 132, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 34, "top_nesting_level": 0 }, { "name": "default_temp_dir", "long_name": "default_temp_dir( )", "filename": "catalog.py", "nloc": 9, "complexity": 3, "token_count": 64, "parameters": [], "start_line": 134, "end_line": 142, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 0 }, { "name": "os_dependent_catalog_name", "long_name": "os_dependent_catalog_name( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 145, "end_line": 157, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 0 }, { "name": "catalog_path", "long_name": "catalog_path( module_path )", "filename": "catalog.py", "nloc": 12, "complexity": 3, "token_count": 105, "parameters": [ "module_path" ], "start_line": 159, "end_line": 184, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "get_catalog", "long_name": "get_catalog( module_path , mode = 'r' )", "filename": "catalog.py", "nloc": 7, "complexity": 2, "token_count": 35, "parameters": [ "module_path", "mode" ], "start_line": 186, "end_line": 204, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 0 }, { "name": "__init__", "long_name": "__init__( self , user_path_list = None )", "filename": "catalog.py", "nloc": 10, "complexity": 3, "token_count": 60, "parameters": [ "self", "user_path_list" ], "start_line": 233, "end_line": 248, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "set_module_directory", "long_name": "set_module_directory( self , module_dir )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self", "module_dir" ], "start_line": 250, "end_line": 256, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "get_module_directory", "long_name": "get_module_directory( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 257, "end_line": 260, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "clear_module_directory", "long_name": "clear_module_directory( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 261, "end_line": 264, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "get_environ_path", "long_name": "get_environ_path( self )", "filename": "catalog.py", "nloc": 9, "complexity": 3, "token_count": 55, "parameters": [ "self" ], "start_line": 266, "end_line": 280, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "build_search_order", "long_name": "build_search_order( self )", "filename": "catalog.py", "nloc": 11, "complexity": 4, "token_count": 62, "parameters": [ "self" ], "start_line": 282, "end_line": 304, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "get_catalog_files", "long_name": "get_catalog_files( self )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 34, "parameters": [ "self" ], "start_line": 306, "end_line": 315, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_existing_files", "long_name": "get_existing_files( self )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 27, "parameters": [ "self" ], "start_line": 317, "end_line": 322, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_writable_file.file_test", "long_name": "get_writable_file.file_test( x )", "filename": "catalog.py", "nloc": 4, "complexity": 3, "token_count": 43, "parameters": [ "x" ], "start_line": 336, "end_line": 339, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 2 }, { "name": "get_writable_file", "long_name": "get_writable_file( self , existing_only = 0 )", "filename": "catalog.py", "nloc": 12, "complexity": 3, "token_count": 55, "parameters": [ "self", "existing_only" ], "start_line": 324, "end_line": 345, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "get_writable_dir", "long_name": "get_writable_dir( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self" ], "start_line": 347, "end_line": 352, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "unique_module_name", "long_name": "unique_module_name( self , code , module_dir = None )", "filename": "catalog.py", "nloc": 9, "complexity": 4, "token_count": 53, "parameters": [ "self", "code", "module_dir" ], "start_line": 354, "end_line": 369, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "path_key", "long_name": "path_key( self , code )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "self", "code" ], "start_line": 371, "end_line": 374, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "configure_path", "long_name": "configure_path( self , cat , code )", "filename": "catalog.py", "nloc": 7, "complexity": 2, "token_count": 47, "parameters": [ "self", "cat", "code" ], "start_line": 376, "end_line": 388, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "unconfigure_path", "long_name": "unconfigure_path( self )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 390, "end_line": 396, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "get_cataloged_functions", "long_name": "get_cataloged_functions( self , code )", "filename": "catalog.py", "nloc": 15, "complexity": 5, "token_count": 86, "parameters": [ "self", "code" ], "start_line": 398, "end_line": 427, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 30, "top_nesting_level": 1 }, { "name": "repair_catalog", "long_name": "repair_catalog( self , catalog_path , code )", "filename": "catalog.py", "nloc": 14, "complexity": 4, "token_count": 72, "parameters": [ "self", "catalog_path", "code" ], "start_line": 430, "end_line": 454, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 1 }, { "name": "get_functions_fast", "long_name": "get_functions_fast( self , code )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 20, "parameters": [ "self", "code" ], "start_line": 456, "end_line": 461, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_functions", "long_name": "get_functions( self , code , module_dir = None )", "filename": "catalog.py", "nloc": 13, "complexity": 5, "token_count": 69, "parameters": [ "self", "code", "module_dir" ], "start_line": 463, "end_line": 497, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 35, "top_nesting_level": 1 }, { "name": "add_function", "long_name": "add_function( self , code , function , module_dir = None )", "filename": "catalog.py", "nloc": 12, "complexity": 4, "token_count": 94, "parameters": [ "self", "code", "function", "module_dir" ], "start_line": 499, "end_line": 527, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 29, "top_nesting_level": 1 }, { "name": "add_function_persistent", "long_name": "add_function_persistent( self , code , function )", "filename": "catalog.py", "nloc": 24, "complexity": 5, "token_count": 166, "parameters": [ "self", "code", "function" ], "start_line": 529, "end_line": 566, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 38, "top_nesting_level": 1 }, { "name": "fast_cache", "long_name": "fast_cache( self , code , function )", "filename": "catalog.py", "nloc": 11, "complexity": 4, "token_count": 59, "parameters": [ "self", "code", "function" ], "start_line": 568, "end_line": 590, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "test", "long_name": "test( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 592, "end_line": 594, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 596, "end_line": 598, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "changed_methods": [], "nloc": 319, "complexity": 90, "token_count": 1724, "diff_parsed": { "added": [ " returned by temfile.gettempdir(). Functions closer to the front are of" ], "deleted": [ " returned by temfile.tempdir(). Functions closer to the front are of" ] } }, { "old_path": "weave/doc/tutorial.html", "new_path": "weave/doc/tutorial.html", "filename": "tutorial.html", "extension": "html", "change_type": "MODIFY", "diff": "@@ -81,8 +81,8 @@

Outline

\n

Introduction

\n \n

\n-The weave package allows the inclusion of C/C++ within \n-Python code. This offers both another level of optimization to those who need \n+The weave package provides tools for including C/C++ code within\n+in Python code. This offers both another level of optimization to those who need \n it, and an easy way to modify and extend any supported extension libraries such \n as wxPython and hopefully VTK soon. Inlining C/C++ code within Python generally\n results in speed ups of 1.5x to 30x speed-up over algorithms written in pure\n@@ -94,7 +94,7 @@

Introduction

\n There are three basic ways to use weave. The \n weave.inline() function executes C code directly within Python, \n and weave.blitz() translates Python Numeric expressions to C++ \n-for fast execution. This was the original functionality for which \n+for fast execution. blitz() was the original reason \n weave was built. For those interested in building extension\n libraries, the ext_tools module provides classes for building \n extension modules within Python. \n@@ -103,8 +103,9 @@

Introduction

\n although some of its functionality requires gcc or a similarly \n modern C++ compiler that handles templates well. Up to now, most testing has \n been done on Windows 2000 with Microsoft's C++ compiler (MSVC) and with gcc \n-(mingw32 2.95.2 and 2.95.3-6). All tests also seem to pass on Linux (RH 7.1 \n-with gcc 2.96).\n+(mingw32 2.95.2 and 2.95.3-6). All tests also pass on Linux (RH 7.1 \n+with gcc 2.96), and I've had reports that it works on Debian also (thanks \n+Pearu).\n

\n The inline and blitz provide new functionality to \n Python (although I've recently learned about the Introduction\n building Python extension modules already exists (SWIG, SIP, pycpp, CXX, and \n others). As of yet, I'm not sure where weave fits in this \n spectrum. It is closest in flavor to CXX in that it makes creating new C/C++ \n-extension modules pretty easy. However, If you're wrapping a gaggle of legacy \n+extension modules pretty easy. However, if you're wrapping a gaggle of legacy \n functions or classes, SWIG and friends are definitely the better choice. \n weave is set up so that you can customize how Python types are \n converted to C types in weave. This is great for \n-inline(), but, for wrapping legacy code, it is generally better to \n-specify things the other way around -- that is how C types map to \n-Python types. This weave does not do. I guess it would be \n-possible to build such a tool on top of weave, but with good \n-tools like SWIG around, I'm not sure the effort produces any new capabilities. \n-Things like function overloading are probably easily implemented in \n-weave and it might be easier to mix Python/C code in function \n-calls, but nothing beyond this comes to mind. So, if you're developing new \n-extension modules, or just want to optimize a few functions in C, \n-weave might be the tool for you. If you're wrapping legacy code, \n-stick with SWIG.\n+inline(), but, for wrapping legacy code, it is more flexible to \n+specify things the other way around -- that is how C types map to Python types. \n+This weave does not do. I guess it would be possible to build \n+such a tool on top of weave, but with good tools like SWIG around, \n+I'm not sure the effort produces any new capabilities. Things like function \n+overloading are probably easily implemented in weave and it might \n+be easier to mix Python/C code in function calls, but nothing beyond this comes \n+to mind. So, if you're developing new extension modules or optimizing Python \n+functions in C, weave.ext_tools() might be the tool \n+for you. If you're wrapping legacy code, stick with SWIG.\n

\n The next several sections give the basics of how to use weave.\n We'll discuss what's happening under the covers in more detail later \n@@ -1257,7 +1257,7 @@

Returning Values

\n \t results[1] = Py::String(\"2nd\");\n \t return_val = Py::new_reference_to(results); \t \n \"\"\"\n- return inline_tools.inline(code,[])\n+ return inline_tools.inline(code)\n \n

\n The example is available in examples/tuple_return.py. It also\n@@ -1505,7 +1505,7 @@

Type Conversions

\n Python to C++ conversions fill in code in several locations in the generated\n inline extension function. Below is the basic template for the\n function. This is actually the exact code that is generated by calling\n-weave.inline(\"\",[]).\n+weave.inline(\"\").\n \n 
\n     static PyObject* compiled_func(PyObject*self, PyObject* args)\n@@ -1720,7 +1720,7 @@ 
 File Conversion 
\n sys.stdout and sys.stderr.  For example, instead of\n \n     
\n-    >>> weave.inline('printf(\"hello\\\\n\");',[])\n+    >>> weave.inline('printf(\"hello\\\\n\");')\n     
\n     \n You might try:\n",
                "added_lines": 20,
                "deleted_lines": 20,
                "source_code": "\n
Weave Documentation
\n
\nBy Eric Jones eric@enthought.com\n
\n
Outline
\n
 \n
 Introduction\n
 Requirements\n
 Installation and Testing\n
 Inline\n    
\n        
More with printf\n        
\n        More examples\n        
\n            
Binary search\n            
Dictionary sort\n            
Numeric -- cast/copy/transpose\n            
wxPython
\n        
\n        
Keyword options\n        
Returning values\n        
\n            
\n                        The issue with locals()
\n        
\n        
A quick look at the code\n        
\n        Technical Details\n        
\n            
Converting Types\n                
\n                    
\n                        Numeric Argument Conversion\n                    
\n                        String, List, Tuple, and Dictionary Conversion\n                    
File Conversion \n                        
\n                        Callable, Instance, and Module Conversion                \n                    
Customizing Conversions\n                
    \n            
Compiling Code\n            
\"Cataloging\" functions\n            
\n                
Function Storage\n                
The PYTHONCOMPILED evnironment variable
\n            
\n            
    \n        
\n        
        \n    
\n
Blitz\n    
\n        
Requirements\n        
Limitations\n        
Numeric Efficiency Issues\n        
The Tools        \n        
\n            
Parser\n            
Blitz and Numeric\n        
\n        
Type defintions and coersion\n        
Cataloging Compiled Functions\n        
Checking Array Sizes\n         
Creating the Extension Module\n    
\n
  Extension Modules\n    
\n        
A Simple Example\n        
Fibonacci Example\n   
\n
  Customizing Type Conversions -- Type Factories (not written)\n    
\n        
Type Specifications\n        
Type Information\n        
The Conversion Process    \n    
    \n
\n\n
Introduction
\n\n
\nThe weave package provides tools for including C/C++ code within\nin Python code.  This offers both another level of optimization to those who need \nit, and an easy way to modify and extend any supported extension libraries such \nas wxPython and hopefully VTK soon. Inlining C/C++ code within Python generally\nresults in speed ups of 1.5x to 30x speed-up over algorithms written in pure\nPython (However, it is also possible to slow things down...).  Generally \nalgorithms that require a large number of calls to the Python API don't benefit\nas much from the conversion to C/C++ as algorithms that have inner loops \ncompletely convertable to C.\n
 \nThere are three basic ways to use weave. The \nweave.inline() function executes C code directly within Python, \nand weave.blitz() translates Python Numeric expressions to C++ \nfor fast execution.  blitz() was the original reason \nweave was built.  For those interested in building extension\nlibraries, the ext_tools module provides classes for building \nextension modules within Python. \n
\nMost of weave's functionality should work on Windows and Unix, \nalthough some of its functionality requires gcc or a similarly \nmodern C++ compiler that handles templates well.  Up to now, most testing has \nbeen done on Windows 2000 with Microsoft's C++ compiler (MSVC) and with gcc \n(mingw32 2.95.2 and 2.95.3-6). All tests also pass on Linux (RH 7.1 \nwith gcc 2.96), and I've had reports that it works on Debian also (thanks \nPearu).\n
\nThe inline and blitz provide new functionality to \nPython (although I've recently learned about the PyInline project which may offer \nsimilar functionality to inline).  On the other hand, tools for \nbuilding Python extension modules already exists (SWIG, SIP, pycpp, CXX, and \nothers). As of yet, I'm not sure where weave fits in this \nspectrum. It is closest in flavor to CXX in that it makes creating new C/C++ \nextension modules pretty easy. However, if you're wrapping a gaggle of legacy \nfunctions or classes, SWIG and friends are definitely the better choice. \nweave is set up so that you can customize how Python types are \nconverted to C types in weave. This is great for \ninline(), but, for wrapping legacy code, it is more flexible to \nspecify things the other way around -- that is how C types map to Python types. \nThis weave does not do.  I guess it would be possible to build \nsuch a tool on top of weave, but with good tools like SWIG around, \nI'm not sure the effort produces any new capabilities. Things like function \noverloading are probably easily implemented in weave and it might \nbe easier to mix Python/C code in function calls, but nothing beyond this comes \nto mind. So, if you're developing new extension modules or optimizing Python \nfunctions in C, weave.ext_tools() might be the tool \nfor you. If you're wrapping legacy code, stick with SWIG.\n
\nThe next several sections give the basics of how to use weave.\nWe'll discuss what's happening under the covers in more detail later \non.  Serious users will need to at least look at the type conversion section to \nunderstand how Python variables map to C/C++ types and how to customize this \nbehavior.  One other note.  If you don't know C or C++ then these docs are \nprobably of very little help to you. Further, it'd be helpful if you know \nsomething about writing Python extensions. weave does quite a \nbit for you, but for anything complex, you'll need to do some conversions, \nreference counting, etc.\n
\n\nNote: weave is actually part of the SciPy package.  However, it works fine as a \nstandalone package.  The examples here are given as if it is used as a stand \nalone package.  If you are using from within scipy, you can use  from \nscipy import weave and the examples will work identically.\n\n\n
Requirements
\n
    \n    
  •  Python\n         
    \n         I use 2.1.1.  Probably 2.0 or higher should work.\n         
    \n    
    • \n    \n    
  •  C++ compiler\n         
    \n         weave uses distutils to actually build \n         extension modules, so it uses whatever compiler was originally used to \n         build Python.  weave itself requires a C++ compiler.  If \n         you used a C++ compiler to build Python, your probably fine.\n         
    \n         On Unix gcc is the preferred choice, because I've done a little \n         testing with it.  All testing has been done with gcc, but I expect the \n         majority of compilers should work for inline and \n         ext_tools.  The one issue I'm not sure about is that I've \n         hard coded things so that compilations are linked with the \n         stdc++ library.  Is this standard across \n         Unix compilers, or is this a gcc-ism?\n         
    \n         For blitz(), you'll need a reasonably recent version of \n         gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n         versions are likely to work.  Its likely that KAI's C++ compiler and \n         maybe some others will work, but I haven't tried. My advise is to use \n         gcc for now unless your willing to tinker with the code some.\n         
    \n         On Windows, either MSVC or gcc (www.mingw.org\" > mingw32) should work.  Again, \n         you'll need gcc for blitz() as the\n         MSVC compiler doesn't handle templates well.\n         
    \n         I have not tried Cygwin, so please report success if it works for you.\n         
    \n    
    • \n\n    
  •  Numeric (optional)\n         
    \n         The python Numeric module from here. is required for \n         blitz() to work. Be sure and get NumPy, not NumArray\n         which is the \"next generation\" implementation.\n         
    \n    
    • \n    
  •  scipy_distutils and scipy_test (packaged with weave)\n         
    \n         These two modules are packaged with weave in both\n         the windows installer and the source distributions.  If you are using\n         CVS, however, you'll need to download these separately (also available\n         through CVS at SciPy).\n         
    \n    
    • \n
\n
\n\n\n
Installation and Testing
\n
\nThere are currently two ways to get weave. Fist, \nweave is part of SciPy and installed automatically (as a sub-\npackage) whenever SciPy is installed (although the latest version isn't in \nSciPy yet, so use this one for now).  Second, since weave is \nuseful outside of the scientific community, it has been setup so that it can be\nused as a stand-alone module. \n\n
\nThe stand-alone version can be downloaded from here.  Unix users should grab the \ntar ball (.tgz file) and install it using the following commands.\n\n    
\n    tar -xzvf weave-0.2.tar.gz\n    cd weave-0.2\n    python setup.py install\n    
        \n\nThis will also install two other packages, scipy_distutils and \nscipy_test.  The first is needed by the setup process itself and \nboth are used in the unit-testing process. For Windows users, it's even easier. \nThey can download the click-install .exe file and run it for automatic \ninstallation.  Numeric is required if you want to use blitz(), but\nisn't necessary for inline() or ext_tools\n
\nIf you're using the CVS version, you'll need to install scipy_distutils and \nscipy_test modules (also available from CVS) on your own.\n
\n Note: The dependency issue here is a little sticky.  I hate to make people \ndownload more than one file (and so I haven't), but distutils doesn't have a \nway to do conditional installation -- at least that I know about.  This can \nlead to undesired clobbering of modules.  What to do, what to do...\n
\nOnce weave is installed, fire up python and run its unit tests.\n\n    
\n    >>> import weave\n    >>> weave.test()\n    runs long time... spews tons of output\n    
        \n\nThis takes a loooong time.  On windows, it is usually several minutes.  On Unix \nwith remote file systems, I've had it take 15 or so minutes.  In the end, it \nshould run about 150 tests and spew some speed results along the way.  If you \nget errors, please let me know.\n\nIf you don't have Numeric installed, you'll get some module import errors \nduring the test setup phase for modules that are Numeric specific (blitz_spec, \nblitz_tools, size_check, standard_array_spec, ast_tools), but all test should\npass (about 60 and the run time should be quite a bit less).\n
\nIf you only want to test a single module of the package, you can do this by\nrunning test() for that specific module.\n\n    
\n    >>> import weave.scalar_spec\n    >>> weave.scalar_spec.test()\n    .......\n    ----------------------------------------------------------------------\n    Ran 7 tests in 23.284s\n    
        \n\nNote: I've had some test fail on windows machines where I have msvc, gcc-2.95.2 \n(in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My environment \nhas c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the path.  The test \nprocess runs very smoothly until the end where several test using gcc fail with \ncpp0 not found by g++.  If I check os.system('gcc -v') before running tests, I \nget gcc-2.95.3-6.  If I check after running tests (and after failure), I get \ngcc-2.95.2. ??huh??.  The os.environ['PATH'] still has c:\\gcc first in it and \nis not corrupted (msvc/distutils messes with the environment variables, so we \nhave to undo its work in some places).  If anyone else sees this, let me know -\n- it may just be an quirk on my machine (unlikely).  Testing with the gcc-\n2.95.2 installation always works.\n\n\n\n
Inline
\n
\ninline() compiles and executes C/C++ code on the fly.  Variables \nin the local and global Python scope are also available in the C/C++ code. \nValues are passed to the C/C++ code by assignment much like variables \nare passed into a standard Python function.  Values are returned from the C/C++ \ncode through a special argument called return_val.  Also, the contents of \nmutable objects can be changed within the C/C++ code and the changes remain \nafter the C code exits and returns to Python. (more on this later)\n
        \nHere's a trivial printf example using inline():\n\n    
\n    >>> import weave    \n    >>> a  = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n    
        \n
\nIn this, its most basic form, inline(c_code, var_list) requires two \narguments.  c_code is a string of valid C/C++ code. \nvar_list is a list of variable names that are passed from \nPython into C/C++.  Here we have a simple printf statement that \nwrites the Python variable a to the screen. The first time you run \nthis, there will be a pause while the code is written to a .cpp file, compiled \ninto an extension module, loaded into Python, cataloged for future use, and \nexecuted.  On windows (850 MHz PIII), this takes about 1.5 seconds when using \nMicrosoft's C++ compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). \nAll subsequent executions of the code will happen very quickly because the code \nonly needs to be compiled once.  If you kill and restart the interpreter and then \nexecute the same code fragment again, there will be a much shorter delay in the \nfractions of seconds range. This is because weave stores a \ncatalog of all previously compiled functions in an on disk cache. When it sees \na string that has been compiled, it loads the already compiled module and \nexecutes the appropriate function.  \n
\n\nNote: If you try the printf example in a GUI shell such as IDLE, \nPythonWin, PyShell, etc., you're unlikely to see the output.  This is because the \nC code is writing to stdout, instead of to the GUI window.  This doesn't mean \nthat inline doesn't work in these environments -- it only means that standard \nout in C is not the same as the standard out for Python in these cases.  Non \ninput/output functions will work as expected.\n\n
\nAlthough effort has been made to reduce the overhead associated with calling \ninline, it is still less efficient for simple code snippets than using \nequivalent Python code.  The simple printf example is actually \nslower by 30% or so than using Python print statement. And, it is \nnot difficult to create code fragments that are 8-10 times slower using inline \nthan equivalent Python.  However, for more complicated algorithms, \nthe speed up can be worth while -- anywhwere from 1.5- 30 times faster. \nAlgorithms that have to manipulate Python objects (sorting a list) usually only \nsee a factor of 2 or so improvement.  Algorithms that are highly computational \nor manipulate Numeric arrays can see much larger improvements.  The \nexamples/vq.py file shows a factor of 30 or more improvement on the vector \nquantization algorithm that is used heavily in information theory and \nclassification problems.\n
\n\n\n
More with printf
\n
\nMSVC users will actually see a bit of compiler output that distutils does not\nsupress the first time the code executes:\n\n    
    \n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    sc_e013937dbc8c647ac62438874e5795131.cpp\n       Creating library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\n       \\Release\\sc_e013937dbc8c647ac62438874e5795131.lib and object C:\\DOCUME\n       ~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_e013937dbc8c64\n       7ac62438874e5795131.exp\n    1\n    
\n
\nNothing bead is happening, its just a bit annoying.  Anyone know how to \nturn this off?    \n
\nThis example also demonstrates using 'raw strings'. The r \npreceeding the code string in the last example denotes that this is a 'raw \nstring'.  In raw strings, the backslash character is not interpreted as an \nescape character, and so it isn't necessary to use a double backslash to \nindicate that the '\\n' is meant to be interpreted in the C printf \nstatement instead of by Python.  If your C code contains a lot\nof strings and control characters, raw strings might make things easier.\nMost of the time, however, standard strings work just as well.\n\n
\nThe printf statement in these examples is formatted to print \nout integers.  What happens if a is a string?  inline\nwill happily, compile a new version of the code to accept strings as input,\nand execute the code.  The result?\n\n    
    \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    32956972\n    
      \n
\nIn this case, the result is non-sensical, but also non-fatal.  In other \nsituations, it might produce a compile time error because a is \nrequired to be an integer at some point in the code, or it could produce a \nsegmentation fault.  Its possible to protect against passing \ninline arguments of the wrong data type by using asserts in \nPython.\n\n    
    \n    >>> a = 'string'\n    >>> def protected_printf(a):    \n    ...     assert(type(a) == type(1))\n    ...     weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    >>> protected_printf(1)\n     1\n    >>> protected_printf('string')\n    AssertError...\n    
      \n\n
\nFor printing strings, the format statement needs to be changed.\n\n    
    \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%s\\n\",a);',['a'])\n    string\n    
      \n\n
\nAs in this case, C/C++ code fragments often have to change to accept different \ntypes. For the given printing task, however, C++ streams provide a way of a \nsingle statement that works for integers and strings.  By default, the stream \nobjects live in the std (standard) namespace and thus require the use of \nstd::.\n\n    
    \n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    1    \n    >>> a = 'string'\n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    string\n    
 \n         \n
\nExamples using printf and cout are included in \nexamples/print_example.py.\n\n\n
 More examples 
\n\nThis section shows several more advanced uses of inline.  It \nincludes a few algorithms from the Python Cookbook \nthat have been re-written in inline C to improve speed as well as a couple \nexamples using Numeric and wxPython.\n\n\n
 Binary search
\nLets look at the example of searching a sorted list of integers for a value. \nFor inspiration, we'll use Kalle Svensson's  \nbinary_search() algorithm from the Python Cookbook.  His recipe follows:\n\n    
\n    def binary_search(seq, t):\n        min = 0; max = len(seq) - 1\n        while 1:\n            if max < min:\n                return -1\n            m = (min  + max)  / 2\n            if seq[m] < t: \n                min = m  + 1 \n            elif seq[m] > t: \n                max = m  - 1 \n            else:\n                return m    \n
\n\nThis Python version works for arbitrary Python data types. The C version below is \nspecialized to handle integer values. There is a little type checking done in \nPython to assure that we're working with the correct data types before heading \ninto C. The variables seq and t don't need to be \ndeclared beacuse weave handles converting and declaring them in \nthe C code. All other temporary variables such as min, max, etc. \nmust be declared -- it is C after all. Here's the new mixed Python/C function:\n\n 
    \n    def c_int_binary_search(seq,t):\n        # do a little type checking in Python\n        assert(type(t) == type(1))\n        assert(type(seq) == type([]))\n        \n        # now the C code\n        code = \"\"\"\n               #line 29 \"binary_search.py\"\n               int val, m, min = 0;  \n               int max = seq.length() - 1;\n               PyObject *py_val; \n               for(;;)\n               {\n                   if (max < min  ) \n                   { \n                       return_val =  Py::new_reference_to(Py::Int(-1)); \n                       break;\n                   } \n                   m =  (min + max) /2;\n                   val =    py_to_int(PyList_GetItem(seq.ptr(),m),\"val\"); \n                   if (val  < t) \n                       min = m  + 1;\n                   else if (val >  t)\n                       max = m - 1;\n                   else\n                   {\n                       return_val = Py::new_reference_to(Py::Int(m));\n                       break;\n                   }\n               }\n               \"\"\"\n        return inline(code,['seq','t'])\n
\n

\nWe have two variables seq and t passed in. \nt is guaranteed (by the assert) to be an integer. \nPython integers are converted to C int types in the transition from Python to \nC. seq is a Python list. By default, it is translated to a CXX \nlist object. Full documentation for the CXX library can be found at its website. The basics are that the CXX \nprovides C++ class equivalents for Python objects that simplify, or at \nleast object orientify, working with Python objects in C/C++. For example, \nseq.length() returns the length of the list. A little more about\nCXX and its class methods, etc. is in the ** type conversions ** section.\n

\nMost of the algorithm above looks similar in C to the original Python code. \nThere are two main differences. The first is the setting of \nreturn_val instead of directly returning from the C code with a \nreturn statement. return_val is an automatically \ndefined variable of type PyObject* that is returned from the C \ncode back to Python. You'll have to handle reference counting issues when \nsetting this variable. In this example, CXX classes and functions handle the \ndirty work. All CXX functions and classes live in the namespace \nPy::. The following code converts the integer m to a \nCXX Int() object and then to a PyObject* with an \nincremented reference count using Py::new_reference_to().\n\n 

   \n    return_val = Py::new_reference_to(Py::Int(m));\n
\n

\nThe second big differences shows up in the retrieval of integer values from the \nPython list. The simple Python seq[i] call balloons into a C \nPython API call to grab the value out of the list and then a separate call to \npy_to_int() that converts the PyObject* to an integer. \npy_to_int() includes both a NULL cheack and a \nPyInt_Check() call as well as the conversion call. If either of \nthe checks fail, an exception is raised. The entire C++ code block is executed \nwith in a try/catch block that handles exceptions much like Python \ndoes. This removes the need for most error checking code.\n

\nIt is worth note that CXX lists do have indexing operators that result \nin code that looks much like Python. However, the overhead in using them \nappears to be relatively high, so the standard Python API was used on the \nseq.ptr() which is the underlying PyObject* of the \nList object.\n

\nThe #line directive that is the first line of the C code \nblock isn't necessary, but it's nice for debugging. If the compilation fails \nbecause of the syntax error in the code, the error will be reported as an error \nin the Python file \"binary_search.py\" with an offset from the given line number \n(29 here).\n

\nSo what was all our effort worth in terms of efficiency? Well not a lot in \nthis case. The examples/binary_search.py file runs both Python and C versions \nof the functions As well as using the standard bisect module. If \nwe run it on a 1 million element list and run the search 3000 times (for 0-\n2999), here are the results we get:\n\n 

   \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python binary_search.py\n    Binary search for 3000 items in 1000000 length list of integers:\n     speed in python: 0.159999966621\n     speed of bisect: 0.121000051498\n     speed up: 1.32\n     speed in c: 0.110000014305\n     speed up: 1.45\n     speed in c(no asserts): 0.0900000333786\n     speed up: 1.78\n
\n

\nSo, we get roughly a 50-75% improvement depending on whether we use the Python \nasserts in our C version. If we move down to searching a 10000 element list, \nthe advantage evaporates. Even smaller lists might result in the Python \nversion being faster. I'd like to say that moving to Numeric lists (and \ngetting rid of the GetItem() call) offers a substantial speed up, but my \npreliminary efforts didn't produce one. I think the log(N) algorithm is to \nblame. Because the algorithm is nice, there just isn't much time spent \ncomputing things, so moving to C isn't that big of a win. If there are ways to \nreduce conversion overhead of values, this may improve the C/Python speed \nup. Anyone have other explanations or faster code, please let me know.\n\n\n

Dictionary Sort

\n

\nThe demo in examples/dict_sort.py is another example from the Python CookBook. \nThis \nsubmission, by Alex Martelli, demonstrates how to return the values from a \ndictionary sorted by their keys:\n\n 

       \n    def sortedDictValues3(adict):\n        keys = adict.keys()\n        keys.sort()\n        return map(adict.get, keys)\n
\n

\nAlex provides 3 algorithms and this is the 3rd and fastest of the set. The C \nversion of this same algorithm follows:\n\n 

       \n    def c_sort(adict):\n        assert(type(adict) == type({}))\n        code = \"\"\"     \n        #line 21 \"dict_sort.py\"  \n        Py::List keys = adict.keys();\n        Py::List items(keys.length()); keys.sort();     \n        PyObject* item = NULL; \n        for(int i = 0;  i < keys.length();i++)\n        {\n            item = PyList_GET_ITEM(keys.ptr(),i);\n            item = PyDict_GetItem(adict.ptr(),item);\n            Py_XINCREF(item);\n            PyList_SetItem(items.ptr(),i,item);              \n        }           \n        return_val = Py::new_reference_to(items);\n        \"\"\"   \n        return inline_tools.inline(code,['adict'],verbose=1)\n
\n

\nLike the original Python function, the C++ version can handle any Python \ndictionary regardless of the key/value pair types. It uses CXX objects for the \nmost part to declare python types in C++, but uses Python API calls to manipulate \ntheir contents. Again, this choice is made for speed. The C++ version, while\nmore complicated, is about a factor of 2 faster than Python.\n\n 

       \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python dict_sort.py\n    Dict sort of 1000 items for 300 iterations:\n     speed in python: 0.319999933243\n    [0, 1, 2, 3, 4]\n     speed in c: 0.151000022888\n     speed up: 2.12\n    [0, 1, 2, 3, 4]\n
\n

\n\n

Numeric -- cast/copy/transpose

\n\nCastCopyTranspose is a function called quite heavily by Linear Algebra routines\nin the Numeric library. Its needed in part because of the row-major memory layout\nof multi-demensional Python (and C) arrays vs. the col-major order of the underlying\nFortran algorithms. For small matrices (say 100x100 or less), a significant\nportion of the common routines such as LU decompisition or singular value decompostion\nare spent in this setup routine. This shouldn't happen. Here is the Python\nversion of the function using standard Numeric operations.\n\n 
       \n    def _castCopyAndTranspose(type, array):\n        if a.typecode() == type:\n            cast_array = copy.copy(Numeric.transpose(a))\n        else:\n            cast_array = copy.copy(Numeric.transpose(a).astype(type))\n        return cast_array\n
\n\nAnd the following is a inline C version of the same function:\n\n 
\n    from weave.blitz_tools import blitz_type_factories\n    from weave import scalar_spec\n    from weave import inline\n    def _cast_copy_transpose(type,a_2d):\n        assert(len(shape(a_2d)) == 2)\n        new_array = zeros(shape(a_2d),type)\n        numeric_type = scalar_spec.numeric_to_blitz_type_mapping[type]\n        code = \\\n        \"\"\"  \n        for(int i = 0;i < _Na_2d[0]; i++)  \n            for(int j = 0;  j < _Na_2d[1]; j++)\n                new_array(i,j) = (%s) a_2d(j,i);\n        \"\"\" % numeric_type\n        inline(code,['new_array','a_2d'],\n               type_factories = blitz_type_factories,compiler='gcc')\n        return new_array\n
\n\nThis example uses blitz++ arrays instead of the standard representation of \nNumeric arrays so that indexing is simplier to write. This is accomplished by \npassing in the blitz++ \"type factories\" to override the standard Python to C++ \ntype conversions. Blitz++ arrays allow you to write clean, fast code, but they \nalso are sloooow to compile (20 seconds or more for this snippet). This is why \nthey aren't the default type used for Numeric arrays (and also because most \ncompilers can't compile blitz arrays...). inline() is also forced \nto use 'gcc' as the compiler because the default compiler on Windows (MSVC) \nwill not compile blitz code. 'gcc' I think will use the standard compiler \non Unix machine instead of explicitly forcing gcc (check this) \n\nComparisons of the Python vs inline C++ code show a factor of 3 speed up. Also \nshown are the results of an \"inplace\" transpose routine that can be used if the \noutput of the linear algebra routine can overwrite the original matrix (this is \noften appropriate). This provides another factor of 2 improvement.\n\n 
\n     #C:\\home\\ej\\wrk\\scipy\\weave\\examples> python cast_copy_transpose.py\n    # Cast/Copy/Transposing (150,150)array 1 times\n    #  speed in python: 0.870999932289\n    #  speed in c: 0.25\n    #  speed up: 3.48\n    #  inplace transpose c: 0.129999995232\n    #  speed up: 6.70\n
\n\n\n

wxPython

\n\ninline knows how to handle wxPython objects. Thats nice in and of\nitself, but it also demonstrates that the type conversion mechanism is reasonably \nflexible. Chances are, it won't take a ton of effort to support special types\nyou might have. The examples/wx_example.py borrows the scrolled window\nexample from the wxPython demo, accept that it mixes inline C code in the middle\nof the drawing function.\n\n 
\n    def DoDrawing(self, dc):\n        \n        red = wxNamedColour(\"RED\");\n        blue = wxNamedColour(\"BLUE\");\n        grey_brush = wxLIGHT_GREY_BRUSH;\n        code = \\\n        \"\"\"\n        #line 108 \"wx_example.py\" \n        dc->BeginDrawing();\n        dc->SetPen(wxPen(*red,4,wxSOLID));\n        dc->DrawRectangle(5,5,50,50);\n        dc->SetBrush(*grey_brush);\n        dc->SetPen(wxPen(*blue,4,wxSOLID));\n        dc->DrawRectangle(15, 15, 50, 50);\n        \"\"\"\n        inline(code,['dc','red','blue','grey_brush'])\n        \n        dc.SetFont(wxFont(14, wxSWISS, wxNORMAL, wxNORMAL))\n        dc.SetTextForeground(wxColour(0xFF, 0x20, 0xFF))\n        te = dc.GetTextExtent(\"Hello World\")\n        dc.DrawText(\"Hello World\", 60, 65)\n\n        dc.SetPen(wxPen(wxNamedColour('VIOLET'), 4))\n        dc.DrawLine(5, 65+te[1], 60+te[0], 65+te[1])\n        ...\n
\n\nHere, some of the Python calls to wx objects were just converted to C++ calls. There\nisn't any benefit, it just demonstrates the capabilities. You might want to use this\nif you have a computationally intensive loop in your drawing code that you want to \nspeed up.\n\nOn windows, you'll have to use the MSVC compiler if you use the standard wxPython\nDLLs distributed by Robin Dunn. Thats because MSVC and gcc, while binary\ncompatible in C, are not binary compatible for C++. In fact, its probably best, no \nmatter what platform you're on, to specify that inline use the same\ncompiler that was used to build wxPython to be on the safe side. There isn't currently\na way to learn this info from the library -- you just have to know. Also, at least\non the windows platform, you'll need to install the wxWindows libraries and link to \nthem. I think there is a way around this, but I haven't found it yet -- I get some\nlinking errors dealing with wxString. One final note. You'll probably have to\ntweak weave/wx_spec.py or weave/wx_info.py for your machine's configuration to\npoint at the correct directories etc. There. That should sufficiently scare people\ninto not even looking at this... :)\n\n\n

Keyword Options

\n

\nThe basic definition of the inline() function has a slew of \noptional variables. It also takes keyword arguments that are passed to \ndistutils as compiler options. The following is a formatted \ncut/paste of the argument section of inline's doc-string. It \nexplains all of the variables. Some examples using various options will \nfollow.\n\n 

       \n    def inline(code,arg_names,local_dict = None, global_dict = None, \n               force = 0, \n               compiler='',\n               verbose = 0, \n               support_code = None,\n               customize=None, \n               type_factories = None, \n               auto_downcast=1,\n               **kw):\n
\n\n \ninline has quite \na few options as listed below. Also, the keyword arguments for distutils \nextension modules are accepted to specify extra information needed for \ncompiling. \n
\n

inline Arguments:

\n
\n
\n
code
\n \n
\nstring. A string of valid C++ code. It should not \n specify a return statement. Instead it should assign results that need to be \n returned to Python in the return_val. \n
\n\n
arg_names
\n \n
\nlist of strings. A list of Python variable names \n that should be transferred from Python into the C/C++ code. \n
\n\n
local_dict
\n \n
\noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the local scope for the C/C++ \n code. If local_dict is not specified the local dictionary of the calling \n function is used. \n
\n\n
global_dict
\n \n
\noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the global scope for the C/C++ \n code. If global_dict is not specified the global dictionary of the calling \n function is used. \n
\n\n
force
\n \n
\noptional. 0 or 1. default 0. If 1, the C++ code is \n compiled every time inline is called. This is really only useful for \n debugging, and probably only useful if you're editing support_code a lot. \n
\n\n
compiler
\n \n
\noptional. string. The name of compiler to use when compiling. On windows, it \nunderstands 'msvc' and 'gcc' as well as all the compiler names understood by \ndistutils. On Unix, it'll only understand the values understoof by distutils. \n(I should add 'gcc' though to this).\n

\nOn windows, the compiler defaults to the Microsoft C++ compiler. If this isn't \navailable, it looks for mingw32 (the gcc compiler).\n

\nOn Unix, it'll probably use the same compiler that was used when compiling \nPython. Cygwin's behavior should be similar.

\n
\n\n
verbose
\n \n
\noptional. 0,1, or 2. defualt 0. Speficies how much \n much information is printed during the compile phase of inlining code. 0 is \n silent (except on windows with msvc where it still prints some garbage). 1 \n informs you when compiling starts, finishes, and how long it took. 2 prints \n out the command lines for the compilation process and can be useful if you're \n having problems getting code to work. Its handy for finding the name of the \n .cpp file if you need to examine it. verbose has no affect if the \n compilation isn't necessary. \n
\n\n
support_code
\n \n
\noptional. string. A string of valid C++ code \n declaring extra code that might be needed by your compiled function. This \n could be declarations of functions, classes, or structures. \n
\n\n
customize
\n \n
\noptional. base_info.custom_info object. An \n alternative way to specifiy support_code, headers, etc. needed by the \n function see the weave.base_info module for more details. (not sure \n this'll be used much). \n \n
\n
type_factories
\n \n
\noptional. list of type specification factories. These guys are what convert \nPython data types to C/C++ data types. If you'd like to use a different set of \ntype conversions than the default, specify them here. Look in the type \nconversions section of the main documentation for examples.\n
\n
auto_downcast
\n \n
\noptional. 0 or 1. default 1. This only affects functions that have Numeric \narrays as input variables. Setting this to 1 will cause all floating point \nvalues to be cast as float instead of double if all the Numeric arrays are of \ntype float. If even one of the arrays has type double or double complex, all \nvariables maintain there standard types.\n
\n
\n
\n\n

Distutils keywords:

\n
\ninline() also accepts a number of distutils keywords \nfor controlling how the code is compiled. The following descriptions have been \ncopied from Greg Ward's distutils.extension.Extension class doc-\nstrings for convenience:\n\n
\n
sources
\n \n
\n[string] list of source filenames, relative to the \n distribution root (where the setup script lives), in Unix form \n (slash-separated) for portability. Source files may be C, C++, SWIG (.i), \n platform-specific resource files, or whatever else is recognized by the \n \"build_ext\" command as source for a Python extension. Note: The module_path \n file is always appended to the front of this list \n
\n\n
include_dirs
\n \n
\n[string] list of directories to search for C/C++ \n header files (in Unix form for portability) \n
\n\n
define_macros
\n \n
\n[(name : string, value : string|None)] list of \n macros to define; each macro is defined using a 2-tuple, where 'value' is \n either the string to define it to or None to define it without a particular \n value (equivalent of \"#define FOO\" in source or -DFOO on Unix C compiler \n command line) \n
\n
undef_macros
\n \n
\n[string] list of macros to undefine explicitly \n
\n
library_dirs
\n
\n[string] list of directories to search for C/C++ libraries at link time \n
\n
libraries
\n
\n[string] list of library names (not filenames or paths) to link against \n
\n
runtime_library_dirs
\n
\n[string] list of directories to search for C/C++ libraries at run time (for \nshared extensions, this is when the extension is loaded) \n
\n\n
extra_objects
\n \n
\n[string] list of extra files to link with (eg. \n object files not implied by 'sources', static library that must be \n explicitly specified, binary resource files, etc.) \n
\n\n
extra_compile_args
\n \n
\n[string] any extra platform- and compiler-specific \n information to use when compiling the source files in 'sources'. For \n platforms and compilers where \"command line\" makes sense, this is typically \n a list of command-line arguments, but for other platforms it could be \n anything. \n
\n
extra_link_args
\n \n
\n[string] any extra platform- and compiler-specific \n information to use when linking object files together to create the \n extension (or to create a new static Python interpreter). Similar \n interpretation as for 'extra_compile_args'. \n
\n
export_symbols
\n \n
\n[string] list of symbols to be exported from a shared extension. Not used on \nall platforms, and not generally necessary for Python extensions, which \ntypically export exactly one symbol: \"init\" + extension_name. \n
\n
\n
\n\n\n

Keyword Option Examples

\nWe'll walk through several examples here to demonstrate the behavior of \ninline and also how the various arguments are used.\n\nIn the simplest (most) cases, code and arg_names\nare the only arguments that need to be specified. Here's a simple example\nrun on Windows machine that has Microsoft VC++ installed.\n\n 
\n    >>> from weave import inline\n    >>> a = 'string'\n    >>> code = \"\"\"\n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));\n    ...        \"\"\"\n    >>> inline(code,['a'])\n     sc_86e98826b65b047ffd2cd5f479c627f12.cpp\n    Creating\n       library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f12.lib\n    and object C:\\DOCUME~ 1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ff\n    d2cd5f479c627f12.exp\n    6\n    >>> inline(code,['a'])\n    6\n
\n \nWhen inline is first run, you'll notice that pause and some \ntrash printed to the screen. The \"trash\" is acutually part of the compilers\noutput that distutils does not supress. On Unix or windows machines with only\ngcc installed, the trash will not appear. On the second call, the code \nfragment is not compiled since it already exists, and only the answer is \nreturned. Now kill the interpreter and restart, and run the same code with\na different string.\n\n 
\n    >>> from weave import inline\n    >>> a = 'a longer string' \n    >>> code = \"\"\" \n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));  \n    ...        \"\"\"\n    >>> inline(code,['a'])\n    15\n
\n

\nNotice this time, inline() did not recompile the code because it\nfound the compiled function in the persistent catalog of functions. There is\na short pause as it looks up and loads the function, but it is much shorter \nthan compiling would require.\n

\nYou can specify the local and global dictionaries if you'd like (much like \nexec or eval() in Python), but if they aren't \nspecified, the \"expected\" ones are used -- i.e. the ones from the function that \ncalled inline() . This is accomplished through a little call \nframe trickery. Here is an example where the local_dict is specified using\nthe same code example from above:\n\n 

\n    >>> a = 'a longer string'\n    >>> b = 'an even  longer string' \n    >>> my_dict = {'a':b}\n    >>> inline(code,['a'])\n    15\n    >>> inline(code,['a'],my_dict)\n    21\n
\n \n

\nEverytime, the code is changed, inline does a \nrecompile. However, changing any of the other options in inline does not\nforce a recompile. The force option was added so that one\ncould force a recompile when tinkering with other variables. In practice,\nit is just as easy to change the code by a single character\n(like adding a space some place) to force the recompile. Note: It also \nmight be nice to add some methods for purging the cache and on disk \ncatalogs.\n

\nI use verbose sometimes for debugging. When set to 2, it'll \noutput all the information (including the name of the .cpp file) that you'd\nexpect from running a make file. This is nice if you need to examine the\ngenerated code to see where things are going haywire. Note that error\nmessages from failed compiles are printed to the screen even if verbose\n is set to 0.\n

\nThe following example demonstrates using gcc instead of the standard msvc \ncompiler on windows using same code fragment as above. Because the example has \nalready been compiled, the force=1 flag is needed to make \ninline() ignore the previously compiled version and recompile \nusing gcc. The verbose flag is added to show what is printed out:\n\n 

\n    >>>inline(code,['a'],compiler='gcc',verbose=2,force=1)\n    running build_ext    \n    building 'sc_86e98826b65b047ffd2cd5f479c627f13' extension \n    c:\\gcc-2.95.2\\bin\\g++.exe -mno-cygwin -mdll -O2 -w -Wstrict-prototypes -IC:\n    \\home\\ej\\wrk\\scipy\\weave -IC:\\Python21\\Include -c C:\\DOCUME~1\\eric\\LOCAL\n    S~1\\Temp\\python21_compiled\\sc_86e98826b65b047ffd2cd5f479c627f13.cpp -o C:\\D\n    OCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b04\n    7ffd2cd5f479c627f13.o    \n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxextensions.c (C:\\DOCUME~1\\eri\n    c\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxextensions.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxsupport.cxx (C:\\DOCUME~1\\eric\n    \\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxsupport.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\IndirectPythonInterface.cxx (C:\\\n    DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\indirectpythonin\n    terface.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxx_extensions.cxx (C:\\DOCUME~1\\\n    eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxx_extensions.o up-to-da\n    te)\n    writing C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86\n    e98826b65b047ffd2cd5f479c627f13.def\n    c:\\gcc-2.95.2\\bin\\dllwrap.exe --driver-name g++ -mno-cygwin -mdll -static -\n    -output-lib C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\l\n    ibsc_86e98826b65b047ffd2cd5f479c627f13.a --def C:\\DOCUME~1\\eric\\LOCALS~1\\Te\n    mp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f13.def \n    -s C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e9882\n    6b65b047ffd2cd5f479c627f13.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compil\n    ed\\temp\\Release\\cxxextensions.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\cxxsupport.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\indirectpythoninterface.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\n    \\python21_compiled\\temp\\Release\\cxx_extensions.o -LC:\\Python21\\libs -lpytho\n    n21 -o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\sc_86e98826b65b047f\n    fd2cd5f479c627f13.pyd\n    15\n
\n\nThat's quite a bit of output. verbose=1 just prints the compile\ntime.\n\n 
\n    >>>inline(code,['a'],compiler='gcc',verbose=1,force=1)\n    Compiling code...\n    finished compiling (sec):  6.00800001621\n    15\n
\n\n

\n Note: I've only used the weave option for switching between 'msvc'\nand 'gcc' on windows. It may have use on Unix also, but I don't know yet.\n\n\n

\nThe support_code argument is likely to be used a lot. It allows \nyou to specify extra code fragments such as function, structure or class \ndefinitions that you want to use in the code string. Note that \nchanges to support_code do not force a recompile. The \ncatalog only relies on code (for performance reasons) to determine \nwhether recompiling is necessary. So, if you make a change to support_code, \nyou'll need to alter code in some way or use the \nforce argument to get the code to recompile. I usually just add \nsome inocuous whitespace to the end of one of the lines in code \nsomewhere. Here's an example of defining a separate method for calculating\nthe string length:\n\n 

\n    >>> from weave import inline\n    >>> a = 'a longer string'\n    >>> support_code = \"\"\"\n    ...                PyObject* length(Py::String a)\n    ...                {\n    ...                    int l = a.length();  \n    ...                    return Py::new_reference_to(Py::Int(l)); \n    ...                }\n    ...                \"\"\"        \n    >>> inline(\"return_val = length(a);\",['a'],\n    ...        support_code = support_code)\n    15\n
\n

\ncustomize is a left over from a previous way of specifying \ncompiler options. It is a custom_info object that can specify \nquite a bit of information about how a file is compiled. These \ninfo objects are the standard way of defining compile information \nfor type conversion classes. However, I don't think they are as handy here, \nespecially since we've exposed all the keyword arguments that distutils can \nhandle. Between these keywords, and the support_code option, I \nthink customize may be obsolete. We'll see if anyone cares to use \nit. If not, it'll get axed in the next version.\n

\nThe type_factories variable is important to people who want to\ncustomize the way arguments are converted from Python to C. We'll talk about\nthis in the next chapter **xx** of this document when we discuss type\nconversions.\n

\nauto_downcast handles one of the big type conversion issues that\nis common when using Numeric arrays in conjunction with Python scalar values.\nIf you have an array of single precision values and multiply that array by a \nPython scalar, the result is upcast to a double precision array because the\nscalar value is double precision. This is not usually the desired behavior\nbecause it can double your memory usage. auto_downcast goes\nsome distance towards changing the casting precedence of arrays and scalars.\nIf your only using single precision arrays, it will automatically downcast all\nscalar values from double to single precision when they are passed into the\nC++ code. This is the default behavior. If you want all values to keep there\ndefault type, set auto_downcast to 0.\n

\n\n\n\n

Returning Values

\n\nPython variables in the local and global scope transfer seemlessly from Python \ninto the C++ snippets. And, if inline were to completely live up\nto its name, any modifications to variables in the C++ code would be reflected\nin the Python variables when control was passed back to Python. For example,\nthe desired behavior would be something like:\n\n 
\n    # THIS DOES NOT WORK\n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    2\n
\n\nInstead you get:\n\n 
\n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    1\n
\n \nVariables are passed into C++ as if you are calling a Python function. Python's \ncalling convention is sometimes called \"pass by assignment\". This means its as \nif a c_a = a assignment is made right before inline \ncall is made and the c_a variable is used within the C++ code. \nThus, any changes made to c_a are not reflected in Python's \na variable. Things do get a little more confusing, however, when \nlooking at variables with mutable types. Changes made in C++ to the contents \nof mutable types are reflected in the Python variables.\n\n 
\n    >>> a= [1,2]\n    >>> weave.inline(\"PyList_SetItem(a.ptr(),0,PyInt_FromLong(3));\",['a'])\n    >>> print a\n    [3, 2]\n
\n\nSo modifications to the contents of mutable types in C++ are seen when control\nis returned to Python. Modifications to immutable types such as tuples,\nstrings, and numbers do not alter the Python variables.\n\nIf you need to make changes to an immutable variable, you'll need to assign\nthe new value to the \"magic\" variable return_val in C++. This\nvalue is returned by the inline() function:\n\n 
\n    >>> a = 1\n    >>> a = weave.inline(\"return_val = Py::new_reference_to(Py::Int(a+1));\",['a'])  \n    >>> a\n    2\n
\n\nThe return_val variable can also be used to return newly created \nvalues. This is possible by returning a tuple. The following trivial example \nillustrates how this can be done:\n\n 
       \n    # python version\n    def multi_return():\n        return 1, '2nd'\n    \n    # C version.\n    def c_multi_return():    \n        code =  \"\"\"\n     \t        Py::Tuple results(2);\n     \t        results[0] = Py::Int(1);\n     \t        results[1] = Py::String(\"2nd\");\n     \t        return_val = Py::new_reference_to(results); \t        \n                \"\"\"\n        return inline_tools.inline(code)\n
\n

\nThe example is available in examples/tuple_return.py. It also\nhas the dubious honor of demonstrating how much inline() can \nslow things down. The C version here is about 10 times slower than the Python\nversion. Of course, something so trivial has no reason to be written in\nC anyway.\n\n\n

The issue with locals()

\n

\ninline passes the locals() and globals() \ndictionaries from Python into the C++ function from the calling function. It \nextracts the variables that are used in the C++ code from these dictionaries, \nconverts then to C++ variables, and then calculates using them. It seems like \nit would be trivial, then, after the calculations were finished to then insert \nthe new values back into the locals() and globals() \ndictionaries so that the modified values were reflected in Python. \nUnfortunately, as pointed out by the Python manual, the locals() dictionary is \nnot writable. \n

\n\nI suspect locals() is not writable because there are some \noptimizations done to speed lookups of the local namespace. I'm guessing local \nlookups don't always look at a dictionary to find values. Can someone \"in the \nknow\" confirm or correct this? Another thing I'd like to know is whether there \nis a way to write to the local namespace of another stack frame from C/C++. If \nso, it would be possible to have some clean up code in compiled functions that \nwrote final values of variables in C++ back to the correct Python stack frame. \nI think this goes a long way toward making inline truely live up \nto its name. I don't think we'll get to the point of creating variables in \nPython for variables created in C -- although I suppose with a C/C++ parser you \ncould do that also.\n\n

\n\n\n

A quick look at the code

\n\nweave generates a C++ file holding an extension function for \neach inline code snippet. These file names are generated using \nfrom the md5 signature of the code snippet and saved to a location specified by \nthe PYTHONCOMPILED environment variable (discussed later). The cpp files are \ngenerally about 200-400 lines long and include quite a few functions to support \ntype conversions, etc. However, the actual compiled function is pretty simple. \nBelow is the familiar printf example:\n\n 
\n    >>> import weave    \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
\n\nAnd here is the extension function generated by inline:\n\n 
\n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        // The Py_None needs an incref before returning\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n        \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try                              \n        {                                \n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n            /* Here is the inline code */            \n            printf(\"%d\\n\",a);\n            /* I would like to fill in changed locals and globals here... */\n        }                                       \n        catch( Py::Exception& e)           \n        {                                \n            return_val =  Py::Null();    \n            exception_occured = 1;       \n        }                                 \n        if(!return_val && !exception_occured)\n        {\n                                      \n            Py_INCREF(Py_None);              \n            return_val = Py_None;            \n        }\n        /* clean up code */\n        \n        /* return */                              \n        return return_val;           \n    }                                \n
\n\nEvery inline function takes exactly two arguments -- the local and global\ndictionaries for the current scope. All variable values are looked up out\nof these dictionaries. The lookups, along with all inline code \nexecution, are done within a C++ try block. If the variables\naren't found, or there is an error converting a Python variable to the \nappropriate type in C++, an exception is raised. The C++ exception\nis automatically converted to a Python exception by CXX and returned to Python.\n\nThe py_to_int() function illustrates how the conversions and\nexception handling works. py_to_int first checks that the given PyObject*\npointer is not NULL and is a Python integer. If all is well, it calls the\nPython API to convert the value to an int. Otherwise, it calls\nhandle_bad_type() which gathers information about what went wrong\nand then raises a CXX TypeError which returns to Python as a TypeError.\n\n 
\n    int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
\n\n 
\n    void handle_bad_type(PyObject* py_obj, char* good_type, char*  var_name)\n    {\n        char msg[500];\n        sprintf(msg,\"received '%s' type instead of '%s' for variable '%s'\",\n                find_type(py_obj),good_type,var_name);\n        throw Py::TypeError(msg);\n    }\n    \n    char* find_type(PyObject* py_obj)\n    {\n        if(py_obj == NULL) return \"C NULL value\";\n        if(PyCallable_Check(py_obj)) return \"callable\";\n        if(PyString_Check(py_obj)) return \"string\";\n        if(PyInt_Check(py_obj)) return \"int\";\n        if(PyFloat_Check(py_obj)) return \"float\";\n        if(PyDict_Check(py_obj)) return \"dict\";\n        if(PyList_Check(py_obj)) return \"list\";\n        if(PyTuple_Check(py_obj)) return \"tuple\";\n        if(PyFile_Check(py_obj)) return \"file\";\n        if(PyModule_Check(py_obj)) return \"module\";\n        \n        //should probably do more interagation (and thinking) on these.\n        if(PyCallable_Check(py_obj) && PyInstance_Check(py_obj)) return \"callable\";\n        if(PyInstance_Check(py_obj)) return \"instance\"; \n        if(PyCallable_Check(py_obj)) return \"callable\";\n        return \"unkown type\";\n    }\n
\n\nSince the inline is also executed within the try/catch\nblock, you can use CXX exceptions within your code. It is usually a bad idea\nto directly return from your code, even if an error occurs. This\nskips the clean up section of the extension function. In this simple example,\nthere isn't any clean up code, but in more complicated examples, there may\nbe some reference counting that needs to be taken care of here on converted\nvariables. To avoid this, either uses exceptions or set \nreturn_val to NULL and use if/then's to skip code\nafter errors.\n\n\n

Technical Details

\n

\nThere are \n

    \n
  1. Type conversion \n
  2. Generating C/C++ code \n
  3. Compile the code to an extension module \n
  4. Catalog (and cache) the function for future use
    5. \n
\n

\nItems 1 and 2 above are related, but most easily discussed separately. Type \nconversions are customizable by the user if needed. Understanding them is \npretty important for anything beyond trivial uses of inline. \nGenerating the C/C++ code is handled by ext_function and \next_module classes and . For the most part, compiling the code is \nhandled by distutils. Some customizations were needed, but they were \nrelatively minor and do not require changes to distutils itself (although a few \nchanges would be nice...). Cataloging is pretty simple in concept, but surprisingly\nrequired the most code to implement (and still likely needs some work). So,\nthis section covers items 1 and 4 from the list. Item 2 is covered later in\nthe chapter covering the ext_tools module, and distutils is covered\nby a completely separate document xxx.\n \n

Passing Variables in/out of the C/C++ code

\n\nNote: Passing variables into the C code is pretty straight forward, but there \nare subtlties to how variable modifications in C are returned to Python. see \nxxx for a more thorough discussion of this issue.\n \n\n\n

Type Conversions

\n\n\nNote: Maybe xxx_converter instead of xxx_specification is a more descriptive \nname.\n\n\n

\nBy default, inline() makes the following type conversions between\nPython and C++ types.\n

\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\n

Default Data Type Conversions

\n

Python

\n

C++

   int   int
   float   double
   complex   std::complex
   string   Py::String
   list   Py::List
   dict   Py::Dict
   tuple   Py::Tuple
   file   FILE*
   callable   PyObject*
   instance   PyObject*
   Numeric.array   PyArrayObject*
   wxXXX   wxXXX*
\n
\n

\nThe Py:: namespace is defined by the \nCXX library which has C++ class\nequivalents for many Python types. std:: is the namespace of the\nstandard library in C++.\n

\n\nNote: \n

    \n
  • I haven't figured out how to handle long int yet (I think they are currenlty converted \n to int - - check this). \n \n
  • \nHopefully VTK will be added to the list soon
    • \n
\n
    \n    \n

    \n\nPython to C++ conversions fill in code in several locations in the generated\ninline extension function. Below is the basic template for the\nfunction. This is actually the exact code that is generated by calling\nweave.inline(\"\").\n\n 

    \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n    \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try\n        {\n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            /* argument conversion code */\n            /* inline code */\n            /*I would like to fill in changed locals and globals here...*/\n    \n        }\n        catch( Py::Exception& e)\n        {\n            return_val =  Py::Null();\n            exception_occured = 1;\n        }\n        /* cleanup code */\n        if(!return_val && !exception_occured)\n        {\n    \n            Py_INCREF(Py_None);\n            return_val = Py_None;\n        }\n    \n        return return_val;\n    }\n
    \n\nThe /* inline code */ section is filled with the code passed to\nthe inline() function call. The \n/*argument convserion code*/ and /* cleanup code */\nsections are filled with code that handles conversion from Python to C++\ntypes and code that deallocates memory or manipulates reference counts before\nthe function returns. The following sections demostrate how these two areas\nare filled in by the default conversion methods.\n\n \nNote: I'm not sure I have reference counting correct on a few of these. The \nonly thing I increase/decrease the ref count on is Numeric arrays. If you\nsee an issue, please let me know.\n\n\n\n

    Numeric Argument Conversion

    \n\nInteger, floating point, and complex arguments are handled in a very similar\nfashion. Consider the following inline function that has a single integer \nvariable passed in:\n\n 
    \n    >>> a = 1\n    >>> inline(\"\",['a'])\n
    \n\nThe argument conversion code inserted for a is:\n\n 
    \n    /* argument conversion code */\n    int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
    \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_int() has the following\nform:\n\n 
    \n    static int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
    \n\nSimilarly, the float and complex conversion routines look like:\n\n 
        \n    static double py_to_float(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyFloat_Check(py_obj))\n            handle_bad_type(py_obj,\"float\", name);\n        return PyFloat_AsDouble(py_obj);\n    }\n    \n    static std::complex py_to_complex(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyComplex_Check(py_obj))\n            handle_bad_type(py_obj,\"complex\", name);\n        return std::complex(PyComplex_RealAsDouble(py_obj),\n                                    PyComplex_ImagAsDouble(py_obj));    \n    }\n
    \n\nNumeric conversions do not require any clean up code.\n\n\n

    String, List, Tuple, and Dictionary Conversion

    \n\nStrings, Lists, Tuples and Dictionary conversions are all converted to \nCXX types by default.\n\nFor the following code, \n\n 
    \n    >>> a = [1]\n    >>> inline(\"\",['a'])\n
    \n\nThe argument conversion code inserted for a is:\n\n 
    \n    /* argument conversion code */\n    Py::List a = py_to_list (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
    \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_list() and its\nfriends has the following form:\n\n 
        \n    static Py::List py_to_list(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyList_Check(py_obj))\n            handle_bad_type(py_obj,\"list\", name);\n        return Py::List(py_obj);\n    }\n    \n    static Py::String py_to_string(PyObject* py_obj,char* name)\n    {\n        if (!PyString_Check(py_obj))\n            handle_bad_type(py_obj,\"string\", name);\n        return Py::String(py_obj);\n    }\n\n    static Py::Dict py_to_dict(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyDict_Check(py_obj))\n            handle_bad_type(py_obj,\"dict\", name);\n        return Py::Dict(py_obj);\n    }\n    \n    static Py::Tuple py_to_tuple(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyTuple_Check(py_obj))\n            handle_bad_type(py_obj,\"tuple\", name);\n        return Py::Tuple(py_obj);\n    }\n
    \n\nCXX handles reference counts on for strings, lists, tuples, and dictionaries,\nso clean up code isn't necessary.\n\n\n

    File Conversion

    \n\nFor the following code, \n\n 
    \n    >>> a = open(\"bob\",'w')  \n    >>> inline(\"\",['a'])\n
    \n\nThe argument conversion code is:\n\n 
    \n    /* argument conversion code */\n    PyObject* py_a = get_variable(\"a\",raw_locals,raw_globals);\n    FILE* a = py_to_file(py_a,\"a\");\n
    \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_file() converts\nPyObject* to a FILE* and increments the reference count of the PyObject*:\n\n 
    \n    FILE* py_to_file(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"file\", name);\n    \n        Py_INCREF(py_obj);\n        return PyFile_AsFile(py_obj);\n    }\n
    \n\nBecause the PyObject* was incremented, the clean up code needs to decrement\nthe counter\n\n 
    \n    /* cleanup code */\n    Py_XDECREF(py_a);\n
    \n\nIts important to understand that file conversion only works on actual files --\ni.e. ones created using the open() command in Python. It does\nnot support converting arbitrary objects that support the file interface into\nC FILE* pointers. This can affect many things. For example, in\ninitial printf() examples, one might be tempted to solve the \nproblem of C and Python IDE's (PythonWin, PyCrust, etc.) writing to different\nstdout and stderr by using fprintf() and passing in \nsys.stdout and sys.stderr. For example, instead of\n\n 
    \n    >>> weave.inline('printf(\"hello\\\\n\");')\n
    \n \nYou might try:\n\n 
    \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n
    \n\nThis will work as expected from a standard python interpreter, but in PythonWin,\nthe following occurs:\n\n 
    \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n    Traceback (most recent call last):\n        File \"\", line 1, in ?\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 315, in inline\n            auto_downcast = auto_downcast,\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 386, in compile_function\n            type_factories = type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 197, in __init__\n            auto_downcast, type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 390, in assign_variable_types\n            raise TypeError, format_error_msg(errors)\n        TypeError: {'buf': \"Unable to convert variable 'buf' to a C++ type.\"}\n
    \n\nThe traceback tells us that inline() was unable to convert 'buf' to a\nC++ type (If instance conversion was implemented, the error would have occurred at \nruntime instead). Why is this? Let's look at what the buf object \nreally is:\n\n 
    \n    >>> buf\n    pywin.framework.interact.InteractiveView instance at 00EAD014\n
    \n\nPythonWin has reassigned sys.stdout to a special object that \nimplements the Python file interface. This works great in Python, but since \nthe special object doesn't have a FILE* pointer underlying it, fprintf doesn't \nknow what to do with it (well this will be the problem when instance conversion \nis implemented...).\n\n\n

    Callable, Instance, and Module Conversion

    \n\nNote: Need to look into how ref counts should be handled. Also,\nInstance and Module conversion are not currently implemented.\n\n\n 
    \n    >>> def a(): \n        pass\n    >>> inline(\"\",['a'])\n
    \n\nCallable and instance variables are converted to PyObject*. Nothing is done\nto there reference counts.\n\n 
    \n    /* argument conversion code */\n    PyObject* a = py_to_callable(get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
    \n\nget_variable() reads the variable a\nfrom the local and global namespaces. The py_to_callable() and\npy_to_instance() don't currently increment the ref count.\n\n 
        \n    PyObject* py_to_callable(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyCallable_Check(py_obj))\n            handle_bad_type(py_obj,\"callable\", name);    \n        return py_obj;\n    }\n\n    PyObject* py_to_instance(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"instance\", name);    \n        return py_obj;\n    }\n
    \n \nThere is no cleanup code for callables, modules, or instances.\n\n\n

    Customizing Conversions

    \n

    \nConverting from Python to C++ types is handled by xxx_specification classes. A \ntype specification class actually serve in two related but different \nroles. The first is in determining whether a Python variable that needs to be \nconverted should be represented by the given class. The second is as a code \ngenerator that generate C++ code needed to convert from Python to C++ types for \na specific variable.\n

    \nWhen \n\n 

    \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\",a);',['a'])\n
    \n \nis called for the first time, the code snippet has to be compiled. In this \nprocess, the variable 'a' is tested against a list of type specifications (the \ndefault list is stored in weave/ext_tools.py). The first \nspecification in the list is used to represent the variable. \n\n

    \nExamples of xxx_specification are scattered throughout numerous \n\"xxx_spec.py\" files in the weave package. Closely related to \nthe xxx_specification classes are yyy_info classes. \nThese classes contain compiler, header, and support code information necessary \nfor including a certain set of capabilities (such as blitz++ or CXX support)\nin a compiled module. xxx_specification classes have one or more\nyyy_info classes associated with them.\n\nIf you'd like to define your own set of type specifications, the current best route\nis to examine some of the existing spec and info files. Maybe looking over\nsequence_spec.py and cxx_info.py are a good place to start. After defining \nspecification classes, you'll need to pass them into inline using the \ntype_factories argument. \n\nA lot of times you may just want to change how a specific variable type is \nrepresented. Say you'd rather have Python strings converted to \nstd::string or maybe char* instead of using the CXX \nstring object, but would like all other type conversions to have default \nbehavior. This requires that a new specification class that handles strings\nis written and then prepended to a list of the default type specifications. Since\nit is closer to the front of the list, it effectively overrides the default\nstring specification.\n\nThe following code demonstrates how this is done:\n\n...\n\n\n

    The Catalog

    \n

    \ncatalog.py has a class called catalog that helps keep \ntrack of previously compiled functions. This prevents inline() \nand related functions from having to compile functions everytime they are \ncalled. Instead, catalog will check an in memory cache to see if the function \nhas already been loaded into python. If it hasn't, then it starts searching \nthrough persisent catalogs on disk to see if it finds an entry for the given \nfunction. By saving information about compiled functions to disk, it isn't\nnecessary to re-compile functions everytime you stop and restart the interpreter.\nFunctions are compiled once and stored for future use.\n\n

    \nWhen inline(cpp_code) is called the following things happen:\n

      \n
    1. \n A fast local cache of functions is checked for the last function called for \n cpp_code. If an entry for cpp_code doesn't exist in the \n cache or the cached function call fails (perhaps because the function doesn't \n have compatible types) then the next step is to check the catalog. \n
    2. \n The catalog class also keeps an in-memory cache with a list of all the \n functions compiled for cpp_code. If cpp_code has\n ever been called, then this cache will be present (loaded from disk). If\n the cache isn't present, then it is loaded from disk.\n

      \n If the cache is present, each function in the cache is \n called until one is found that was compiled for the correct argument types. If \n none of the functions work, a new function is compiled with the given argument \n types. This function is written to the on-disk catalog as well as into the \n in-memory cache.

      \n
    3. \n When a lookup for cpp_code fails, the catalog looks through \n the on-disk function catalogs for the entries. The PYTHONCOMPILED variable \n determines where to search for these catalogs and in what order. If \n PYTHONCOMPILED is not present several platform dependent locations are \n searched. All functions found for cpp_code in the path are \n loaded into the in-memory cache with functions found earlier in the search \n path closer to the front of the call list.\n

      \n If the function isn't found in the on-disk catalog, \n then the function is compiled, written to the first writable directory in the \n PYTHONCOMPILED path, and also loaded into the in-memory cache.

      \n
      4. \n
    \n\n\n

    Function Storage: How functions are stored in caches and on disk

    \n

    \nFunction caches are stored as dictionaries where the key is the entire C++\ncode string and the value is either a single function (as in the \"level 1\"\ncache) or a list of functions (as in the main catalog cache). On disk\ncatalogs are stored in the same manor using standard Python shelves.\n

    \nEarly on, there was a question as to whether md5 check sums of the C++\ncode strings should be used instead of the actual code strings. I think this\nis the route inline Perl took. Some (admittedly quick) tests of the md5 vs.\nthe entire string showed that using the entire string was at least a\nfactor of 3 or 4 faster for Python. I think this is because it is more\ntime consuming to compute the md5 value than it is to do look-ups of long\nstrings in the dictionary. Look at the examples/md5_speed.py file for the\ntest run. \n\n\n

    Catalog search paths and the PYTHONCOMPILED variable

    \n

    \nThe default location for catalog files on Unix is is ~/.pythonXX_compiled where \nXX is version of Python being used. If this directory doesn't exist, it is \ncreated the first time a catalog is used. The directory must be writable. If, \nfor any reason it isn't, then the catalog attempts to create a directory based \non your user id in the /tmp directory. The directory permissions are set so \nthat only you have access to the directory. If this fails, I think you're out of \nluck. I don't think either of these should ever fail though. On Windows, a \ndirectory called pythonXX_compiled is created in the user's temporary \ndirectory. \n

    \nThe actual catalog file that lives in this directory is a Python shelve with\na platform specific name such as \"nt21compiled_catalog\" so that multiple OSes\ncan share the same file systems without trampling on each other. Along with\nthe catalog file, the .cpp and .so or .pyd files created by inline will live\nin this directory. The catalog file simply contains keys which are the C++\ncode strings with values that are lists of functions. The function lists point\nat functions within these compiled modules. Each function in the lists \nexecutes the same C++ code string, but compiled for different input variables.\n

    \nYou can use the PYTHONCOMPILED environment variable to specify alternative\nlocations for compiled functions. On Unix this is a colon (':') separated\nlist of directories. On windows, it is a (';') separated list of directories.\nThese directories will be searched prior to the default directory for a\ncompiled function catalog. Also, the first writable directory in the list\nis where all new compiled function catalogs, .cpp and .so or .pyd files are\nwritten. Relative directory paths ('.' and '..') should work fine in the\nPYTHONCOMPILED variable as should environement variables.\n

    \nThere is a \"special\" path variable called MODULE that can be placed in the \nPYTHONCOMPILED variable. It specifies that the compiled catalog should\nreside in the same directory as the module that called it. This is useful\nif an admin wants to build a lot of compiled functions during the build\nof a package and then install them in site-packages along with the package.\nUser's who specify MODULE in their PYTHONCOMPILED variable will have access\nto these compiled functions. Note, however, that if they call the function\nwith a set of argument types that it hasn't previously been built for, the\nnew function will be stored in their default directory (or some other writable\ndirectory in the PYTHONCOMPILED path) because the user will not have write\naccess to the site-packages directory.\n

    \nAn example of using the PYTHONCOMPILED path on bash follows:\n\n 

    \n    PYTHONCOMPILED=MODULE:/some/path;export PYTHONCOMPILED;\n
    \n\nIf you are using python21 on linux, and the module bob.py in site-packages\nhas a compiled function in it, then the catalog search order when calling that\nfunction for the first time in a python session would be:\n\n 
    \n    /usr/lib/python21/site-packages/linuxpython_compiled\n    /some/path/linuxpython_compiled\n    ~/.python21_compiled/linuxpython_compiled\n
    \n\nThe default location is always included in the search path.\n

    \n \nNote: hmmm. see a possible problem here. I should probably make a sub-\ndirectory such as /usr/lib/python21/site-\npackages/python21_compiled/linuxpython_compiled so that library files compiled \nwith python21 are tried to link with python22 files in some strange scenarios. \nNeed to check this.\n\n\n

    \nThe in-module cache (in weave.inline_tools reduces the overhead \nof calling inline functions by about a factor of 2. It can be reduced a little \nmore for type loop calls where the same function is called over and over again \nif the cache was a single value instead of a dictionary, but the benefit is \nvery small (less than 5%) and the utility is quite a bit less. So, we'll stick \nwith a dictionary as the cache.\n

    \n\n\n

    Blitz

    \n Note: most of this section is lifted from old documentation. It should be\npretty accurate, but there may be a few discrepancies.\n

    \nweave.blitz() compiles Numeric Python expressions for fast \nexecution. For most applications, compiled expressions should provide a \nfactor of 2-10 speed-up over Numeric arrays. Using compiled \nexpressions is meant to be as unobtrusive as possible and works much like \npythons exec statement. As an example, the following code fragment takes a 5 \npoint average of the 512x512 2d image, b, and stores it in array, a:\n\n 

    \n    from scipy import *  # or from Numeric import *\n    a = ones((512,512), Float64) \n    b = ones((512,512), Float64) \n    # ...do some stuff to fill in b...\n    # now average\n    a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] \\\n                   + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n
    \n \nTo compile the expression, convert the expression to a string by putting\nquotes around it and then use weave.blitz:\n\n 
    \n    import weave\n    expr = \"a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n                          \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n    weave.blitz(expr)\n
    \n\nThe first time weave.blitz is run for a given expression and \nset of arguements, C++ code that accomplishes the exact same task as the Python \nexpression is generated and compiled to an extension module. This can take up \nto a couple of minutes depending on the complexity of the function. Subsequent \ncalls to the function are very fast. Futher, the generated module is saved \nbetween program executions so that the compilation is only done once for a \ngiven expression and associated set of array types. If the given expression\nis executed with a new set of array types, the code most be compiled again. This\ndoes not overwrite the previously compiled function -- both of them are saved and\navailable for exectution. \n

    \nThe following table compares the run times for standard Numeric code and \ncompiled code for the 5 point averaging.\n

    \n

    \n\n\n\n\n\n
    Method Run Time (seconds)
    Standard Numeric 0.46349
    blitz (1st time compiling) 78.95526
    blitz (subsequent calls) 0.05843 (factor of 8 speedup)
    \n
    \n

    \nThese numbers are for a 512x512 double precision image run on a 400 MHz Celeron \nprocessor under RedHat Linux 6.2.\n

    \nBecause of the slow compile times, its probably most effective to develop \nalgorithms as you usually do using the capabilities of scipy or the Numeric \nmodule. Once the algorithm is perfected, put quotes around it and execute it \nusing weave.blitz. This provides the standard rapid \nprototyping strengths of Python and results in algorithms that run close to \nthat of hand coded C or Fortran.\n\n\n

    Requirements

    \n\nCurrently, the weave.blitz has only been tested under Linux \nwith gcc-2.95-3 and on Windows with Mingw32 (2.95.2). Its compiler \nrequirements are pretty heavy duty (see the \nblitz++ home page), so it won't \nwork with just any compiler. Particularly MSVC++ isn't up to snuff. A number \nof other compilers such as KAI++ will also work, but my suspicions are that gcc \nwill get the most use.\n\n\n

    Limitations

    \n
      \n
    1. \nCurrently, weave.blitz handles all standard mathematic \noperators except for the ** power operator. The built-in trigonmetric, log, \nfloor/ceil, and fabs functions might work (but haven't been tested). It also \nhandles all types of array indexing supported by the Numeric module. \n

      \nweave.blitz does not currently support operations that use \narray broadcasting, nor have any of the special purpose functions in Numeric \nsuch as take, compress, etc. been implemented. Note that there are no obvious \nreasons why most of this functionality cannot be added to scipy.weave, so it \nwill likely trickle into future versions. Using slice() objects \ndirectly instead of start:stop:step is also not supported.\n

      2. \n
    2. \nCurrently Python only works on expressions that include assignment such as\n \n 
      \n    >>> result = b + c + d\n
      \n\nThis means that the result array must exist before calling \nweave.blitz. Future versions will allow the following:\n\n 
      \n    >>> result = weave.blitz_eval(\"b + c + d\")\n
      \n
      3. \n
    3. \nweave.blitz works best when algorithms can be expressed in a \n\"vectorized\" form. Algorithms that have a large number of if/thens and other \nconditions are better hand written in C or Fortran. Further, the restrictions \nimposed by requiring vectorized expressions sometimes preclude the use of more \nefficient data structures or algorithms. For maximum speed in these cases, \nhand-coded C or Fortran code is the only way to go.\n
      4. \n
    4. \nOne other point deserves mention lest people be confused. \nweave.blitz is not a general purpose Python->C compiler. It \nonly works for expressions that contain Numeric arrays and/or \nPython scalar values. This focused scope concentrates effort on the \ncompuationally intensive regions of the program and sidesteps the difficult \nissues associated with a general purpose Python->C compiler.\n
      5. \n
    \n\n\n

    Numeric efficiency issues: What compilation buys you

    \n\nSome might wonder why compiling Numeric expressions to C++ is beneficial since \noperations on Numeric array operations are already executed within C loops. \nThe problem is that anything other than the simplest expression are executed in \nless than optimal fashion. Consider the following Numeric expression:\n\n 
    \n    a = 1.2 * b + c * d\n
    \n \nWhen Numeric calculates the value for the 2d array, a, it does \nthe following steps:\n\n 
    \n    temp1 = 1.2 * b\n    temp2 = c * d\n    a = temp1 + temp2\n
    \n \nTwo things to note. Since c is an (perhaps large) array, a large \ntemporary array must be created to store the results of 1.2 * b. \nThe same is true for temp2. Allocation is slow. The second thing \nis that we have 3 loops executing, one to calculate temp1, one for \ntemp2 and one for adding them up. A C loop for the same problem \nmight look like:\n\n 
    \n    for(int i = 0; i < M; i++)\n        for(int j = 0; j < N; j++)\n            a[i,j] = 1.2 * b[i,j] + c[i,j] * d[i,j]\n
    \n \nHere, the 3 loops have been fused into a single loop and there is no longer\na need for a temporary array. This provides a significant speed improvement\nover the above example (write me and tell me what you get). \n

    \nSo, converting Numeric expressions into C/C++ loops that fuse the loops and \neliminate temporary arrays can provide big gains. The goal then,is to convert \nNumeric expression to C/C++ loops, compile them in an extension module, and \nthen call the compiled extension function. The good news is that there is an \nobvious correspondence between the Numeric expression above and the C loop. The \nbad news is that Numeric is generally much more powerful than this simple \nexample illustrates and handling all possible indexing possibilities results in \nloops that are less than straight forward to write. (take a peak in Numeric for \nconfirmation). Luckily, there are several available tools that simplify the \nprocess.\n\n\n

    The Tools

    \n\nweave.blitz relies heavily on several remarkable tools. On the \nPython side, the main facilitators are Jermey Hylton's parser module and Jim \nHuginin's Numeric module. On the compiled language side, Todd Veldhuizen's \nblitz++ array library, written in C++ (shhhh. don't tell David Beazley), does \nthe heavy lifting. Don't assume that, because it's C++, it's much slower than C \nor Fortran. Blitz++ uses a jaw dropping array of template techniques \n(metaprogramming, template expression, etc) to convert innocent looking and \nreadable C++ expressions into to code that usually executes within a few \npercentage points of Fortran code for the same problem. This is good. \nUnfortunately all the template raz-ma-taz is very expensive to compile, so the \n200 line extension modules often take 2 or more minutes to compile. This isn't so \ngood. weave.blitz works to minimize this issue by remembering \nwhere compiled modules live and reusing them instead of re-compiling every time \na program is re-run.\n\n\n

    Parser

    \nTearing Numeric expressions apart, examining the pieces, and then rebuilding \nthem as C++ (blitz) expressions requires a parser of some sort. I can imagine \nsomeone attacking this problem with regular expressions, but it'd likely be \nugly and fragile. Amazingly, Python solves this problem for us. It actually \nexposes its parsing engine to the world through the parser module. \nThe following fragment creates an Abstract Syntax Tree (AST) object for the \nexpression and then converts to a (rather unpleasant looking) deeply nested list \nrepresentation of the tree. \n \n 
    \n    >>> import parser\n    >>> import scipy.weave.misc\n    >>> ast = parser.suite(\"a = b * c + d\")\n    >>> ast_list = ast.tolist()\n    >>> sym_list = scipy.weave.misc.translate_symbols(ast_list)\n    >>> pprint.pprint(sym_list)\n    ['file_input',\n     ['stmt',\n      ['simple_stmt',\n       ['small_stmt',\n        ['expr_stmt',\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'a']]]]]]]]]]]]]]],\n         ['EQUAL', '='],\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'b']]]],\n                    ['STAR', '*'],\n                    ['factor', ['power', ['atom', ['NAME', 'c']]]]],\n                   ['PLUS', '+'],\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'd']]]]]]]]]]]]]]]]],\n       ['NEWLINE', '']]],\n     ['ENDMARKER', '']]\n
    \n\nDespite its looks, with some tools developed by Jermey H., its possible\nto search these trees for specific patterns (sub-trees), extract the \nsub-tree, manipulate them converting python specific code fragments\nto blitz code fragments, and then re-insert it in the parse tree. The parser\nmodule documentation has some details on how to do this. Traversing the \nnew blitzified tree, writing out the terminal symbols as you go, creates\nour new blitz++ expression string.\n\n \n

    Blitz and Numeric

    \nThe other nice discovery in the project is that the data structure used\nfor Numeric arrays and blitz arrays is nearly identical. Numeric stores\n\"strides\" as byte offsets and blitz stores them as element offsets, but\nother than that, they are the same. Further, most of the concept and\ncapabilities of the two libraries are remarkably similar. It is satisfying \nthat two completely different implementations solved the problem with \nsimilar basic architectures. It is also fortitous. The work involved in \nconverting Numeric expressions to blitz expressions was greatly diminished.\nAs an example, consider the code for slicing an array in Python with a\nstride:\n\n 
    \n    >>> a = b[0:4:2] + c\n    >>> a\n    [0,2,4]\n
    \n\n\nIn Blitz it is as follows:\n\n 
    \n    Array<2,int> b(10);\n    Array<2,int> c(3);\n    // ...\n    Array<2,int> a = b(Range(0,3,2)) + c;\n
    \n\n\nHere the range object works exactly like Python slice objects with the exception\nthat the top index (3) is inclusive where as Python's (4) is exclusive. Other \ndifferences include the type declaraions in C++ and parentheses instead of \nbrackets for indexing arrays. Currently, weave.blitz handles the \ninclusive/exclusive issue by subtracting one from upper indices during the\ntranslation. An alternative that is likely more robust/maintainable in the \nlong run, is to write a PyRange class that behaves like Python's range. \nThis is likely very easy.\n

    \nThe stock blitz also doesn't handle negative indices in ranges. The current \nimplementation of the blitz() has a partial solution to this \nproblem. It calculates and index that starts with a '-' sign by subtracting it \nfrom the maximum index in the array so that:\n\n 

    \n                    upper index limit\n                        /-----\\\n    b[:-1] -> b(Range(0,Nb[0]-1-1))\n
    \n\nThis approach fails, however, when the top index is calculated from other \nvalues. In the following scenario, if i+j evaluates to a negative \nvalue, the compiled code will produce incorrect results and could even core-\ndump. Right now, all calculated indices are assumed to be positive.\n \n 
    \n    b[:i-j] -> b(Range(0,i+j))\n
    \n\nA solution is to calculate all indices up front using if/then to handle the\n+/- cases. This is a little work and results in more code, so it hasn't been\ndone. I'm holding out to see if blitz++ can be modified to handle negative\nindexing, but haven't looked into how much effort is involved yet. While it \nneeds fixin', I don't think there is a ton of code where this is an issue.\n

    \nThe actual translation of the Python expressions to blitz expressions is \ncurrently a two part process. First, all x:y:z slicing expression are removed\nfrom the AST, converted to slice(x,y,z) and re-inserted into the tree. Any\nmath needed on these expressions (subtracting from the \nmaximum index, etc.) are also preformed here. _beg and _end are used as special\nvariables that are defined as blitz::fromBegin and blitz::toEnd.\n\n 

    \n    a[i+j:i+j+1,:] = b[2:3,:] \n
    \n\nbecomes a more verbose:\n \n 
    \n    a[slice(i+j,i+j+1),slice(_beg,_end)] = b[slice(2,3),slice(_beg,_end)]\n
    \n \nThe second part does a simple string search/replace to convert to a blitz \nexpression with the following translations:\n\n 
    \n    slice(_beg,_end) -> _all  # not strictly needed, but cuts down on code.\n    slice            -> blitz::Range\n    [                -> (\n    ]                -> )\n    _stp             -> 1\n
    \n\n_all is defined in the compiled function as \nblitz::Range.all(). These translations could of course happen \ndirectly in the syntax tree. But the string replacement is slightly easier. \nNote that name spaces are maintained in the C++ code to lessen the likelyhood \nof name clashes. Currently no effort is made to detect name clashes. A good \nrule of thumb is don't use values that start with '_' or 'py_' in compiled \nexpressions and you'll be fine.\n\n \n

    Type definitions and coersion

    \n\nSo far we've glossed over the dynamic vs. static typing issue between Python \nand C++. In Python, the type of value that a variable holds can change\nthrough the course of program execution. C/C++, on the other hand, forces you\nto declare the type of value a variables will hold prior at compile time.\nweave.blitz handles this issue by examining the types of the\nvariables in the expression being executed, and compiling a function for those\nexplicit types. For example:\n\n 
    \n    a = ones((5,5),Float32)\n    b = ones((5,5),Float32)\n    weave.blitz(\"a = a + b\")\n
    \n\nWhen compiling this expression to C++, weave.blitz sees that the\nvalues for a and b in the local scope have type Float32, or 'float'\non a 32 bit architecture. As a result, it compiles the function using \nthe float type (no attempt has been made to deal with 64 bit issues).\nIt also goes one step further. If all arrays have the same type, a templated\nversion of the function is made and instantiated for float, double, \ncomplex, and complex arrays. Note: This feature has been \nremoved from the current version of the code. Each version will be compiled\nseparately \n

    \nWhat happens if you call a compiled function with array types that are \ndifferent than the ones for which it was originally compiled? No biggie, you'll \njust have to wait on it to compile a new version for your new types. This \ndoesn't overwrite the old functions, as they are still accessible. See the \ncatalog section in the inline() documentation to see how this is handled. \nSuffice to say, the mechanism is transparent to the user and behaves \nlike dynamic typing with the occasional wait for compiling newly typed \nfunctions.\n

    \nWhen working with combined scalar/array operations, the type of the array is \nalways used. This is similar to the savespace flag that was recently \nadded to Numeric. This prevents issues with the following expression perhaps \nunexpectedly being calculated at a higher (more expensive) precision that can \noccur in Python:\n\n 

    \n    >>> a = array((1,2,3),typecode = Float32)\n    >>> b = a * 2.1 # results in b being a Float64 array.\n
    \n \nIn this example, \n\n 
    \n    >>> a = ones((5,5),Float32)\n    >>> b = ones((5,5),Float32)\n    >>> weave.blitz(\"b = a * 2.1\")\n
    \n \nthe 2.1 is cast down to a float before carrying out \nthe operation. If you really want to force the calculation to be a \ndouble, define a and b as \ndouble arrays.\n

    \nOne other point of note. Currently, you must include both the right hand side \nand left hand side (assignment side) of your equation in the compiled \nexpression. Also, the array being assigned to must be created prior to calling \nweave.blitz. I'm pretty sure this is easily changed so that a \ncompiled_eval expression can be defined, but no effort has been made to \nallocate new arrays (and decern their type) on the fly.\n\n \n

    Cataloging Compiled Functions

    \n\nSee the Cataloging functions section in the \nweave.inline() documentation.\n\n \n

    Checking Array Sizes

    \n\nSurprisingly, one of the big initial problems with compiled code was making\nsure all the arrays in an operation were of compatible type. The following\ncase, is of course, trivially easy:\n\n 
    \n    a = b + c\n
    \n \nIt only requires that arrays a, b, and c \nhave the same shape. However, expressions like:\n\n 
    \n    a[i+j:i+j+1,:] = b[2:3,:] + c\n
    \n\nare not so trivial. Since slicing is involved, the size of the slices, not the \ninput arrays must be checked. Broadcasting complicates things further because \narrays and slices with different dimensions and shapes may be compatible for \nmath operations (broadcasting isn't yet supported by \nweave.blitz). Reductions have a similar effect as their \nresults are different shapes than their input operand. The binary operators in \nNumeric compare the shapes of their two operands just before they operate on \nthem. This is possible because Numeric treats each operation independently. \nThe intermediate (temporary) arrays created during sub-operations in an \nexpression are tested for the correct shape before they are combined by another \noperation. Because weave.blitz fuses all operations into a \nsingle loop, this isn't possible. The shape comparisons must be done and \nguaranteed compatible before evaluating the expression.\n

    \nThe solution chosen converts input arrays to \"dummy arrays\" that only represent \nthe dimensions of the arrays, not the data. Binary operations on dummy arrays \ncheck that input array sizes are comptible and return a dummy array with the \nsize correct size. Evaluating an expression of dummy arrays traces the \nchanging array sizes through all operations and fails if incompatible array \nsizes are ever found. \n

    \nThe machinery for this is housed in weave.size_check. It \nbasically involves writing a new class (dummy array) and overloading it math \noperators to calculate the new sizes correctly. All the code is in Python and \nthere is a fair amount of logic (mainly to handle indexing and slicing) so the \noperation does impose some overhead. For large arrays (ie. 50x50x50), the \noverhead is negligible compared to evaluating the actual expression. For small \narrays (ie. 16x16), the overhead imposed for checking the shapes with this \nmethod can cause the weave.blitz to be slower than evaluating \nthe expression in Python. \n

    \nWhat can be done to reduce the overhead? (1) The size checking code could be \nmoved into C. This would likely remove most of the overhead penalty compared \nto Numeric (although there is also some calling overhead), but no effort has \nbeen made to do this. (2) You can also call weave.blitz with\ncheck_size=0 and the size checking isn't done. However, if the \nsizes aren't compatible, it can cause a core-dump. So, foregoing size_checking\nisn't advisable until your code is well debugged.\n\n \n

    Creating the Extension Module

    \n\nweave.blitz uses the same machinery as \nweave.inline to build the extension module. The only difference\nis the code included in the function is automatically generated from the\nNumeric array expression instead of supplied by the user.\n\n\n

    Extension Modules

    \nweave.inline and weave.blitz are high level tools\nthat generate extension modules automatically. Under the covers, they use several\nclasses from weave.ext_tools to help generate the extension module.\nThe main two classes are ext_module and ext_function (I'd\nlike to add ext_class and ext_method also). These classes\nsimplify the process of generating extension modules by handling most of the \"boiler\nplate\" code automatically.\n\n\nNote: inline actually sub-classes weave.ext_tools.ext_function \nto generate slightly different code than the standard ext_function.\nThe main difference is that the standard class converts function arguments to\nC types, while inline always has two arguments, the local and global dicts, and\nthe grabs the variables that need to be convereted to C from these.\n\n\n\n

    A Simple Example

    \nThe following simple example demonstrates how to build an extension module within\na Python function:\n\n 
    \n    # examples/increment_example.py\n    from weave import ext_tools\n    \n    def build_increment_ext():\n        \"\"\" Build a simple extension with functions that increment numbers.\n            The extension will be built in the local directory.\n        \"\"\"        \n        mod = ext_tools.ext_module('increment_ext')\n    \n        a = 1 # effectively a type declaration for 'a' in the \n              # following functions.\n    \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n        mod.add_function(func)\n        \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+2));\"    \n        func = ext_tools.ext_function('increment_by_2',ext_code,['a'])\n        mod.add_function(func)\n                \n        mod.compile()\n
    \n\n\nThe function build_increment_ext() creates an extension module \nnamed increment_ext and compiles it to a shared library (.so or \n.pyd) that can be loaded into Python.. increment_ext contains two \nfunctions, increment and increment_by_2. \n\nThe first line of build_increment_ext(),\n\n 
    \n        mod = ext_tools.ext_module('increment_ext') \n
    \n\ncreates an ext_module instance that is ready to have \next_function instances added to it. ext_function \ninstances are created much with a calling convention similar to \nweave.inline(). The most common call includes a C/C++ code \nsnippet and a list of the arguments for the function. The following\n\n 
    \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n
    \n \ncreates a C/C++ extension function that is equivalent to the following Python\nfunction:\n\n 
    \n        def increment(a):\n            return a + 1\n
    \n\nA second method is also added to the module and then,\n\n 
    \n        mod.compile()\n
    \n\nis called to build the extension module. By default, the module is created\nin the current working directory.\n\nThis example is available in the examples/increment_example.py file\nfound in the weave directory. At the bottom of the file in the\nmodule's \"main\" program, an attempt to import increment_ext without\nbuilding it is made. If this fails (the module doesn't exist in the PYTHONPATH), \nthe module is built by calling build_increment_ext(). This approach\nonly takes the time consuming ( a few seconds for this example) process of building\nthe module if it hasn't been built before.\n\n 
    \n    if __name__ == \"__main__\":\n        try:\n            import increment_ext\n        except ImportError:\n            build_increment_ext()\n            import increment_ext\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
    \n\n\nNote: If we were willing to always pay the penalty of building the C++ code for \na module, we could store the md5 checksum of the C++ code along with some \ninformation about the compiler, platform, etc. Then, \next_module.compile() could try importing the module before it actually\ncompiles it, check the md5 checksum and other meta-data in the imported module\nwith the meta-data of the code it just produced and only compile the code if\nthe module didn't exist or the meta-data didn't match. This would reduce the\nabove code to:\n\n 
    \n    if __name__ == \"__main__\":\n        build_increment_ext()\n\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
    \n\nNote: There would always be the overhead of building the C++ code, but it would only actually compile the code once. You pay a little in overhead and get cleaner\n\"import\" code. Needs some thought.\n\n

    \n\nIf you run increment_example.py from the command line, you get\nthe following:\n\n 

    \n    [eric@n0]$ python increment_example.py\n    a, a+1: 1 2\n    a, a+2: 1 3\n
    \n\nIf the module didn't exist before it was run, the module is created. If it did\nexist, it is just imported and used.\n\n\n

    Fibonacci Example

    \nexamples/fibonacci.py provides a little more complex example of \nhow to use ext_tools. Fibonacci numbers are a series of numbers \nwhere each number in the series is the sum of the previous two: 1, 1, 2, 3, 5, \n8, etc. Here, the first two numbers in the series are taken to be 1. One \napproach to calculating Fibonacci numbers uses recursive function calls. In \nPython, it might be written as:\n\n 
    \n    def fib(a):\n        if a <= 2:\n            return 1\n        else:\n            return fib(a-2) + fib(a-1)\n
    \n\nIn C, the same function would look something like this:\n\n 
    \n     int fib(int a)\n     {                   \n         if(a <= 2)\n             return 1;\n         else\n             return fib(a-2) + fib(a-1);  \n     }                      \n
    \n\nRecursion is much faster in C than in Python, so it would be beneficial\nto use the C version for fibonacci number calculations instead of the\nPython version. We need an extension function that calls this C function\nto do this. This is possible by including the above code snippet as \n\"support code\" and then calling it from the extension function. Support \ncode snippets (usually structure definitions, helper functions and the like)\nare inserted into the extension module C/C++ file before the extension\nfunction code. Here is how to build the C version of the fibonacci number\ngenerator:\n\n 
    \ndef build_fibonacci():\n    \"\"\" Builds an extension module with fibonacci calculators.\n    \"\"\"\n    mod = ext_tools.ext_module('fibonacci_ext')\n    a = 1 # this is effectively a type declaration\n    \n    # recursive fibonacci in C \n    fib_code = \"\"\"\n                   int fib1(int a)\n                   {                   \n                       if(a <= 2)\n                           return 1;\n                       else\n                           return fib1(a-2) + fib1(a-1);  \n                   }                         \n               \"\"\"\n    ext_code = \"\"\"\n                   int val = fib1(a);\n                   return_val = Py::new_reference_to(Py::Int(val));\n               \"\"\"    \n    fib = ext_tools.ext_function('fib',ext_code,['a'])\n    fib.customize.add_support_code(fib_code)\n    mod.add_function(fib)\n\n    mod.compile()\n\n
    \n\nXXX More about custom_info, and what xxx_info instances are good for.\n\n

    \n\nNote: recursion is not the fastest way to calculate fibonacci numbers, but this \napproach serves nicely for this example.\n\n

    \n\n

    Customizing Type Conversions -- Type Factories

    \nnot written\n\n

    Things I wish weave did

    \n\nIt is possible to get name clashes if you uses a variable name that is already defined\nin a header automatically included (such as stdio.h) For instance, if you\ntry to pass in a variable named stdout, you'll get a cryptic error report\ndue to the fact that stdio.h also defines the name. weave\nshould probably try and handle this in some way.\n\nOther things...", "source_code_before": "\n

    Weave Documentation

    \n

    \nBy Eric Jones eric@enthought.com\n

    \n

    Outline

    \n
    \n
    Introduction\n
    Requirements\n
    Installation and Testing\n
    Inline\n
    \n
    More with printf\n
    \n More examples\n
    \n
    Binary search\n
    Dictionary sort\n
    Numeric -- cast/copy/transpose\n
    wxPython
    \n
    \n
    Keyword options\n
    Returning values\n
    \n
    \n The issue with locals()
    \n
    \n
    A quick look at the code\n
    \n Technical Details\n
    \n
    Converting Types\n
    \n
    \n Numeric Argument Conversion\n
    \n String, List, Tuple, and Dictionary Conversion\n
    File Conversion \n
    \n Callable, Instance, and Module Conversion \n
    Customizing Conversions\n
    \n
    Compiling Code\n
    \"Cataloging\" functions\n
    \n
    Function Storage\n
    The PYTHONCOMPILED evnironment variable
    \n
    \n
    \n
    \n
    \n
    \n
    Blitz\n
    \n
    Requirements\n
    Limitations\n
    Numeric Efficiency Issues\n
    The Tools \n
    \n
    Parser\n
    Blitz and Numeric\n
    \n
    Type defintions and coersion\n
    Cataloging Compiled Functions\n
    Checking Array Sizes\n
    Creating the Extension Module\n
    \n
    Extension Modules\n
    \n
    A Simple Example\n
    Fibonacci Example\n
    \n
    Customizing Type Conversions -- Type Factories (not written)\n
    \n
    Type Specifications\n
    Type Information\n
    The Conversion Process \n
    \n
    \n\n

    Introduction

    \n\n

    \nThe weave package allows the inclusion of C/C++ within \nPython code. This offers both another level of optimization to those who need \nit, and an easy way to modify and extend any supported extension libraries such \nas wxPython and hopefully VTK soon. Inlining C/C++ code within Python generally\nresults in speed ups of 1.5x to 30x speed-up over algorithms written in pure\nPython (However, it is also possible to slow things down...). Generally \nalgorithms that require a large number of calls to the Python API don't benefit\nas much from the conversion to C/C++ as algorithms that have inner loops \ncompletely convertable to C.\n

    \nThere are three basic ways to use weave. The \nweave.inline() function executes C code directly within Python, \nand weave.blitz() translates Python Numeric expressions to C++ \nfor fast execution. This was the original functionality for which \nweave was built. For those interested in building extension\nlibraries, the ext_tools module provides classes for building \nextension modules within Python. \n

    \nMost of weave's functionality should work on Windows and Unix, \nalthough some of its functionality requires gcc or a similarly \nmodern C++ compiler that handles templates well. Up to now, most testing has \nbeen done on Windows 2000 with Microsoft's C++ compiler (MSVC) and with gcc \n(mingw32 2.95.2 and 2.95.3-6). All tests also seem to pass on Linux (RH 7.1 \nwith gcc 2.96).\n

    \nThe inline and blitz provide new functionality to \nPython (although I've recently learned about the PyInline project which may offer \nsimilar functionality to inline). On the other hand, tools for \nbuilding Python extension modules already exists (SWIG, SIP, pycpp, CXX, and \nothers). As of yet, I'm not sure where weave fits in this \nspectrum. It is closest in flavor to CXX in that it makes creating new C/C++ \nextension modules pretty easy. However, If you're wrapping a gaggle of legacy \nfunctions or classes, SWIG and friends are definitely the better choice. \nweave is set up so that you can customize how Python types are \nconverted to C types in weave. This is great for \ninline(), but, for wrapping legacy code, it is generally better to \nspecify things the other way around -- that is how C types map to \nPython types. This weave does not do. I guess it would be \npossible to build such a tool on top of weave, but with good \ntools like SWIG around, I'm not sure the effort produces any new capabilities. \nThings like function overloading are probably easily implemented in \nweave and it might be easier to mix Python/C code in function \ncalls, but nothing beyond this comes to mind. So, if you're developing new \nextension modules, or just want to optimize a few functions in C, \nweave might be the tool for you. If you're wrapping legacy code, \nstick with SWIG.\n

    \nThe next several sections give the basics of how to use weave.\nWe'll discuss what's happening under the covers in more detail later \non. Serious users will need to at least look at the type conversion section to \nunderstand how Python variables map to C/C++ types and how to customize this \nbehavior. One other note. If you don't know C or C++ then these docs are \nprobably of very little help to you. Further, it'd be helpful if you know \nsomething about writing Python extensions. weave does quite a \nbit for you, but for anything complex, you'll need to do some conversions, \nreference counting, etc.\n

    \n\nNote: weave is actually part of the SciPy package. However, it works fine as a \nstandalone package. The examples here are given as if it is used as a stand \nalone package. If you are using from within scipy, you can use from \nscipy import weave and the examples will work identically.\n\n\n

    Requirements

    \n
      \n
    • Python\n

      \n I use 2.1.1. Probably 2.0 or higher should work.\n

      \n

      • \n \n
    • C++ compiler\n

      \n weave uses distutils to actually build \n extension modules, so it uses whatever compiler was originally used to \n build Python. weave itself requires a C++ compiler. If \n you used a C++ compiler to build Python, your probably fine.\n

      \n On Unix gcc is the preferred choice, because I've done a little \n testing with it. All testing has been done with gcc, but I expect the \n majority of compilers should work for inline and \n ext_tools. The one issue I'm not sure about is that I've \n hard coded things so that compilations are linked with the \n stdc++ library. Is this standard across \n Unix compilers, or is this a gcc-ism?\n

      \n For blitz(), you'll need a reasonably recent version of \n gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n versions are likely to work. Its likely that KAI's C++ compiler and \n maybe some others will work, but I haven't tried. My advise is to use \n gcc for now unless your willing to tinker with the code some.\n

      \n On Windows, either MSVC or gcc (www.mingw.org\" > mingw32) should work. Again, \n you'll need gcc for blitz() as the\n MSVC compiler doesn't handle templates well.\n

      \n I have not tried Cygwin, so please report success if it works for you.\n

      \n

      • \n\n
    • Numeric (optional)\n

      \n The python Numeric module from here. is required for \n blitz() to work. Be sure and get NumPy, not NumArray\n which is the \"next generation\" implementation.\n

      \n

      • \n
    • scipy_distutils and scipy_test (packaged with weave)\n

      \n These two modules are packaged with weave in both\n the windows installer and the source distributions. If you are using\n CVS, however, you'll need to download these separately (also available\n through CVS at SciPy).\n

      \n

      • \n
    \n

    \n\n\n

    Installation and Testing

    \n

    \nThere are currently two ways to get weave. Fist, \nweave is part of SciPy and installed automatically (as a sub-\npackage) whenever SciPy is installed (although the latest version isn't in \nSciPy yet, so use this one for now). Second, since weave is \nuseful outside of the scientific community, it has been setup so that it can be\nused as a stand-alone module. \n\n

    \nThe stand-alone version can be downloaded from here. Unix users should grab the \ntar ball (.tgz file) and install it using the following commands.\n\n 

    \n    tar -xzvf weave-0.2.tar.gz\n    cd weave-0.2\n    python setup.py install\n
    \n\nThis will also install two other packages, scipy_distutils and \nscipy_test. The first is needed by the setup process itself and \nboth are used in the unit-testing process. For Windows users, it's even easier. \nThey can download the click-install .exe file and run it for automatic \ninstallation. Numeric is required if you want to use blitz(), but\nisn't necessary for inline() or ext_tools\n

    \nIf you're using the CVS version, you'll need to install scipy_distutils and \nscipy_test modules (also available from CVS) on your own.\n

    \n Note: The dependency issue here is a little sticky. I hate to make people \ndownload more than one file (and so I haven't), but distutils doesn't have a \nway to do conditional installation -- at least that I know about. This can \nlead to undesired clobbering of modules. What to do, what to do...\n

    \nOnce weave is installed, fire up python and run its unit tests.\n\n 

    \n    >>> import weave\n    >>> weave.test()\n    runs long time... spews tons of output\n
    \n\nThis takes a loooong time. On windows, it is usually several minutes. On Unix \nwith remote file systems, I've had it take 15 or so minutes. In the end, it \nshould run about 150 tests and spew some speed results along the way. If you \nget errors, please let me know.\n\nIf you don't have Numeric installed, you'll get some module import errors \nduring the test setup phase for modules that are Numeric specific (blitz_spec, \nblitz_tools, size_check, standard_array_spec, ast_tools), but all test should\npass (about 60 and the run time should be quite a bit less).\n

    \nIf you only want to test a single module of the package, you can do this by\nrunning test() for that specific module.\n\n 

    \n    >>> import weave.scalar_spec\n    >>> weave.scalar_spec.test()\n    .......\n    ----------------------------------------------------------------------\n    Ran 7 tests in 23.284s\n
    \n\nNote: I've had some test fail on windows machines where I have msvc, gcc-2.95.2 \n(in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My environment \nhas c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the path. The test \nprocess runs very smoothly until the end where several test using gcc fail with \ncpp0 not found by g++. If I check os.system('gcc -v') before running tests, I \nget gcc-2.95.3-6. If I check after running tests (and after failure), I get \ngcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\\gcc first in it and \nis not corrupted (msvc/distutils messes with the environment variables, so we \nhave to undo its work in some places). If anyone else sees this, let me know -\n- it may just be an quirk on my machine (unlikely). Testing with the gcc-\n2.95.2 installation always works.\n\n\n\n

    Inline

    \n

    \ninline() compiles and executes C/C++ code on the fly. Variables \nin the local and global Python scope are also available in the C/C++ code. \nValues are passed to the C/C++ code by assignment much like variables \nare passed into a standard Python function. Values are returned from the C/C++ \ncode through a special argument called return_val. Also, the contents of \nmutable objects can be changed within the C/C++ code and the changes remain \nafter the C code exits and returns to Python. (more on this later)\n

    \nHere's a trivial printf example using inline():\n\n 

    \n    >>> import weave    \n    >>> a  = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
    \n

    \nIn this, its most basic form, inline(c_code, var_list) requires two \narguments. c_code is a string of valid C/C++ code. \nvar_list is a list of variable names that are passed from \nPython into C/C++. Here we have a simple printf statement that \nwrites the Python variable a to the screen. The first time you run \nthis, there will be a pause while the code is written to a .cpp file, compiled \ninto an extension module, loaded into Python, cataloged for future use, and \nexecuted. On windows (850 MHz PIII), this takes about 1.5 seconds when using \nMicrosoft's C++ compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). \nAll subsequent executions of the code will happen very quickly because the code \nonly needs to be compiled once. If you kill and restart the interpreter and then \nexecute the same code fragment again, there will be a much shorter delay in the \nfractions of seconds range. This is because weave stores a \ncatalog of all previously compiled functions in an on disk cache. When it sees \na string that has been compiled, it loads the already compiled module and \nexecutes the appropriate function. \n

    \n\nNote: If you try the printf example in a GUI shell such as IDLE, \nPythonWin, PyShell, etc., you're unlikely to see the output. This is because the \nC code is writing to stdout, instead of to the GUI window. This doesn't mean \nthat inline doesn't work in these environments -- it only means that standard \nout in C is not the same as the standard out for Python in these cases. Non \ninput/output functions will work as expected.\n\n

    \nAlthough effort has been made to reduce the overhead associated with calling \ninline, it is still less efficient for simple code snippets than using \nequivalent Python code. The simple printf example is actually \nslower by 30% or so than using Python print statement. And, it is \nnot difficult to create code fragments that are 8-10 times slower using inline \nthan equivalent Python. However, for more complicated algorithms, \nthe speed up can be worth while -- anywhwere from 1.5- 30 times faster. \nAlgorithms that have to manipulate Python objects (sorting a list) usually only \nsee a factor of 2 or so improvement. Algorithms that are highly computational \nor manipulate Numeric arrays can see much larger improvements. The \nexamples/vq.py file shows a factor of 30 or more improvement on the vector \nquantization algorithm that is used heavily in information theory and \nclassification problems.\n

    \n\n\n

    More with printf

    \n

    \nMSVC users will actually see a bit of compiler output that distutils does not\nsupress the first time the code executes:\n\n 

        \n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    sc_e013937dbc8c647ac62438874e5795131.cpp\n       Creating library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\n       \\Release\\sc_e013937dbc8c647ac62438874e5795131.lib and object C:\\DOCUME\n       ~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_e013937dbc8c64\n       7ac62438874e5795131.exp\n    1\n
    \n

    \nNothing bead is happening, its just a bit annoying. Anyone know how to \nturn this off? \n

    \nThis example also demonstrates using 'raw strings'. The r \npreceeding the code string in the last example denotes that this is a 'raw \nstring'. In raw strings, the backslash character is not interpreted as an \nescape character, and so it isn't necessary to use a double backslash to \nindicate that the '\\n' is meant to be interpreted in the C printf \nstatement instead of by Python. If your C code contains a lot\nof strings and control characters, raw strings might make things easier.\nMost of the time, however, standard strings work just as well.\n\n

    \nThe printf statement in these examples is formatted to print \nout integers. What happens if a is a string? inline\nwill happily, compile a new version of the code to accept strings as input,\nand execute the code. The result?\n\n 

        \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    32956972\n
    \n

    \nIn this case, the result is non-sensical, but also non-fatal. In other \nsituations, it might produce a compile time error because a is \nrequired to be an integer at some point in the code, or it could produce a \nsegmentation fault. Its possible to protect against passing \ninline arguments of the wrong data type by using asserts in \nPython.\n\n 

        \n    >>> a = 'string'\n    >>> def protected_printf(a):    \n    ...     assert(type(a) == type(1))\n    ...     weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    >>> protected_printf(1)\n     1\n    >>> protected_printf('string')\n    AssertError...\n
    \n\n

    \nFor printing strings, the format statement needs to be changed.\n\n 

        \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%s\\n\",a);',['a'])\n    string\n
    \n\n

    \nAs in this case, C/C++ code fragments often have to change to accept different \ntypes. For the given printing task, however, C++ streams provide a way of a \nsingle statement that works for integers and strings. By default, the stream \nobjects live in the std (standard) namespace and thus require the use of \nstd::.\n\n 

        \n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    1    \n    >>> a = 'string'\n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    string\n
    \n \n

    \nExamples using printf and cout are included in \nexamples/print_example.py.\n\n\n

    More examples

    \n\nThis section shows several more advanced uses of inline. It \nincludes a few algorithms from the Python Cookbook \nthat have been re-written in inline C to improve speed as well as a couple \nexamples using Numeric and wxPython.\n\n\n

    Binary search

    \nLets look at the example of searching a sorted list of integers for a value. \nFor inspiration, we'll use Kalle Svensson's \nbinary_search() algorithm from the Python Cookbook. His recipe follows:\n\n 
    \n    def binary_search(seq, t):\n        min = 0; max = len(seq) - 1\n        while 1:\n            if max < min:\n                return -1\n            m = (min  + max)  / 2\n            if seq[m] < t: \n                min = m  + 1 \n            elif seq[m] > t: \n                max = m  - 1 \n            else:\n                return m    \n
    \n\nThis Python version works for arbitrary Python data types. The C version below is \nspecialized to handle integer values. There is a little type checking done in \nPython to assure that we're working with the correct data types before heading \ninto C. The variables seq and t don't need to be \ndeclared beacuse weave handles converting and declaring them in \nthe C code. All other temporary variables such as min, max, etc. \nmust be declared -- it is C after all. Here's the new mixed Python/C function:\n\n 
        \n    def c_int_binary_search(seq,t):\n        # do a little type checking in Python\n        assert(type(t) == type(1))\n        assert(type(seq) == type([]))\n        \n        # now the C code\n        code = \"\"\"\n               #line 29 \"binary_search.py\"\n               int val, m, min = 0;  \n               int max = seq.length() - 1;\n               PyObject *py_val; \n               for(;;)\n               {\n                   if (max < min  ) \n                   { \n                       return_val =  Py::new_reference_to(Py::Int(-1)); \n                       break;\n                   } \n                   m =  (min + max) /2;\n                   val =    py_to_int(PyList_GetItem(seq.ptr(),m),\"val\"); \n                   if (val  < t) \n                       min = m  + 1;\n                   else if (val >  t)\n                       max = m - 1;\n                   else\n                   {\n                       return_val = Py::new_reference_to(Py::Int(m));\n                       break;\n                   }\n               }\n               \"\"\"\n        return inline(code,['seq','t'])\n
    \n

    \nWe have two variables seq and t passed in. \nt is guaranteed (by the assert) to be an integer. \nPython integers are converted to C int types in the transition from Python to \nC. seq is a Python list. By default, it is translated to a CXX \nlist object. Full documentation for the CXX library can be found at its website. The basics are that the CXX \nprovides C++ class equivalents for Python objects that simplify, or at \nleast object orientify, working with Python objects in C/C++. For example, \nseq.length() returns the length of the list. A little more about\nCXX and its class methods, etc. is in the ** type conversions ** section.\n

    \nMost of the algorithm above looks similar in C to the original Python code. \nThere are two main differences. The first is the setting of \nreturn_val instead of directly returning from the C code with a \nreturn statement. return_val is an automatically \ndefined variable of type PyObject* that is returned from the C \ncode back to Python. You'll have to handle reference counting issues when \nsetting this variable. In this example, CXX classes and functions handle the \ndirty work. All CXX functions and classes live in the namespace \nPy::. The following code converts the integer m to a \nCXX Int() object and then to a PyObject* with an \nincremented reference count using Py::new_reference_to().\n\n 

       \n    return_val = Py::new_reference_to(Py::Int(m));\n
    \n

    \nThe second big differences shows up in the retrieval of integer values from the \nPython list. The simple Python seq[i] call balloons into a C \nPython API call to grab the value out of the list and then a separate call to \npy_to_int() that converts the PyObject* to an integer. \npy_to_int() includes both a NULL cheack and a \nPyInt_Check() call as well as the conversion call. If either of \nthe checks fail, an exception is raised. The entire C++ code block is executed \nwith in a try/catch block that handles exceptions much like Python \ndoes. This removes the need for most error checking code.\n

    \nIt is worth note that CXX lists do have indexing operators that result \nin code that looks much like Python. However, the overhead in using them \nappears to be relatively high, so the standard Python API was used on the \nseq.ptr() which is the underlying PyObject* of the \nList object.\n

    \nThe #line directive that is the first line of the C code \nblock isn't necessary, but it's nice for debugging. If the compilation fails \nbecause of the syntax error in the code, the error will be reported as an error \nin the Python file \"binary_search.py\" with an offset from the given line number \n(29 here).\n

    \nSo what was all our effort worth in terms of efficiency? Well not a lot in \nthis case. The examples/binary_search.py file runs both Python and C versions \nof the functions As well as using the standard bisect module. If \nwe run it on a 1 million element list and run the search 3000 times (for 0-\n2999), here are the results we get:\n\n 

       \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python binary_search.py\n    Binary search for 3000 items in 1000000 length list of integers:\n     speed in python: 0.159999966621\n     speed of bisect: 0.121000051498\n     speed up: 1.32\n     speed in c: 0.110000014305\n     speed up: 1.45\n     speed in c(no asserts): 0.0900000333786\n     speed up: 1.78\n
    \n

    \nSo, we get roughly a 50-75% improvement depending on whether we use the Python \nasserts in our C version. If we move down to searching a 10000 element list, \nthe advantage evaporates. Even smaller lists might result in the Python \nversion being faster. I'd like to say that moving to Numeric lists (and \ngetting rid of the GetItem() call) offers a substantial speed up, but my \npreliminary efforts didn't produce one. I think the log(N) algorithm is to \nblame. Because the algorithm is nice, there just isn't much time spent \ncomputing things, so moving to C isn't that big of a win. If there are ways to \nreduce conversion overhead of values, this may improve the C/Python speed \nup. Anyone have other explanations or faster code, please let me know.\n\n\n

    Dictionary Sort

    \n

    \nThe demo in examples/dict_sort.py is another example from the Python CookBook. \nThis \nsubmission, by Alex Martelli, demonstrates how to return the values from a \ndictionary sorted by their keys:\n\n 

           \n    def sortedDictValues3(adict):\n        keys = adict.keys()\n        keys.sort()\n        return map(adict.get, keys)\n
    \n

    \nAlex provides 3 algorithms and this is the 3rd and fastest of the set. The C \nversion of this same algorithm follows:\n\n 

           \n    def c_sort(adict):\n        assert(type(adict) == type({}))\n        code = \"\"\"     \n        #line 21 \"dict_sort.py\"  \n        Py::List keys = adict.keys();\n        Py::List items(keys.length()); keys.sort();     \n        PyObject* item = NULL; \n        for(int i = 0;  i < keys.length();i++)\n        {\n            item = PyList_GET_ITEM(keys.ptr(),i);\n            item = PyDict_GetItem(adict.ptr(),item);\n            Py_XINCREF(item);\n            PyList_SetItem(items.ptr(),i,item);              \n        }           \n        return_val = Py::new_reference_to(items);\n        \"\"\"   \n        return inline_tools.inline(code,['adict'],verbose=1)\n
    \n

    \nLike the original Python function, the C++ version can handle any Python \ndictionary regardless of the key/value pair types. It uses CXX objects for the \nmost part to declare python types in C++, but uses Python API calls to manipulate \ntheir contents. Again, this choice is made for speed. The C++ version, while\nmore complicated, is about a factor of 2 faster than Python.\n\n 

           \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python dict_sort.py\n    Dict sort of 1000 items for 300 iterations:\n     speed in python: 0.319999933243\n    [0, 1, 2, 3, 4]\n     speed in c: 0.151000022888\n     speed up: 2.12\n    [0, 1, 2, 3, 4]\n
    \n

    \n\n

    Numeric -- cast/copy/transpose

    \n\nCastCopyTranspose is a function called quite heavily by Linear Algebra routines\nin the Numeric library. Its needed in part because of the row-major memory layout\nof multi-demensional Python (and C) arrays vs. the col-major order of the underlying\nFortran algorithms. For small matrices (say 100x100 or less), a significant\nportion of the common routines such as LU decompisition or singular value decompostion\nare spent in this setup routine. This shouldn't happen. Here is the Python\nversion of the function using standard Numeric operations.\n\n 
           \n    def _castCopyAndTranspose(type, array):\n        if a.typecode() == type:\n            cast_array = copy.copy(Numeric.transpose(a))\n        else:\n            cast_array = copy.copy(Numeric.transpose(a).astype(type))\n        return cast_array\n
    \n\nAnd the following is a inline C version of the same function:\n\n 
    \n    from weave.blitz_tools import blitz_type_factories\n    from weave import scalar_spec\n    from weave import inline\n    def _cast_copy_transpose(type,a_2d):\n        assert(len(shape(a_2d)) == 2)\n        new_array = zeros(shape(a_2d),type)\n        numeric_type = scalar_spec.numeric_to_blitz_type_mapping[type]\n        code = \\\n        \"\"\"  \n        for(int i = 0;i < _Na_2d[0]; i++)  \n            for(int j = 0;  j < _Na_2d[1]; j++)\n                new_array(i,j) = (%s) a_2d(j,i);\n        \"\"\" % numeric_type\n        inline(code,['new_array','a_2d'],\n               type_factories = blitz_type_factories,compiler='gcc')\n        return new_array\n
    \n\nThis example uses blitz++ arrays instead of the standard representation of \nNumeric arrays so that indexing is simplier to write. This is accomplished by \npassing in the blitz++ \"type factories\" to override the standard Python to C++ \ntype conversions. Blitz++ arrays allow you to write clean, fast code, but they \nalso are sloooow to compile (20 seconds or more for this snippet). This is why \nthey aren't the default type used for Numeric arrays (and also because most \ncompilers can't compile blitz arrays...). inline() is also forced \nto use 'gcc' as the compiler because the default compiler on Windows (MSVC) \nwill not compile blitz code. 'gcc' I think will use the standard compiler \non Unix machine instead of explicitly forcing gcc (check this) \n\nComparisons of the Python vs inline C++ code show a factor of 3 speed up. Also \nshown are the results of an \"inplace\" transpose routine that can be used if the \noutput of the linear algebra routine can overwrite the original matrix (this is \noften appropriate). This provides another factor of 2 improvement.\n\n 
    \n     #C:\\home\\ej\\wrk\\scipy\\weave\\examples> python cast_copy_transpose.py\n    # Cast/Copy/Transposing (150,150)array 1 times\n    #  speed in python: 0.870999932289\n    #  speed in c: 0.25\n    #  speed up: 3.48\n    #  inplace transpose c: 0.129999995232\n    #  speed up: 6.70\n
    \n\n\n

    wxPython

    \n\ninline knows how to handle wxPython objects. Thats nice in and of\nitself, but it also demonstrates that the type conversion mechanism is reasonably \nflexible. Chances are, it won't take a ton of effort to support special types\nyou might have. The examples/wx_example.py borrows the scrolled window\nexample from the wxPython demo, accept that it mixes inline C code in the middle\nof the drawing function.\n\n 
    \n    def DoDrawing(self, dc):\n        \n        red = wxNamedColour(\"RED\");\n        blue = wxNamedColour(\"BLUE\");\n        grey_brush = wxLIGHT_GREY_BRUSH;\n        code = \\\n        \"\"\"\n        #line 108 \"wx_example.py\" \n        dc->BeginDrawing();\n        dc->SetPen(wxPen(*red,4,wxSOLID));\n        dc->DrawRectangle(5,5,50,50);\n        dc->SetBrush(*grey_brush);\n        dc->SetPen(wxPen(*blue,4,wxSOLID));\n        dc->DrawRectangle(15, 15, 50, 50);\n        \"\"\"\n        inline(code,['dc','red','blue','grey_brush'])\n        \n        dc.SetFont(wxFont(14, wxSWISS, wxNORMAL, wxNORMAL))\n        dc.SetTextForeground(wxColour(0xFF, 0x20, 0xFF))\n        te = dc.GetTextExtent(\"Hello World\")\n        dc.DrawText(\"Hello World\", 60, 65)\n\n        dc.SetPen(wxPen(wxNamedColour('VIOLET'), 4))\n        dc.DrawLine(5, 65+te[1], 60+te[0], 65+te[1])\n        ...\n
    \n\nHere, some of the Python calls to wx objects were just converted to C++ calls. There\nisn't any benefit, it just demonstrates the capabilities. You might want to use this\nif you have a computationally intensive loop in your drawing code that you want to \nspeed up.\n\nOn windows, you'll have to use the MSVC compiler if you use the standard wxPython\nDLLs distributed by Robin Dunn. Thats because MSVC and gcc, while binary\ncompatible in C, are not binary compatible for C++. In fact, its probably best, no \nmatter what platform you're on, to specify that inline use the same\ncompiler that was used to build wxPython to be on the safe side. There isn't currently\na way to learn this info from the library -- you just have to know. Also, at least\non the windows platform, you'll need to install the wxWindows libraries and link to \nthem. I think there is a way around this, but I haven't found it yet -- I get some\nlinking errors dealing with wxString. One final note. You'll probably have to\ntweak weave/wx_spec.py or weave/wx_info.py for your machine's configuration to\npoint at the correct directories etc. There. That should sufficiently scare people\ninto not even looking at this... :)\n\n    \n

    Keyword Options

    \n

    \nThe basic definition of the inline() function has a slew of \noptional variables. It also takes keyword arguments that are passed to \ndistutils as compiler options. The following is a formatted \ncut/paste of the argument section of inline's doc-string. It \nexplains all of the variables. Some examples using various options will \nfollow.\n\n 

           \n    def inline(code,arg_names,local_dict = None, global_dict = None, \n               force = 0, \n               compiler='',\n               verbose = 0, \n               support_code = None,\n               customize=None, \n               type_factories = None, \n               auto_downcast=1,\n               **kw):\n
    \n\n \ninline has quite \na few options as listed below. Also, the keyword arguments for distutils \nextension modules are accepted to specify extra information needed for \ncompiling. \n
    \n

    inline Arguments:

    \n
    \n
    \n
    code
    \n \n
    \nstring. A string of valid C++ code. It should not \n specify a return statement. Instead it should assign results that need to be \n returned to Python in the return_val. \n
    \n\n
    arg_names
    \n \n
    \nlist of strings. A list of Python variable names \n that should be transferred from Python into the C/C++ code. \n
    \n\n
    local_dict
    \n \n
    \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the local scope for the C/C++ \n code. If local_dict is not specified the local dictionary of the calling \n function is used. \n
    \n\n
    global_dict
    \n \n
    \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the global scope for the C/C++ \n code. If global_dict is not specified the global dictionary of the calling \n function is used. \n
    \n\n
    force
    \n \n
    \noptional. 0 or 1. default 0. If 1, the C++ code is \n compiled every time inline is called. This is really only useful for \n debugging, and probably only useful if you're editing support_code a lot. \n
    \n\n
    compiler
    \n \n
    \noptional. string. The name of compiler to use when compiling. On windows, it \nunderstands 'msvc' and 'gcc' as well as all the compiler names understood by \ndistutils. On Unix, it'll only understand the values understoof by distutils. \n(I should add 'gcc' though to this).\n

    \nOn windows, the compiler defaults to the Microsoft C++ compiler. If this isn't \navailable, it looks for mingw32 (the gcc compiler).\n

    \nOn Unix, it'll probably use the same compiler that was used when compiling \nPython. Cygwin's behavior should be similar.

    \n
    \n\n
    verbose
    \n \n
    \noptional. 0,1, or 2. defualt 0. Speficies how much \n much information is printed during the compile phase of inlining code. 0 is \n silent (except on windows with msvc where it still prints some garbage). 1 \n informs you when compiling starts, finishes, and how long it took. 2 prints \n out the command lines for the compilation process and can be useful if you're \n having problems getting code to work. Its handy for finding the name of the \n .cpp file if you need to examine it. verbose has no affect if the \n compilation isn't necessary. \n
    \n\n
    support_code
    \n \n
    \noptional. string. A string of valid C++ code \n declaring extra code that might be needed by your compiled function. This \n could be declarations of functions, classes, or structures. \n
    \n\n
    customize
    \n \n
    \noptional. base_info.custom_info object. An \n alternative way to specifiy support_code, headers, etc. needed by the \n function see the weave.base_info module for more details. (not sure \n this'll be used much). \n \n
    \n
    type_factories
    \n \n
    \noptional. list of type specification factories. These guys are what convert \nPython data types to C/C++ data types. If you'd like to use a different set of \ntype conversions than the default, specify them here. Look in the type \nconversions section of the main documentation for examples.\n
    \n
    auto_downcast
    \n \n
    \noptional. 0 or 1. default 1. This only affects functions that have Numeric \narrays as input variables. Setting this to 1 will cause all floating point \nvalues to be cast as float instead of double if all the Numeric arrays are of \ntype float. If even one of the arrays has type double or double complex, all \nvariables maintain there standard types.\n
    \n
    \n
    \n\n

    Distutils keywords:

    \n
    \ninline() also accepts a number of distutils keywords \nfor controlling how the code is compiled. The following descriptions have been \ncopied from Greg Ward's distutils.extension.Extension class doc-\nstrings for convenience:\n\n
    \n
    sources
    \n \n
    \n[string] list of source filenames, relative to the \n distribution root (where the setup script lives), in Unix form \n (slash-separated) for portability. Source files may be C, C++, SWIG (.i), \n platform-specific resource files, or whatever else is recognized by the \n \"build_ext\" command as source for a Python extension. Note: The module_path \n file is always appended to the front of this list \n
    \n\n
    include_dirs
    \n \n
    \n[string] list of directories to search for C/C++ \n header files (in Unix form for portability) \n
    \n\n
    define_macros
    \n \n
    \n[(name : string, value : string|None)] list of \n macros to define; each macro is defined using a 2-tuple, where 'value' is \n either the string to define it to or None to define it without a particular \n value (equivalent of \"#define FOO\" in source or -DFOO on Unix C compiler \n command line) \n
    \n
    undef_macros
    \n \n
    \n[string] list of macros to undefine explicitly \n
    \n
    library_dirs
    \n
    \n[string] list of directories to search for C/C++ libraries at link time \n
    \n
    libraries
    \n
    \n[string] list of library names (not filenames or paths) to link against \n
    \n
    runtime_library_dirs
    \n
    \n[string] list of directories to search for C/C++ libraries at run time (for \nshared extensions, this is when the extension is loaded) \n
    \n\n
    extra_objects
    \n \n
    \n[string] list of extra files to link with (eg. \n object files not implied by 'sources', static library that must be \n explicitly specified, binary resource files, etc.) \n
    \n\n
    extra_compile_args
    \n \n
    \n[string] any extra platform- and compiler-specific \n information to use when compiling the source files in 'sources'. For \n platforms and compilers where \"command line\" makes sense, this is typically \n a list of command-line arguments, but for other platforms it could be \n anything. \n
    \n
    extra_link_args
    \n \n
    \n[string] any extra platform- and compiler-specific \n information to use when linking object files together to create the \n extension (or to create a new static Python interpreter). Similar \n interpretation as for 'extra_compile_args'. \n
    \n
    export_symbols
    \n \n
    \n[string] list of symbols to be exported from a shared extension. Not used on \nall platforms, and not generally necessary for Python extensions, which \ntypically export exactly one symbol: \"init\" + extension_name. \n
    \n
    \n
    \n\n\n

    Keyword Option Examples

    \nWe'll walk through several examples here to demonstrate the behavior of \ninline and also how the various arguments are used.\n\nIn the simplest (most) cases, code and arg_names\nare the only arguments that need to be specified. Here's a simple example\nrun on Windows machine that has Microsoft VC++ installed.\n\n 
    \n    >>> from weave import inline\n    >>> a = 'string'\n    >>> code = \"\"\"\n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));\n    ...        \"\"\"\n    >>> inline(code,['a'])\n     sc_86e98826b65b047ffd2cd5f479c627f12.cpp\n    Creating\n       library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f12.lib\n    and object C:\\DOCUME~ 1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ff\n    d2cd5f479c627f12.exp\n    6\n    >>> inline(code,['a'])\n    6\n
    \n \nWhen inline is first run, you'll notice that pause and some \ntrash printed to the screen. The \"trash\" is acutually part of the compilers\noutput that distutils does not supress. On Unix or windows machines with only\ngcc installed, the trash will not appear. On the second call, the code \nfragment is not compiled since it already exists, and only the answer is \nreturned. Now kill the interpreter and restart, and run the same code with\na different string.\n\n 
    \n    >>> from weave import inline\n    >>> a = 'a longer string' \n    >>> code = \"\"\" \n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));  \n    ...        \"\"\"\n    >>> inline(code,['a'])\n    15\n
    \n

    \nNotice this time, inline() did not recompile the code because it\nfound the compiled function in the persistent catalog of functions. There is\na short pause as it looks up and loads the function, but it is much shorter \nthan compiling would require.\n

    \nYou can specify the local and global dictionaries if you'd like (much like \nexec or eval() in Python), but if they aren't \nspecified, the \"expected\" ones are used -- i.e. the ones from the function that \ncalled inline() . This is accomplished through a little call \nframe trickery. Here is an example where the local_dict is specified using\nthe same code example from above:\n\n 

    \n    >>> a = 'a longer string'\n    >>> b = 'an even  longer string' \n    >>> my_dict = {'a':b}\n    >>> inline(code,['a'])\n    15\n    >>> inline(code,['a'],my_dict)\n    21\n
    \n \n

    \nEverytime, the code is changed, inline does a \nrecompile. However, changing any of the other options in inline does not\nforce a recompile. The force option was added so that one\ncould force a recompile when tinkering with other variables. In practice,\nit is just as easy to change the code by a single character\n(like adding a space some place) to force the recompile. Note: It also \nmight be nice to add some methods for purging the cache and on disk \ncatalogs.\n

    \nI use verbose sometimes for debugging. When set to 2, it'll \noutput all the information (including the name of the .cpp file) that you'd\nexpect from running a make file. This is nice if you need to examine the\ngenerated code to see where things are going haywire. Note that error\nmessages from failed compiles are printed to the screen even if verbose\n is set to 0.\n

    \nThe following example demonstrates using gcc instead of the standard msvc \ncompiler on windows using same code fragment as above. Because the example has \nalready been compiled, the force=1 flag is needed to make \ninline() ignore the previously compiled version and recompile \nusing gcc. The verbose flag is added to show what is printed out:\n\n 

    \n    >>>inline(code,['a'],compiler='gcc',verbose=2,force=1)\n    running build_ext    \n    building 'sc_86e98826b65b047ffd2cd5f479c627f13' extension \n    c:\\gcc-2.95.2\\bin\\g++.exe -mno-cygwin -mdll -O2 -w -Wstrict-prototypes -IC:\n    \\home\\ej\\wrk\\scipy\\weave -IC:\\Python21\\Include -c C:\\DOCUME~1\\eric\\LOCAL\n    S~1\\Temp\\python21_compiled\\sc_86e98826b65b047ffd2cd5f479c627f13.cpp -o C:\\D\n    OCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b04\n    7ffd2cd5f479c627f13.o    \n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxextensions.c (C:\\DOCUME~1\\eri\n    c\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxextensions.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxsupport.cxx (C:\\DOCUME~1\\eric\n    \\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxsupport.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\IndirectPythonInterface.cxx (C:\\\n    DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\indirectpythonin\n    terface.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxx_extensions.cxx (C:\\DOCUME~1\\\n    eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxx_extensions.o up-to-da\n    te)\n    writing C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86\n    e98826b65b047ffd2cd5f479c627f13.def\n    c:\\gcc-2.95.2\\bin\\dllwrap.exe --driver-name g++ -mno-cygwin -mdll -static -\n    -output-lib C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\l\n    ibsc_86e98826b65b047ffd2cd5f479c627f13.a --def C:\\DOCUME~1\\eric\\LOCALS~1\\Te\n    mp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f13.def \n    -s C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e9882\n    6b65b047ffd2cd5f479c627f13.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compil\n    ed\\temp\\Release\\cxxextensions.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\cxxsupport.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\indirectpythoninterface.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\n    \\python21_compiled\\temp\\Release\\cxx_extensions.o -LC:\\Python21\\libs -lpytho\n    n21 -o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\sc_86e98826b65b047f\n    fd2cd5f479c627f13.pyd\n    15\n
    \n\nThat's quite a bit of output. verbose=1 just prints the compile\ntime.\n\n 
    \n    >>>inline(code,['a'],compiler='gcc',verbose=1,force=1)\n    Compiling code...\n    finished compiling (sec):  6.00800001621\n    15\n
    \n\n

    \n Note: I've only used the weave option for switching between 'msvc'\nand 'gcc' on windows. It may have use on Unix also, but I don't know yet.\n\n\n

    \nThe support_code argument is likely to be used a lot. It allows \nyou to specify extra code fragments such as function, structure or class \ndefinitions that you want to use in the code string. Note that \nchanges to support_code do not force a recompile. The \ncatalog only relies on code (for performance reasons) to determine \nwhether recompiling is necessary. So, if you make a change to support_code, \nyou'll need to alter code in some way or use the \nforce argument to get the code to recompile. I usually just add \nsome inocuous whitespace to the end of one of the lines in code \nsomewhere. Here's an example of defining a separate method for calculating\nthe string length:\n\n 

    \n    >>> from weave import inline\n    >>> a = 'a longer string'\n    >>> support_code = \"\"\"\n    ...                PyObject* length(Py::String a)\n    ...                {\n    ...                    int l = a.length();  \n    ...                    return Py::new_reference_to(Py::Int(l)); \n    ...                }\n    ...                \"\"\"        \n    >>> inline(\"return_val = length(a);\",['a'],\n    ...        support_code = support_code)\n    15\n
    \n

    \ncustomize is a left over from a previous way of specifying \ncompiler options. It is a custom_info object that can specify \nquite a bit of information about how a file is compiled. These \ninfo objects are the standard way of defining compile information \nfor type conversion classes. However, I don't think they are as handy here, \nespecially since we've exposed all the keyword arguments that distutils can \nhandle. Between these keywords, and the support_code option, I \nthink customize may be obsolete. We'll see if anyone cares to use \nit. If not, it'll get axed in the next version.\n

    \nThe type_factories variable is important to people who want to\ncustomize the way arguments are converted from Python to C. We'll talk about\nthis in the next chapter **xx** of this document when we discuss type\nconversions.\n

    \nauto_downcast handles one of the big type conversion issues that\nis common when using Numeric arrays in conjunction with Python scalar values.\nIf you have an array of single precision values and multiply that array by a \nPython scalar, the result is upcast to a double precision array because the\nscalar value is double precision. This is not usually the desired behavior\nbecause it can double your memory usage. auto_downcast goes\nsome distance towards changing the casting precedence of arrays and scalars.\nIf your only using single precision arrays, it will automatically downcast all\nscalar values from double to single precision when they are passed into the\nC++ code. This is the default behavior. If you want all values to keep there\ndefault type, set auto_downcast to 0.\n

    \n\n\n\n

    Returning Values

    \n\nPython variables in the local and global scope transfer seemlessly from Python \ninto the C++ snippets. And, if inline were to completely live up\nto its name, any modifications to variables in the C++ code would be reflected\nin the Python variables when control was passed back to Python. For example,\nthe desired behavior would be something like:\n\n 
    \n    # THIS DOES NOT WORK\n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    2\n
    \n\nInstead you get:\n\n 
    \n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    1\n
    \n \nVariables are passed into C++ as if you are calling a Python function. Python's \ncalling convention is sometimes called \"pass by assignment\". This means its as \nif a c_a = a assignment is made right before inline \ncall is made and the c_a variable is used within the C++ code. \nThus, any changes made to c_a are not reflected in Python's \na variable. Things do get a little more confusing, however, when \nlooking at variables with mutable types. Changes made in C++ to the contents \nof mutable types are reflected in the Python variables.\n\n 
    \n    >>> a= [1,2]\n    >>> weave.inline(\"PyList_SetItem(a.ptr(),0,PyInt_FromLong(3));\",['a'])\n    >>> print a\n    [3, 2]\n
    \n\nSo modifications to the contents of mutable types in C++ are seen when control\nis returned to Python. Modifications to immutable types such as tuples,\nstrings, and numbers do not alter the Python variables.\n\nIf you need to make changes to an immutable variable, you'll need to assign\nthe new value to the \"magic\" variable return_val in C++. This\nvalue is returned by the inline() function:\n\n 
    \n    >>> a = 1\n    >>> a = weave.inline(\"return_val = Py::new_reference_to(Py::Int(a+1));\",['a'])  \n    >>> a\n    2\n
    \n\nThe return_val variable can also be used to return newly created \nvalues. This is possible by returning a tuple. The following trivial example \nillustrates how this can be done:\n\n 
           \n    # python version\n    def multi_return():\n        return 1, '2nd'\n    \n    # C version.\n    def c_multi_return():    \n        code =  \"\"\"\n     \t        Py::Tuple results(2);\n     \t        results[0] = Py::Int(1);\n     \t        results[1] = Py::String(\"2nd\");\n     \t        return_val = Py::new_reference_to(results); \t        \n                \"\"\"\n        return inline_tools.inline(code,[])\n
    \n

    \nThe example is available in examples/tuple_return.py. It also\nhas the dubious honor of demonstrating how much inline() can \nslow things down. The C version here is about 10 times slower than the Python\nversion. Of course, something so trivial has no reason to be written in\nC anyway.\n\n\n

    The issue with locals()

    \n

    \ninline passes the locals() and globals() \ndictionaries from Python into the C++ function from the calling function. It \nextracts the variables that are used in the C++ code from these dictionaries, \nconverts then to C++ variables, and then calculates using them. It seems like \nit would be trivial, then, after the calculations were finished to then insert \nthe new values back into the locals() and globals() \ndictionaries so that the modified values were reflected in Python. \nUnfortunately, as pointed out by the Python manual, the locals() dictionary is \nnot writable. \n

    \n\nI suspect locals() is not writable because there are some \noptimizations done to speed lookups of the local namespace. I'm guessing local \nlookups don't always look at a dictionary to find values. Can someone \"in the \nknow\" confirm or correct this? Another thing I'd like to know is whether there \nis a way to write to the local namespace of another stack frame from C/C++. If \nso, it would be possible to have some clean up code in compiled functions that \nwrote final values of variables in C++ back to the correct Python stack frame. \nI think this goes a long way toward making inline truely live up \nto its name. I don't think we'll get to the point of creating variables in \nPython for variables created in C -- although I suppose with a C/C++ parser you \ncould do that also.\n\n

    \n\n\n

    A quick look at the code

    \n\nweave generates a C++ file holding an extension function for \neach inline code snippet. These file names are generated using \nfrom the md5 signature of the code snippet and saved to a location specified by \nthe PYTHONCOMPILED environment variable (discussed later). The cpp files are \ngenerally about 200-400 lines long and include quite a few functions to support \ntype conversions, etc. However, the actual compiled function is pretty simple. \nBelow is the familiar printf example:\n\n 
    \n    >>> import weave    \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
    \n\nAnd here is the extension function generated by inline:\n\n 
    \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        // The Py_None needs an incref before returning\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n        \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try                              \n        {                                \n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n            /* Here is the inline code */            \n            printf(\"%d\\n\",a);\n            /* I would like to fill in changed locals and globals here... */\n        }                                       \n        catch( Py::Exception& e)           \n        {                                \n            return_val =  Py::Null();    \n            exception_occured = 1;       \n        }                                 \n        if(!return_val && !exception_occured)\n        {\n                                      \n            Py_INCREF(Py_None);              \n            return_val = Py_None;            \n        }\n        /* clean up code */\n        \n        /* return */                              \n        return return_val;           \n    }                                \n
    \n\nEvery inline function takes exactly two arguments -- the local and global\ndictionaries for the current scope. All variable values are looked up out\nof these dictionaries. The lookups, along with all inline code \nexecution, are done within a C++ try block. If the variables\naren't found, or there is an error converting a Python variable to the \nappropriate type in C++, an exception is raised. The C++ exception\nis automatically converted to a Python exception by CXX and returned to Python.\n\nThe py_to_int() function illustrates how the conversions and\nexception handling works. py_to_int first checks that the given PyObject*\npointer is not NULL and is a Python integer. If all is well, it calls the\nPython API to convert the value to an int. Otherwise, it calls\nhandle_bad_type() which gathers information about what went wrong\nand then raises a CXX TypeError which returns to Python as a TypeError.\n\n 
    \n    int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
    \n\n 
    \n    void handle_bad_type(PyObject* py_obj, char* good_type, char*  var_name)\n    {\n        char msg[500];\n        sprintf(msg,\"received '%s' type instead of '%s' for variable '%s'\",\n                find_type(py_obj),good_type,var_name);\n        throw Py::TypeError(msg);\n    }\n    \n    char* find_type(PyObject* py_obj)\n    {\n        if(py_obj == NULL) return \"C NULL value\";\n        if(PyCallable_Check(py_obj)) return \"callable\";\n        if(PyString_Check(py_obj)) return \"string\";\n        if(PyInt_Check(py_obj)) return \"int\";\n        if(PyFloat_Check(py_obj)) return \"float\";\n        if(PyDict_Check(py_obj)) return \"dict\";\n        if(PyList_Check(py_obj)) return \"list\";\n        if(PyTuple_Check(py_obj)) return \"tuple\";\n        if(PyFile_Check(py_obj)) return \"file\";\n        if(PyModule_Check(py_obj)) return \"module\";\n        \n        //should probably do more interagation (and thinking) on these.\n        if(PyCallable_Check(py_obj) && PyInstance_Check(py_obj)) return \"callable\";\n        if(PyInstance_Check(py_obj)) return \"instance\"; \n        if(PyCallable_Check(py_obj)) return \"callable\";\n        return \"unkown type\";\n    }\n
    \n\nSince the inline is also executed within the try/catch\nblock, you can use CXX exceptions within your code. It is usually a bad idea\nto directly return from your code, even if an error occurs. This\nskips the clean up section of the extension function. In this simple example,\nthere isn't any clean up code, but in more complicated examples, there may\nbe some reference counting that needs to be taken care of here on converted\nvariables. To avoid this, either uses exceptions or set \nreturn_val to NULL and use if/then's to skip code\nafter errors.\n\n\n

    Technical Details

    \n

    \nThere are \n

      \n
    1. Type conversion \n
    2. Generating C/C++ code \n
    3. Compile the code to an extension module \n
    4. Catalog (and cache) the function for future use
      5. \n
    \n

    \nItems 1 and 2 above are related, but most easily discussed separately. Type \nconversions are customizable by the user if needed. Understanding them is \npretty important for anything beyond trivial uses of inline. \nGenerating the C/C++ code is handled by ext_function and \next_module classes and . For the most part, compiling the code is \nhandled by distutils. Some customizations were needed, but they were \nrelatively minor and do not require changes to distutils itself (although a few \nchanges would be nice...). Cataloging is pretty simple in concept, but surprisingly\nrequired the most code to implement (and still likely needs some work). So,\nthis section covers items 1 and 4 from the list. Item 2 is covered later in\nthe chapter covering the ext_tools module, and distutils is covered\nby a completely separate document xxx.\n \n

    Passing Variables in/out of the C/C++ code

    \n\nNote: Passing variables into the C code is pretty straight forward, but there \nare subtlties to how variable modifications in C are returned to Python. see \nxxx for a more thorough discussion of this issue.\n \n\n\n

    Type Conversions

    \n\n\nNote: Maybe xxx_converter instead of xxx_specification is a more descriptive \nname.\n\n\n

    \nBy default, inline() makes the following type conversions between\nPython and C++ types.\n

    \n\n

    \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    \n

    Default Data Type Conversions

    \n

    Python

    		\n

    C++

       int   int
       float   double
       complex   std::complex
       string   Py::String
       list   Py::List
       dict   Py::Dict
       tuple   Py::Tuple
       file   FILE*
       callable   PyObject*
       instance   PyObject*
       Numeric.array   PyArrayObject*
       wxXXX   wxXXX*
    \n
    \n

    \nThe Py:: namespace is defined by the \nCXX library which has C++ class\nequivalents for many Python types. std:: is the namespace of the\nstandard library in C++.\n

    \n\nNote: \n

      \n
    • I haven't figured out how to handle long int yet (I think they are currenlty converted \n to int - - check this). \n \n
    • \nHopefully VTK will be added to the list soon
      • \n
    \n
      \n      \n

      \n\nPython to C++ conversions fill in code in several locations in the generated\ninline extension function. Below is the basic template for the\nfunction. This is actually the exact code that is generated by calling\nweave.inline(\"\",[]).\n\n 

      \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n    \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try\n        {\n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            /* argument conversion code */\n            /* inline code */\n            /*I would like to fill in changed locals and globals here...*/\n    \n        }\n        catch( Py::Exception& e)\n        {\n            return_val =  Py::Null();\n            exception_occured = 1;\n        }\n        /* cleanup code */\n        if(!return_val && !exception_occured)\n        {\n    \n            Py_INCREF(Py_None);\n            return_val = Py_None;\n        }\n    \n        return return_val;\n    }\n
      \n\nThe /* inline code */ section is filled with the code passed to\nthe inline() function call. The \n/*argument convserion code*/ and /* cleanup code */\nsections are filled with code that handles conversion from Python to C++\ntypes and code that deallocates memory or manipulates reference counts before\nthe function returns. The following sections demostrate how these two areas\nare filled in by the default conversion methods.\n\n \nNote: I'm not sure I have reference counting correct on a few of these. The \nonly thing I increase/decrease the ref count on is Numeric arrays. If you\nsee an issue, please let me know.\n\n\n\n

      Numeric Argument Conversion

      \n\nInteger, floating point, and complex arguments are handled in a very similar\nfashion. Consider the following inline function that has a single integer \nvariable passed in:\n\n 
      \n    >>> a = 1\n    >>> inline(\"\",['a'])\n
      \n\nThe argument conversion code inserted for a is:\n\n 
      \n    /* argument conversion code */\n    int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
      \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_int() has the following\nform:\n\n 
      \n    static int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
      \n\nSimilarly, the float and complex conversion routines look like:\n\n 
          \n    static double py_to_float(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyFloat_Check(py_obj))\n            handle_bad_type(py_obj,\"float\", name);\n        return PyFloat_AsDouble(py_obj);\n    }\n    \n    static std::complex py_to_complex(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyComplex_Check(py_obj))\n            handle_bad_type(py_obj,\"complex\", name);\n        return std::complex(PyComplex_RealAsDouble(py_obj),\n                                    PyComplex_ImagAsDouble(py_obj));    \n    }\n
      \n\nNumeric conversions do not require any clean up code.\n\n\n

      String, List, Tuple, and Dictionary Conversion

      \n\nStrings, Lists, Tuples and Dictionary conversions are all converted to \nCXX types by default.\n\nFor the following code, \n\n 
      \n    >>> a = [1]\n    >>> inline(\"\",['a'])\n
      \n\nThe argument conversion code inserted for a is:\n\n 
      \n    /* argument conversion code */\n    Py::List a = py_to_list (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
      \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_list() and its\nfriends has the following form:\n\n 
          \n    static Py::List py_to_list(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyList_Check(py_obj))\n            handle_bad_type(py_obj,\"list\", name);\n        return Py::List(py_obj);\n    }\n    \n    static Py::String py_to_string(PyObject* py_obj,char* name)\n    {\n        if (!PyString_Check(py_obj))\n            handle_bad_type(py_obj,\"string\", name);\n        return Py::String(py_obj);\n    }\n\n    static Py::Dict py_to_dict(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyDict_Check(py_obj))\n            handle_bad_type(py_obj,\"dict\", name);\n        return Py::Dict(py_obj);\n    }\n    \n    static Py::Tuple py_to_tuple(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyTuple_Check(py_obj))\n            handle_bad_type(py_obj,\"tuple\", name);\n        return Py::Tuple(py_obj);\n    }\n
      \n\nCXX handles reference counts on for strings, lists, tuples, and dictionaries,\nso clean up code isn't necessary.\n\n\n

      File Conversion

      \n\nFor the following code, \n\n 
      \n    >>> a = open(\"bob\",'w')  \n    >>> inline(\"\",['a'])\n
      \n\nThe argument conversion code is:\n\n 
      \n    /* argument conversion code */\n    PyObject* py_a = get_variable(\"a\",raw_locals,raw_globals);\n    FILE* a = py_to_file(py_a,\"a\");\n
      \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_file() converts\nPyObject* to a FILE* and increments the reference count of the PyObject*:\n\n 
      \n    FILE* py_to_file(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"file\", name);\n    \n        Py_INCREF(py_obj);\n        return PyFile_AsFile(py_obj);\n    }\n
      \n\nBecause the PyObject* was incremented, the clean up code needs to decrement\nthe counter\n\n 
      \n    /* cleanup code */\n    Py_XDECREF(py_a);\n
      \n\nIts important to understand that file conversion only works on actual files --\ni.e. ones created using the open() command in Python. It does\nnot support converting arbitrary objects that support the file interface into\nC FILE* pointers. This can affect many things. For example, in\ninitial printf() examples, one might be tempted to solve the \nproblem of C and Python IDE's (PythonWin, PyCrust, etc.) writing to different\nstdout and stderr by using fprintf() and passing in \nsys.stdout and sys.stderr. For example, instead of\n\n 
      \n    >>> weave.inline('printf(\"hello\\\\n\");',[])\n
      \n \nYou might try:\n\n 
      \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n
      \n\nThis will work as expected from a standard python interpreter, but in PythonWin,\nthe following occurs:\n\n 
      \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n    Traceback (most recent call last):\n        File \"\", line 1, in ?\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 315, in inline\n            auto_downcast = auto_downcast,\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 386, in compile_function\n            type_factories = type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 197, in __init__\n            auto_downcast, type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 390, in assign_variable_types\n            raise TypeError, format_error_msg(errors)\n        TypeError: {'buf': \"Unable to convert variable 'buf' to a C++ type.\"}\n
      \n\nThe traceback tells us that inline() was unable to convert 'buf' to a\nC++ type (If instance conversion was implemented, the error would have occurred at \nruntime instead). Why is this? Let's look at what the buf object \nreally is:\n\n 
      \n    >>> buf\n    pywin.framework.interact.InteractiveView instance at 00EAD014\n
      \n\nPythonWin has reassigned sys.stdout to a special object that \nimplements the Python file interface. This works great in Python, but since \nthe special object doesn't have a FILE* pointer underlying it, fprintf doesn't \nknow what to do with it (well this will be the problem when instance conversion \nis implemented...).\n\n\n

      Callable, Instance, and Module Conversion

      \n\nNote: Need to look into how ref counts should be handled. Also,\nInstance and Module conversion are not currently implemented.\n\n\n 
      \n    >>> def a(): \n        pass\n    >>> inline(\"\",['a'])\n
      \n\nCallable and instance variables are converted to PyObject*. Nothing is done\nto there reference counts.\n\n 
      \n    /* argument conversion code */\n    PyObject* a = py_to_callable(get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
      \n\nget_variable() reads the variable a\nfrom the local and global namespaces. The py_to_callable() and\npy_to_instance() don't currently increment the ref count.\n\n 
          \n    PyObject* py_to_callable(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyCallable_Check(py_obj))\n            handle_bad_type(py_obj,\"callable\", name);    \n        return py_obj;\n    }\n\n    PyObject* py_to_instance(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"instance\", name);    \n        return py_obj;\n    }\n
      \n \nThere is no cleanup code for callables, modules, or instances.\n\n\n

      Customizing Conversions

      \n

      \nConverting from Python to C++ types is handled by xxx_specification classes. A \ntype specification class actually serve in two related but different \nroles. The first is in determining whether a Python variable that needs to be \nconverted should be represented by the given class. The second is as a code \ngenerator that generate C++ code needed to convert from Python to C++ types for \na specific variable.\n

      \nWhen \n\n 

      \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\",a);',['a'])\n
      \n \nis called for the first time, the code snippet has to be compiled. In this \nprocess, the variable 'a' is tested against a list of type specifications (the \ndefault list is stored in weave/ext_tools.py). The first \nspecification in the list is used to represent the variable. \n\n

      \nExamples of xxx_specification are scattered throughout numerous \n\"xxx_spec.py\" files in the weave package. Closely related to \nthe xxx_specification classes are yyy_info classes. \nThese classes contain compiler, header, and support code information necessary \nfor including a certain set of capabilities (such as blitz++ or CXX support)\nin a compiled module. xxx_specification classes have one or more\nyyy_info classes associated with them.\n\nIf you'd like to define your own set of type specifications, the current best route\nis to examine some of the existing spec and info files. Maybe looking over\nsequence_spec.py and cxx_info.py are a good place to start. After defining \nspecification classes, you'll need to pass them into inline using the \ntype_factories argument. \n\nA lot of times you may just want to change how a specific variable type is \nrepresented. Say you'd rather have Python strings converted to \nstd::string or maybe char* instead of using the CXX \nstring object, but would like all other type conversions to have default \nbehavior. This requires that a new specification class that handles strings\nis written and then prepended to a list of the default type specifications. Since\nit is closer to the front of the list, it effectively overrides the default\nstring specification.\n\nThe following code demonstrates how this is done:\n\n...\n\n\n

      The Catalog

      \n

      \ncatalog.py has a class called catalog that helps keep \ntrack of previously compiled functions. This prevents inline() \nand related functions from having to compile functions everytime they are \ncalled. Instead, catalog will check an in memory cache to see if the function \nhas already been loaded into python. If it hasn't, then it starts searching \nthrough persisent catalogs on disk to see if it finds an entry for the given \nfunction. By saving information about compiled functions to disk, it isn't\nnecessary to re-compile functions everytime you stop and restart the interpreter.\nFunctions are compiled once and stored for future use.\n\n

      \nWhen inline(cpp_code) is called the following things happen:\n

        \n
      1. \n A fast local cache of functions is checked for the last function called for \n cpp_code. If an entry for cpp_code doesn't exist in the \n cache or the cached function call fails (perhaps because the function doesn't \n have compatible types) then the next step is to check the catalog. \n
      2. \n The catalog class also keeps an in-memory cache with a list of all the \n functions compiled for cpp_code. If cpp_code has\n ever been called, then this cache will be present (loaded from disk). If\n the cache isn't present, then it is loaded from disk.\n

        \n If the cache is present, each function in the cache is \n called until one is found that was compiled for the correct argument types. If \n none of the functions work, a new function is compiled with the given argument \n types. This function is written to the on-disk catalog as well as into the \n in-memory cache.

        \n
      3. \n When a lookup for cpp_code fails, the catalog looks through \n the on-disk function catalogs for the entries. The PYTHONCOMPILED variable \n determines where to search for these catalogs and in what order. If \n PYTHONCOMPILED is not present several platform dependent locations are \n searched. All functions found for cpp_code in the path are \n loaded into the in-memory cache with functions found earlier in the search \n path closer to the front of the call list.\n

        \n If the function isn't found in the on-disk catalog, \n then the function is compiled, written to the first writable directory in the \n PYTHONCOMPILED path, and also loaded into the in-memory cache.

        \n
        4. \n
      \n\n\n

      Function Storage: How functions are stored in caches and on disk

      \n

      \nFunction caches are stored as dictionaries where the key is the entire C++\ncode string and the value is either a single function (as in the \"level 1\"\ncache) or a list of functions (as in the main catalog cache). On disk\ncatalogs are stored in the same manor using standard Python shelves.\n

      \nEarly on, there was a question as to whether md5 check sums of the C++\ncode strings should be used instead of the actual code strings. I think this\nis the route inline Perl took. Some (admittedly quick) tests of the md5 vs.\nthe entire string showed that using the entire string was at least a\nfactor of 3 or 4 faster for Python. I think this is because it is more\ntime consuming to compute the md5 value than it is to do look-ups of long\nstrings in the dictionary. Look at the examples/md5_speed.py file for the\ntest run. \n\n\n

      Catalog search paths and the PYTHONCOMPILED variable

      \n

      \nThe default location for catalog files on Unix is is ~/.pythonXX_compiled where \nXX is version of Python being used. If this directory doesn't exist, it is \ncreated the first time a catalog is used. The directory must be writable. If, \nfor any reason it isn't, then the catalog attempts to create a directory based \non your user id in the /tmp directory. The directory permissions are set so \nthat only you have access to the directory. If this fails, I think you're out of \nluck. I don't think either of these should ever fail though. On Windows, a \ndirectory called pythonXX_compiled is created in the user's temporary \ndirectory. \n

      \nThe actual catalog file that lives in this directory is a Python shelve with\na platform specific name such as \"nt21compiled_catalog\" so that multiple OSes\ncan share the same file systems without trampling on each other. Along with\nthe catalog file, the .cpp and .so or .pyd files created by inline will live\nin this directory. The catalog file simply contains keys which are the C++\ncode strings with values that are lists of functions. The function lists point\nat functions within these compiled modules. Each function in the lists \nexecutes the same C++ code string, but compiled for different input variables.\n

      \nYou can use the PYTHONCOMPILED environment variable to specify alternative\nlocations for compiled functions. On Unix this is a colon (':') separated\nlist of directories. On windows, it is a (';') separated list of directories.\nThese directories will be searched prior to the default directory for a\ncompiled function catalog. Also, the first writable directory in the list\nis where all new compiled function catalogs, .cpp and .so or .pyd files are\nwritten. Relative directory paths ('.' and '..') should work fine in the\nPYTHONCOMPILED variable as should environement variables.\n

      \nThere is a \"special\" path variable called MODULE that can be placed in the \nPYTHONCOMPILED variable. It specifies that the compiled catalog should\nreside in the same directory as the module that called it. This is useful\nif an admin wants to build a lot of compiled functions during the build\nof a package and then install them in site-packages along with the package.\nUser's who specify MODULE in their PYTHONCOMPILED variable will have access\nto these compiled functions. Note, however, that if they call the function\nwith a set of argument types that it hasn't previously been built for, the\nnew function will be stored in their default directory (or some other writable\ndirectory in the PYTHONCOMPILED path) because the user will not have write\naccess to the site-packages directory.\n

      \nAn example of using the PYTHONCOMPILED path on bash follows:\n\n 

      \n    PYTHONCOMPILED=MODULE:/some/path;export PYTHONCOMPILED;\n
      \n\nIf you are using python21 on linux, and the module bob.py in site-packages\nhas a compiled function in it, then the catalog search order when calling that\nfunction for the first time in a python session would be:\n\n 
      \n    /usr/lib/python21/site-packages/linuxpython_compiled\n    /some/path/linuxpython_compiled\n    ~/.python21_compiled/linuxpython_compiled\n
      \n\nThe default location is always included in the search path.\n

      \n \nNote: hmmm. see a possible problem here. I should probably make a sub-\ndirectory such as /usr/lib/python21/site-\npackages/python21_compiled/linuxpython_compiled so that library files compiled \nwith python21 are tried to link with python22 files in some strange scenarios. \nNeed to check this.\n\n\n

      \nThe in-module cache (in weave.inline_tools reduces the overhead \nof calling inline functions by about a factor of 2. It can be reduced a little \nmore for type loop calls where the same function is called over and over again \nif the cache was a single value instead of a dictionary, but the benefit is \nvery small (less than 5%) and the utility is quite a bit less. So, we'll stick \nwith a dictionary as the cache.\n

      \n\n\n

      Blitz

      \n Note: most of this section is lifted from old documentation. It should be\npretty accurate, but there may be a few discrepancies.\n

      \nweave.blitz() compiles Numeric Python expressions for fast \nexecution. For most applications, compiled expressions should provide a \nfactor of 2-10 speed-up over Numeric arrays. Using compiled \nexpressions is meant to be as unobtrusive as possible and works much like \npythons exec statement. As an example, the following code fragment takes a 5 \npoint average of the 512x512 2d image, b, and stores it in array, a:\n\n 

      \n    from scipy import *  # or from Numeric import *\n    a = ones((512,512), Float64) \n    b = ones((512,512), Float64) \n    # ...do some stuff to fill in b...\n    # now average\n    a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] \\\n                   + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n
      \n \nTo compile the expression, convert the expression to a string by putting\nquotes around it and then use weave.blitz:\n\n 
      \n    import weave\n    expr = \"a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n                          \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n    weave.blitz(expr)\n
      \n\nThe first time weave.blitz is run for a given expression and \nset of arguements, C++ code that accomplishes the exact same task as the Python \nexpression is generated and compiled to an extension module. This can take up \nto a couple of minutes depending on the complexity of the function. Subsequent \ncalls to the function are very fast. Futher, the generated module is saved \nbetween program executions so that the compilation is only done once for a \ngiven expression and associated set of array types. If the given expression\nis executed with a new set of array types, the code most be compiled again. This\ndoes not overwrite the previously compiled function -- both of them are saved and\navailable for exectution. \n

      \nThe following table compares the run times for standard Numeric code and \ncompiled code for the 5 point averaging.\n

      \n

      \n\n\n\n\n\n
      Method Run Time (seconds)
      Standard Numeric 0.46349
      blitz (1st time compiling) 78.95526
      blitz (subsequent calls) 0.05843 (factor of 8 speedup)
      \n
      \n

      \nThese numbers are for a 512x512 double precision image run on a 400 MHz Celeron \nprocessor under RedHat Linux 6.2.\n

      \nBecause of the slow compile times, its probably most effective to develop \nalgorithms as you usually do using the capabilities of scipy or the Numeric \nmodule. Once the algorithm is perfected, put quotes around it and execute it \nusing weave.blitz. This provides the standard rapid \nprototyping strengths of Python and results in algorithms that run close to \nthat of hand coded C or Fortran.\n\n\n

      Requirements

      \n\nCurrently, the weave.blitz has only been tested under Linux \nwith gcc-2.95-3 and on Windows with Mingw32 (2.95.2). Its compiler \nrequirements are pretty heavy duty (see the \nblitz++ home page), so it won't \nwork with just any compiler. Particularly MSVC++ isn't up to snuff. A number \nof other compilers such as KAI++ will also work, but my suspicions are that gcc \nwill get the most use.\n\n\n

      Limitations

      \n
        \n
      1. \nCurrently, weave.blitz handles all standard mathematic \noperators except for the ** power operator. The built-in trigonmetric, log, \nfloor/ceil, and fabs functions might work (but haven't been tested). It also \nhandles all types of array indexing supported by the Numeric module. \n

        \nweave.blitz does not currently support operations that use \narray broadcasting, nor have any of the special purpose functions in Numeric \nsuch as take, compress, etc. been implemented. Note that there are no obvious \nreasons why most of this functionality cannot be added to scipy.weave, so it \nwill likely trickle into future versions. Using slice() objects \ndirectly instead of start:stop:step is also not supported.\n

        2. \n
      2. \nCurrently Python only works on expressions that include assignment such as\n \n 
        \n    >>> result = b + c + d\n
        \n\nThis means that the result array must exist before calling \nweave.blitz. Future versions will allow the following:\n\n 
        \n    >>> result = weave.blitz_eval(\"b + c + d\")\n
        \n
        3. \n
      3. \nweave.blitz works best when algorithms can be expressed in a \n\"vectorized\" form. Algorithms that have a large number of if/thens and other \nconditions are better hand written in C or Fortran. Further, the restrictions \nimposed by requiring vectorized expressions sometimes preclude the use of more \nefficient data structures or algorithms. For maximum speed in these cases, \nhand-coded C or Fortran code is the only way to go.\n
        4. \n
      4. \nOne other point deserves mention lest people be confused. \nweave.blitz is not a general purpose Python->C compiler. It \nonly works for expressions that contain Numeric arrays and/or \nPython scalar values. This focused scope concentrates effort on the \ncompuationally intensive regions of the program and sidesteps the difficult \nissues associated with a general purpose Python->C compiler.\n
        5. \n
      \n\n\n

      Numeric efficiency issues: What compilation buys you

      \n\nSome might wonder why compiling Numeric expressions to C++ is beneficial since \noperations on Numeric array operations are already executed within C loops. \nThe problem is that anything other than the simplest expression are executed in \nless than optimal fashion. Consider the following Numeric expression:\n\n 
      \n    a = 1.2 * b + c * d\n
      \n \nWhen Numeric calculates the value for the 2d array, a, it does \nthe following steps:\n\n 
      \n    temp1 = 1.2 * b\n    temp2 = c * d\n    a = temp1 + temp2\n
      \n \nTwo things to note. Since c is an (perhaps large) array, a large \ntemporary array must be created to store the results of 1.2 * b. \nThe same is true for temp2. Allocation is slow. The second thing \nis that we have 3 loops executing, one to calculate temp1, one for \ntemp2 and one for adding them up. A C loop for the same problem \nmight look like:\n\n 
      \n    for(int i = 0; i < M; i++)\n        for(int j = 0; j < N; j++)\n            a[i,j] = 1.2 * b[i,j] + c[i,j] * d[i,j]\n
      \n \nHere, the 3 loops have been fused into a single loop and there is no longer\na need for a temporary array. This provides a significant speed improvement\nover the above example (write me and tell me what you get). \n

      \nSo, converting Numeric expressions into C/C++ loops that fuse the loops and \neliminate temporary arrays can provide big gains. The goal then,is to convert \nNumeric expression to C/C++ loops, compile them in an extension module, and \nthen call the compiled extension function. The good news is that there is an \nobvious correspondence between the Numeric expression above and the C loop. The \nbad news is that Numeric is generally much more powerful than this simple \nexample illustrates and handling all possible indexing possibilities results in \nloops that are less than straight forward to write. (take a peak in Numeric for \nconfirmation). Luckily, there are several available tools that simplify the \nprocess.\n\n\n

      The Tools

      \n\nweave.blitz relies heavily on several remarkable tools. On the \nPython side, the main facilitators are Jermey Hylton's parser module and Jim \nHuginin's Numeric module. On the compiled language side, Todd Veldhuizen's \nblitz++ array library, written in C++ (shhhh. don't tell David Beazley), does \nthe heavy lifting. Don't assume that, because it's C++, it's much slower than C \nor Fortran. Blitz++ uses a jaw dropping array of template techniques \n(metaprogramming, template expression, etc) to convert innocent looking and \nreadable C++ expressions into to code that usually executes within a few \npercentage points of Fortran code for the same problem. This is good. \nUnfortunately all the template raz-ma-taz is very expensive to compile, so the \n200 line extension modules often take 2 or more minutes to compile. This isn't so \ngood. weave.blitz works to minimize this issue by remembering \nwhere compiled modules live and reusing them instead of re-compiling every time \na program is re-run.\n\n\n

      Parser

      \nTearing Numeric expressions apart, examining the pieces, and then rebuilding \nthem as C++ (blitz) expressions requires a parser of some sort. I can imagine \nsomeone attacking this problem with regular expressions, but it'd likely be \nugly and fragile. Amazingly, Python solves this problem for us. It actually \nexposes its parsing engine to the world through the parser module. \nThe following fragment creates an Abstract Syntax Tree (AST) object for the \nexpression and then converts to a (rather unpleasant looking) deeply nested list \nrepresentation of the tree. \n \n 
      \n    >>> import parser\n    >>> import scipy.weave.misc\n    >>> ast = parser.suite(\"a = b * c + d\")\n    >>> ast_list = ast.tolist()\n    >>> sym_list = scipy.weave.misc.translate_symbols(ast_list)\n    >>> pprint.pprint(sym_list)\n    ['file_input',\n     ['stmt',\n      ['simple_stmt',\n       ['small_stmt',\n        ['expr_stmt',\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'a']]]]]]]]]]]]]]],\n         ['EQUAL', '='],\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'b']]]],\n                    ['STAR', '*'],\n                    ['factor', ['power', ['atom', ['NAME', 'c']]]]],\n                   ['PLUS', '+'],\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'd']]]]]]]]]]]]]]]]],\n       ['NEWLINE', '']]],\n     ['ENDMARKER', '']]\n
      \n\nDespite its looks, with some tools developed by Jermey H., its possible\nto search these trees for specific patterns (sub-trees), extract the \nsub-tree, manipulate them converting python specific code fragments\nto blitz code fragments, and then re-insert it in the parse tree. The parser\nmodule documentation has some details on how to do this. Traversing the \nnew blitzified tree, writing out the terminal symbols as you go, creates\nour new blitz++ expression string.\n\n \n

      Blitz and Numeric

      \nThe other nice discovery in the project is that the data structure used\nfor Numeric arrays and blitz arrays is nearly identical. Numeric stores\n\"strides\" as byte offsets and blitz stores them as element offsets, but\nother than that, they are the same. Further, most of the concept and\ncapabilities of the two libraries are remarkably similar. It is satisfying \nthat two completely different implementations solved the problem with \nsimilar basic architectures. It is also fortitous. The work involved in \nconverting Numeric expressions to blitz expressions was greatly diminished.\nAs an example, consider the code for slicing an array in Python with a\nstride:\n\n 
      \n    >>> a = b[0:4:2] + c\n    >>> a\n    [0,2,4]\n
      \n\n\nIn Blitz it is as follows:\n\n 
      \n    Array<2,int> b(10);\n    Array<2,int> c(3);\n    // ...\n    Array<2,int> a = b(Range(0,3,2)) + c;\n
      \n\n\nHere the range object works exactly like Python slice objects with the exception\nthat the top index (3) is inclusive where as Python's (4) is exclusive. Other \ndifferences include the type declaraions in C++ and parentheses instead of \nbrackets for indexing arrays. Currently, weave.blitz handles the \ninclusive/exclusive issue by subtracting one from upper indices during the\ntranslation. An alternative that is likely more robust/maintainable in the \nlong run, is to write a PyRange class that behaves like Python's range. \nThis is likely very easy.\n

      \nThe stock blitz also doesn't handle negative indices in ranges. The current \nimplementation of the blitz() has a partial solution to this \nproblem. It calculates and index that starts with a '-' sign by subtracting it \nfrom the maximum index in the array so that:\n\n 

      \n                    upper index limit\n                        /-----\\\n    b[:-1] -> b(Range(0,Nb[0]-1-1))\n
      \n\nThis approach fails, however, when the top index is calculated from other \nvalues. In the following scenario, if i+j evaluates to a negative \nvalue, the compiled code will produce incorrect results and could even core-\ndump. Right now, all calculated indices are assumed to be positive.\n \n 
      \n    b[:i-j] -> b(Range(0,i+j))\n
      \n\nA solution is to calculate all indices up front using if/then to handle the\n+/- cases. This is a little work and results in more code, so it hasn't been\ndone. I'm holding out to see if blitz++ can be modified to handle negative\nindexing, but haven't looked into how much effort is involved yet. While it \nneeds fixin', I don't think there is a ton of code where this is an issue.\n

      \nThe actual translation of the Python expressions to blitz expressions is \ncurrently a two part process. First, all x:y:z slicing expression are removed\nfrom the AST, converted to slice(x,y,z) and re-inserted into the tree. Any\nmath needed on these expressions (subtracting from the \nmaximum index, etc.) are also preformed here. _beg and _end are used as special\nvariables that are defined as blitz::fromBegin and blitz::toEnd.\n\n 

      \n    a[i+j:i+j+1,:] = b[2:3,:] \n
      \n\nbecomes a more verbose:\n \n 
      \n    a[slice(i+j,i+j+1),slice(_beg,_end)] = b[slice(2,3),slice(_beg,_end)]\n
      \n \nThe second part does a simple string search/replace to convert to a blitz \nexpression with the following translations:\n\n 
      \n    slice(_beg,_end) -> _all  # not strictly needed, but cuts down on code.\n    slice            -> blitz::Range\n    [                -> (\n    ]                -> )\n    _stp             -> 1\n
      \n\n_all is defined in the compiled function as \nblitz::Range.all(). These translations could of course happen \ndirectly in the syntax tree. But the string replacement is slightly easier. \nNote that name spaces are maintained in the C++ code to lessen the likelyhood \nof name clashes. Currently no effort is made to detect name clashes. A good \nrule of thumb is don't use values that start with '_' or 'py_' in compiled \nexpressions and you'll be fine.\n\n \n

      Type definitions and coersion

      \n\nSo far we've glossed over the dynamic vs. static typing issue between Python \nand C++. In Python, the type of value that a variable holds can change\nthrough the course of program execution. C/C++, on the other hand, forces you\nto declare the type of value a variables will hold prior at compile time.\nweave.blitz handles this issue by examining the types of the\nvariables in the expression being executed, and compiling a function for those\nexplicit types. For example:\n\n 
      \n    a = ones((5,5),Float32)\n    b = ones((5,5),Float32)\n    weave.blitz(\"a = a + b\")\n
      \n\nWhen compiling this expression to C++, weave.blitz sees that the\nvalues for a and b in the local scope have type Float32, or 'float'\non a 32 bit architecture. As a result, it compiles the function using \nthe float type (no attempt has been made to deal with 64 bit issues).\nIt also goes one step further. If all arrays have the same type, a templated\nversion of the function is made and instantiated for float, double, \ncomplex, and complex arrays. Note: This feature has been \nremoved from the current version of the code. Each version will be compiled\nseparately \n

      \nWhat happens if you call a compiled function with array types that are \ndifferent than the ones for which it was originally compiled? No biggie, you'll \njust have to wait on it to compile a new version for your new types. This \ndoesn't overwrite the old functions, as they are still accessible. See the \ncatalog section in the inline() documentation to see how this is handled. \nSuffice to say, the mechanism is transparent to the user and behaves \nlike dynamic typing with the occasional wait for compiling newly typed \nfunctions.\n

      \nWhen working with combined scalar/array operations, the type of the array is \nalways used. This is similar to the savespace flag that was recently \nadded to Numeric. This prevents issues with the following expression perhaps \nunexpectedly being calculated at a higher (more expensive) precision that can \noccur in Python:\n\n 

      \n    >>> a = array((1,2,3),typecode = Float32)\n    >>> b = a * 2.1 # results in b being a Float64 array.\n
      \n \nIn this example, \n\n 
      \n    >>> a = ones((5,5),Float32)\n    >>> b = ones((5,5),Float32)\n    >>> weave.blitz(\"b = a * 2.1\")\n
      \n \nthe 2.1 is cast down to a float before carrying out \nthe operation. If you really want to force the calculation to be a \ndouble, define a and b as \ndouble arrays.\n

      \nOne other point of note. Currently, you must include both the right hand side \nand left hand side (assignment side) of your equation in the compiled \nexpression. Also, the array being assigned to must be created prior to calling \nweave.blitz. I'm pretty sure this is easily changed so that a \ncompiled_eval expression can be defined, but no effort has been made to \nallocate new arrays (and decern their type) on the fly.\n\n \n

      Cataloging Compiled Functions

      \n\nSee the Cataloging functions section in the \nweave.inline() documentation.\n\n \n

      Checking Array Sizes

      \n\nSurprisingly, one of the big initial problems with compiled code was making\nsure all the arrays in an operation were of compatible type. The following\ncase, is of course, trivially easy:\n\n 
      \n    a = b + c\n
      \n \nIt only requires that arrays a, b, and c \nhave the same shape. However, expressions like:\n\n 
      \n    a[i+j:i+j+1,:] = b[2:3,:] + c\n
      \n\nare not so trivial. Since slicing is involved, the size of the slices, not the \ninput arrays must be checked. Broadcasting complicates things further because \narrays and slices with different dimensions and shapes may be compatible for \nmath operations (broadcasting isn't yet supported by \nweave.blitz). Reductions have a similar effect as their \nresults are different shapes than their input operand. The binary operators in \nNumeric compare the shapes of their two operands just before they operate on \nthem. This is possible because Numeric treats each operation independently. \nThe intermediate (temporary) arrays created during sub-operations in an \nexpression are tested for the correct shape before they are combined by another \noperation. Because weave.blitz fuses all operations into a \nsingle loop, this isn't possible. The shape comparisons must be done and \nguaranteed compatible before evaluating the expression.\n

      \nThe solution chosen converts input arrays to \"dummy arrays\" that only represent \nthe dimensions of the arrays, not the data. Binary operations on dummy arrays \ncheck that input array sizes are comptible and return a dummy array with the \nsize correct size. Evaluating an expression of dummy arrays traces the \nchanging array sizes through all operations and fails if incompatible array \nsizes are ever found. \n

      \nThe machinery for this is housed in weave.size_check. It \nbasically involves writing a new class (dummy array) and overloading it math \noperators to calculate the new sizes correctly. All the code is in Python and \nthere is a fair amount of logic (mainly to handle indexing and slicing) so the \noperation does impose some overhead. For large arrays (ie. 50x50x50), the \noverhead is negligible compared to evaluating the actual expression. For small \narrays (ie. 16x16), the overhead imposed for checking the shapes with this \nmethod can cause the weave.blitz to be slower than evaluating \nthe expression in Python. \n

      \nWhat can be done to reduce the overhead? (1) The size checking code could be \nmoved into C. This would likely remove most of the overhead penalty compared \nto Numeric (although there is also some calling overhead), but no effort has \nbeen made to do this. (2) You can also call weave.blitz with\ncheck_size=0 and the size checking isn't done. However, if the \nsizes aren't compatible, it can cause a core-dump. So, foregoing size_checking\nisn't advisable until your code is well debugged.\n\n \n

      Creating the Extension Module

      \n\nweave.blitz uses the same machinery as \nweave.inline to build the extension module. The only difference\nis the code included in the function is automatically generated from the\nNumeric array expression instead of supplied by the user.\n\n\n

      Extension Modules

      \nweave.inline and weave.blitz are high level tools\nthat generate extension modules automatically. Under the covers, they use several\nclasses from weave.ext_tools to help generate the extension module.\nThe main two classes are ext_module and ext_function (I'd\nlike to add ext_class and ext_method also). These classes\nsimplify the process of generating extension modules by handling most of the \"boiler\nplate\" code automatically.\n\n\nNote: inline actually sub-classes weave.ext_tools.ext_function \nto generate slightly different code than the standard ext_function.\nThe main difference is that the standard class converts function arguments to\nC types, while inline always has two arguments, the local and global dicts, and\nthe grabs the variables that need to be convereted to C from these.\n\n\n\n

      A Simple Example

      \nThe following simple example demonstrates how to build an extension module within\na Python function:\n\n 
      \n    # examples/increment_example.py\n    from weave import ext_tools\n    \n    def build_increment_ext():\n        \"\"\" Build a simple extension with functions that increment numbers.\n            The extension will be built in the local directory.\n        \"\"\"        \n        mod = ext_tools.ext_module('increment_ext')\n    \n        a = 1 # effectively a type declaration for 'a' in the \n              # following functions.\n    \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n        mod.add_function(func)\n        \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+2));\"    \n        func = ext_tools.ext_function('increment_by_2',ext_code,['a'])\n        mod.add_function(func)\n                \n        mod.compile()\n
      \n\n\nThe function build_increment_ext() creates an extension module \nnamed increment_ext and compiles it to a shared library (.so or \n.pyd) that can be loaded into Python.. increment_ext contains two \nfunctions, increment and increment_by_2. \n\nThe first line of build_increment_ext(),\n\n 
      \n        mod = ext_tools.ext_module('increment_ext') \n
      \n\ncreates an ext_module instance that is ready to have \next_function instances added to it. ext_function \ninstances are created much with a calling convention similar to \nweave.inline(). The most common call includes a C/C++ code \nsnippet and a list of the arguments for the function. The following\n\n 
      \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n
      \n \ncreates a C/C++ extension function that is equivalent to the following Python\nfunction:\n\n 
      \n        def increment(a):\n            return a + 1\n
      \n\nA second method is also added to the module and then,\n\n 
      \n        mod.compile()\n
      \n\nis called to build the extension module. By default, the module is created\nin the current working directory.\n\nThis example is available in the examples/increment_example.py file\nfound in the weave directory. At the bottom of the file in the\nmodule's \"main\" program, an attempt to import increment_ext without\nbuilding it is made. If this fails (the module doesn't exist in the PYTHONPATH), \nthe module is built by calling build_increment_ext(). This approach\nonly takes the time consuming ( a few seconds for this example) process of building\nthe module if it hasn't been built before.\n\n 
      \n    if __name__ == \"__main__\":\n        try:\n            import increment_ext\n        except ImportError:\n            build_increment_ext()\n            import increment_ext\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
      \n\n\nNote: If we were willing to always pay the penalty of building the C++ code for \na module, we could store the md5 checksum of the C++ code along with some \ninformation about the compiler, platform, etc. Then, \next_module.compile() could try importing the module before it actually\ncompiles it, check the md5 checksum and other meta-data in the imported module\nwith the meta-data of the code it just produced and only compile the code if\nthe module didn't exist or the meta-data didn't match. This would reduce the\nabove code to:\n\n 
      \n    if __name__ == \"__main__\":\n        build_increment_ext()\n\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
      \n\nNote: There would always be the overhead of building the C++ code, but it would only actually compile the code once. You pay a little in overhead and get cleaner\n\"import\" code. Needs some thought.\n\n

      \n\nIf you run increment_example.py from the command line, you get\nthe following:\n\n 

      \n    [eric@n0]$ python increment_example.py\n    a, a+1: 1 2\n    a, a+2: 1 3\n
      \n\nIf the module didn't exist before it was run, the module is created. If it did\nexist, it is just imported and used.\n\n\n

      Fibonacci Example

      \nexamples/fibonacci.py provides a little more complex example of \nhow to use ext_tools. Fibonacci numbers are a series of numbers \nwhere each number in the series is the sum of the previous two: 1, 1, 2, 3, 5, \n8, etc. Here, the first two numbers in the series are taken to be 1. One \napproach to calculating Fibonacci numbers uses recursive function calls. In \nPython, it might be written as:\n\n 
      \n    def fib(a):\n        if a <= 2:\n            return 1\n        else:\n            return fib(a-2) + fib(a-1)\n
      \n\nIn C, the same function would look something like this:\n\n 
      \n     int fib(int a)\n     {                   \n         if(a <= 2)\n             return 1;\n         else\n             return fib(a-2) + fib(a-1);  \n     }                      \n
      \n\nRecursion is much faster in C than in Python, so it would be beneficial\nto use the C version for fibonacci number calculations instead of the\nPython version. We need an extension function that calls this C function\nto do this. This is possible by including the above code snippet as \n\"support code\" and then calling it from the extension function. Support \ncode snippets (usually structure definitions, helper functions and the like)\nare inserted into the extension module C/C++ file before the extension\nfunction code. Here is how to build the C version of the fibonacci number\ngenerator:\n\n 
      \ndef build_fibonacci():\n    \"\"\" Builds an extension module with fibonacci calculators.\n    \"\"\"\n    mod = ext_tools.ext_module('fibonacci_ext')\n    a = 1 # this is effectively a type declaration\n    \n    # recursive fibonacci in C \n    fib_code = \"\"\"\n                   int fib1(int a)\n                   {                   \n                       if(a <= 2)\n                           return 1;\n                       else\n                           return fib1(a-2) + fib1(a-1);  \n                   }                         \n               \"\"\"\n    ext_code = \"\"\"\n                   int val = fib1(a);\n                   return_val = Py::new_reference_to(Py::Int(val));\n               \"\"\"    \n    fib = ext_tools.ext_function('fib',ext_code,['a'])\n    fib.customize.add_support_code(fib_code)\n    mod.add_function(fib)\n\n    mod.compile()\n\n
      \n\nXXX More about custom_info, and what xxx_info instances are good for.\n\n

      \n\nNote: recursion is not the fastest way to calculate fibonacci numbers, but this \napproach serves nicely for this example.\n\n

      \n\n

      Customizing Type Conversions -- Type Factories

      \nnot written\n\n

      Things I wish weave did

      \n\nIt is possible to get name clashes if you uses a variable name that is already defined\nin a header automatically included (such as stdio.h) For instance, if you\ntry to pass in a variable named stdout, you'll get a cryptic error report\ndue to the fact that stdio.h also defines the name. weave\nshould probably try and handle this in some way.\n\nOther things...", "methods": [], "methods_before": [], "changed_methods": [], "nloc": null, "complexity": null, "token_count": null, "diff_parsed": { "added": [ "The weave package provides tools for including C/C++ code within", "in Python code. This offers both another level of optimization to those who need", "for fast execution. blitz() was the original reason", "(mingw32 2.95.2 and 2.95.3-6). All tests also pass on Linux (RH 7.1", "with gcc 2.96), and I've had reports that it works on Debian also (thanks", "Pearu).", "extension modules pretty easy. However, if you're wrapping a gaggle of legacy", "inline(), but, for wrapping legacy code, it is more flexible to", "specify things the other way around -- that is how C types map to Python types.", "This weave does not do. I guess it would be possible to build", "such a tool on top of weave, but with good tools like SWIG around,", "I'm not sure the effort produces any new capabilities. Things like function", "overloading are probably easily implemented in weave and it might", "be easier to mix Python/C code in function calls, but nothing beyond this comes", "to mind. So, if you're developing new extension modules or optimizing Python", "functions in C, weave.ext_tools() might be the tool", "for you. If you're wrapping legacy code, stick with SWIG.", " return inline_tools.inline(code)", "weave.inline(\"\").", " >>> weave.inline('printf(\"hello\\\\n\");')" ], "deleted": [ "The weave package allows the inclusion of C/C++ within", "Python code. This offers both another level of optimization to those who need", "for fast execution. This was the original functionality for which", "(mingw32 2.95.2 and 2.95.3-6). All tests also seem to pass on Linux (RH 7.1", "with gcc 2.96).", "extension modules pretty easy. However, If you're wrapping a gaggle of legacy", "inline(), but, for wrapping legacy code, it is generally better to", "specify things the other way around -- that is how C types map to", "Python types. This weave does not do. I guess it would be", "possible to build such a tool on top of weave, but with good", "tools like SWIG around, I'm not sure the effort produces any new capabilities.", "Things like function overloading are probably easily implemented in", "weave and it might be easier to mix Python/C code in function", "calls, but nothing beyond this comes to mind. So, if you're developing new", "extension modules, or just want to optimize a few functions in C,", "weave might be the tool for you. If you're wrapping legacy code,", "stick with SWIG.", " return inline_tools.inline(code,[])", "weave.inline(\"\",[]).", " >>> weave.inline('printf(\"hello\\\\n\");',[])" ] } }, { "old_path": "weave/tests/test_blitz_tools.py", "new_path": "weave/tests/test_blitz_tools.py", "filename": "test_blitz_tools.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -193,7 +193,7 @@ def remove_test_files():\n \n def setup_test_location():\n import tempfile\n- pth = os.path.join(tempfile.tempdir,'test_files')\n+ pth = os.path.join(tempfile.gettempdir(),'test_files')\n if not os.path.exists(pth):\n os.mkdir(pth)\n #sys.path.insert(0,pth) \n@@ -202,7 +202,7 @@ def setup_test_location():\n def teardown_test_location():\n pass\n #import tempfile \n- #pth = os.path.join(tempfile.tempdir,'test_files')\n+ #pth = os.path.join(tempfile.gettempdir(),'test_files')\n #if sys.path[0] == pth:\n # sys.path = sys.path[1:]\n #return pth\n", "added_lines": 2, "deleted_lines": 2, "source_code": "import unittest\nfrom Numeric import *\nfrom fastumath import *\nimport RandomArray\nimport os\nimport time\n\nfrom scipy_distutils.misc_util import add_grandparent_to_path,restore_path\nfrom scipy_distutils.misc_util import add_local_to_path\n\nadd_grandparent_to_path(__name__)\nimport blitz_tools\nfrom ast_tools import *\nfrom weave_test_utils import *\nrestore_path()\n\nadd_local_to_path(__name__)\nimport test_scalar_spec\nrestore_path()\n\nclass test_ast_to_blitz_expr(unittest.TestCase):\n\n def generic_test(self,expr,desired):\n import parser\n ast = parser.suite(expr)\n ast_list = ast.tolist()\n actual = blitz_tools.ast_to_blitz_expr(ast_list)\n actual = remove_whitespace(actual)\n desired = remove_whitespace(desired)\n print_assert_equal(expr,actual,desired)\n\n def check_simple_expr(self):\n \"\"\"convert simple expr to blitz\n \n a[:1:2] = b[:1+i+2:]\n \"\"\"\n expr = \"a[:1:2] = b[:1+i+2:]\" \n desired = \"a(blitz::Range(_beg,1-1,2))=\"\\\n \"b(blitz::Range(_beg,1+i+2-1));\"\n self.generic_test(expr,desired)\n\n def check_fdtd_expr(self):\n \"\"\" convert fdtd equation to blitz.\n ex[:,1:,1:] = ca_x[:,1:,1:] * ex[:,1:,1:] \n + cb_y_x[:,1:,1:] * (hz[:,1:,1:] - hz[:,:-1,:])\n - cb_z_x[:,1:,1:] * (hy[:,1:,1:] - hy[:,1:,:-1]);\n Note: This really should have \"\\\" at the end of each line\n to indicate continuation. \n \"\"\"\n expr = \"ex[:,1:,1:] = ca_x[:,1:,1:] * ex[:,1:,1:]\" \\\n \"+ cb_y_x[:,1:,1:] * (hz[:,1:,1:] - hz[:,:-1,:])\"\\\n \"- cb_z_x[:,1:,1:] * (hy[:,1:,1:] - hy[:,1:,:-1])\" \n desired = 'ex(_all,blitz::Range(1,_end),blitz::Range(1,_end))='\\\n ' ca_x(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n ' *ex(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '+cb_y_x(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '*(hz(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n ' -hz(_all,blitz::Range(_beg,_Nhz(1)-1-1),_all))'\\\n ' -cb_z_x(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '*(hy(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '-hy(_all,blitz::Range(1,_end),blitz::Range(_beg,_Nhy(2)-1-1)));'\n self.generic_test(expr,desired)\n\nclass test_blitz(unittest.TestCase):\n \"\"\"* These are long running tests...\n \n I'd like to benchmark these things somehow.\n *\"\"\"\n def generic_test(self,expr,arg_dict,type,size):\n mod_location = setup_test_location()\n clean_result = array(arg_dict['result'],copy=1)\n t1 = time.time()\n exec expr in globals(),arg_dict\n t2 = time.time()\n standard = t2 - t1\n desired = arg_dict['result']\n arg_dict['result'] = clean_result\n t1 = time.time()\n old_env = os.environ.get('PYTHONCOMPILED','')\n os.environ['PYTHONCOMPILED'] = mod_location\n blitz_tools.blitz(expr,arg_dict,{},verbose=0)\n os.environ['PYTHONCOMPILED'] = old_env\n t2 = time.time()\n compiled = t2 - t1\n actual = arg_dict['result']\n # this really should give more info...\n try:\n # this isn't very stringent. Need to tighten this up and\n # learn where failures are occuring.\n assert(allclose(abs(actual.flat),abs(desired.flat),1e-4,1e-6))\n except:\n diff = actual-desired\n print diff[:4,:4]\n print diff[:4,-4:]\n print diff[-4:,:4]\n print diff[-4:,-4:]\n print sum(abs(diff.flat)) \n teardown_test_location()\n raise AssertionError \n teardown_test_location() \n return standard,compiled\n \n def generic_2d(self,expr):\n \"\"\" The complex testing is pretty lame...\n \"\"\"\n import parser\n ast = parser.suite(expr)\n arg_list = harvest_variables(ast.tolist())\n #print arg_list\n all_types = [Float32,Float64,Complex32,Complex64]\n all_sizes = [(10,10), (50,50), (100,100), (500,500), (1000,1000)]\n print '\\nExpression:', expr\n for typ in all_types:\n for size in all_sizes:\n result = zeros(size,typ)\n arg_dict = {}\n for arg in arg_list:\n arg_dict[arg] = RandomArray.normal(0,1,size).astype(typ)\n arg_dict[arg].savespace(1)\n # set imag part of complex values to non-zero value\n try: arg_dict[arg].imag = arg_dict[arg].real\n except: pass \n print 'Run:', size,typ\n standard,compiled = self.generic_test(expr,arg_dict,type,size)\n try:\n speed_up = standard/compiled\n except:\n speed_up = -1.\n print \"1st run(Numeric,compiled,speed up): %3.4f, %3.4f, \" \\\n \"%3.4f\" % (standard,compiled,speed_up) \n standard,compiled = self.generic_test(expr,arg_dict,type,size)\n try:\n speed_up = standard/compiled\n except:\n speed_up = -1. \n print \"2nd run(Numeric,compiled,speed up): %3.4f, %3.4f, \" \\\n \"%3.4f\" % (standard,compiled,speed_up) \n #def check_simple_2d(self):\n # \"\"\" result = a + b\"\"\" \n # expr = \"result = a + b\"\n # self.generic_2d(expr)\n def check_5point_avg_2d(self):\n \"\"\" result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\n + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n \"\"\" \n expr = \"result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n self.generic_2d(expr)\n \n def setUp(self):\n # try and get rid of any shared libraries that currently exist in \n # test directory. If some other program is using them though,\n # (another process is running exact same tests, this will to \n # fail clean-up stuff on NT) \n #remove_test_files()\n pass\n def tearDown(self):\n #print '\\n\\n\\ntearing down\\n\\n\\n'\n #remove_test_files()\n # Get rid of any files created by the test such as function catalogs\n # and compiled modules.\n # We'll assume any .pyd, .so files, .cpp, .def or .o \n # in the test directory is a test file. To make sure we\n # don't abliterate something desireable, we'll move it\n # to a file called 'test_trash'\n teardown_test_location()\n \ndef remove_test_files():\n import os,glob\n test_dir = compiler.compile_code.home_dir(__file__)\n trash = os.path.join(test_dir,'test_trash')\n files = glob.glob(os.path.join(test_dir,'*.so'))\n files += glob.glob(os.path.join(test_dir,'*.o'))\n files += glob.glob(os.path.join(test_dir,'*.a'))\n files += glob.glob(os.path.join(test_dir,'*.cpp'))\n files += glob.glob(os.path.join(test_dir,'*.pyd'))\n files += glob.glob(os.path.join(test_dir,'*.def'))\n files += glob.glob(os.path.join(test_dir,'*compiled_catalog*'))\n for i in files:\n try:\n #print i\n os.remove(i)\n except: \n pass \n #all this was to handle \"saving files in trash, but doesn't fly on NT\n #d,f=os.path.split(i)\n #trash_file = os.path.join(trash,f)\n #print 'tf:',trash_file\n #if os.path.exists(trash_file):\n # os.remove(trash_file)\n # print trash_file\n #os.renames(i,trash_file)\n\ndef setup_test_location():\n import tempfile\n pth = os.path.join(tempfile.gettempdir(),'test_files')\n if not os.path.exists(pth):\n os.mkdir(pth)\n #sys.path.insert(0,pth) \n return pth\n\ndef teardown_test_location():\n pass\n #import tempfile \n #pth = os.path.join(tempfile.gettempdir(),'test_files')\n #if sys.path[0] == pth:\n # sys.path = sys.path[1:]\n #return pth\n\ndef test_suite():\n suites = []\n suites.append( unittest.makeSuite(test_ast_to_blitz_expr,'check_') )\n suites.append( unittest.makeSuite(test_blitz,'check_') ) \n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\nif __name__ == \"__main__\":\n test()\n", "source_code_before": "import unittest\nfrom Numeric import *\nfrom fastumath import *\nimport RandomArray\nimport os\nimport time\n\nfrom scipy_distutils.misc_util import add_grandparent_to_path,restore_path\nfrom scipy_distutils.misc_util import add_local_to_path\n\nadd_grandparent_to_path(__name__)\nimport blitz_tools\nfrom ast_tools import *\nfrom weave_test_utils import *\nrestore_path()\n\nadd_local_to_path(__name__)\nimport test_scalar_spec\nrestore_path()\n\nclass test_ast_to_blitz_expr(unittest.TestCase):\n\n def generic_test(self,expr,desired):\n import parser\n ast = parser.suite(expr)\n ast_list = ast.tolist()\n actual = blitz_tools.ast_to_blitz_expr(ast_list)\n actual = remove_whitespace(actual)\n desired = remove_whitespace(desired)\n print_assert_equal(expr,actual,desired)\n\n def check_simple_expr(self):\n \"\"\"convert simple expr to blitz\n \n a[:1:2] = b[:1+i+2:]\n \"\"\"\n expr = \"a[:1:2] = b[:1+i+2:]\" \n desired = \"a(blitz::Range(_beg,1-1,2))=\"\\\n \"b(blitz::Range(_beg,1+i+2-1));\"\n self.generic_test(expr,desired)\n\n def check_fdtd_expr(self):\n \"\"\" convert fdtd equation to blitz.\n ex[:,1:,1:] = ca_x[:,1:,1:] * ex[:,1:,1:] \n + cb_y_x[:,1:,1:] * (hz[:,1:,1:] - hz[:,:-1,:])\n - cb_z_x[:,1:,1:] * (hy[:,1:,1:] - hy[:,1:,:-1]);\n Note: This really should have \"\\\" at the end of each line\n to indicate continuation. \n \"\"\"\n expr = \"ex[:,1:,1:] = ca_x[:,1:,1:] * ex[:,1:,1:]\" \\\n \"+ cb_y_x[:,1:,1:] * (hz[:,1:,1:] - hz[:,:-1,:])\"\\\n \"- cb_z_x[:,1:,1:] * (hy[:,1:,1:] - hy[:,1:,:-1])\" \n desired = 'ex(_all,blitz::Range(1,_end),blitz::Range(1,_end))='\\\n ' ca_x(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n ' *ex(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '+cb_y_x(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '*(hz(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n ' -hz(_all,blitz::Range(_beg,_Nhz(1)-1-1),_all))'\\\n ' -cb_z_x(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '*(hy(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '-hy(_all,blitz::Range(1,_end),blitz::Range(_beg,_Nhy(2)-1-1)));'\n self.generic_test(expr,desired)\n\nclass test_blitz(unittest.TestCase):\n \"\"\"* These are long running tests...\n \n I'd like to benchmark these things somehow.\n *\"\"\"\n def generic_test(self,expr,arg_dict,type,size):\n mod_location = setup_test_location()\n clean_result = array(arg_dict['result'],copy=1)\n t1 = time.time()\n exec expr in globals(),arg_dict\n t2 = time.time()\n standard = t2 - t1\n desired = arg_dict['result']\n arg_dict['result'] = clean_result\n t1 = time.time()\n old_env = os.environ.get('PYTHONCOMPILED','')\n os.environ['PYTHONCOMPILED'] = mod_location\n blitz_tools.blitz(expr,arg_dict,{},verbose=0)\n os.environ['PYTHONCOMPILED'] = old_env\n t2 = time.time()\n compiled = t2 - t1\n actual = arg_dict['result']\n # this really should give more info...\n try:\n # this isn't very stringent. Need to tighten this up and\n # learn where failures are occuring.\n assert(allclose(abs(actual.flat),abs(desired.flat),1e-4,1e-6))\n except:\n diff = actual-desired\n print diff[:4,:4]\n print diff[:4,-4:]\n print diff[-4:,:4]\n print diff[-4:,-4:]\n print sum(abs(diff.flat)) \n teardown_test_location()\n raise AssertionError \n teardown_test_location() \n return standard,compiled\n \n def generic_2d(self,expr):\n \"\"\" The complex testing is pretty lame...\n \"\"\"\n import parser\n ast = parser.suite(expr)\n arg_list = harvest_variables(ast.tolist())\n #print arg_list\n all_types = [Float32,Float64,Complex32,Complex64]\n all_sizes = [(10,10), (50,50), (100,100), (500,500), (1000,1000)]\n print '\\nExpression:', expr\n for typ in all_types:\n for size in all_sizes:\n result = zeros(size,typ)\n arg_dict = {}\n for arg in arg_list:\n arg_dict[arg] = RandomArray.normal(0,1,size).astype(typ)\n arg_dict[arg].savespace(1)\n # set imag part of complex values to non-zero value\n try: arg_dict[arg].imag = arg_dict[arg].real\n except: pass \n print 'Run:', size,typ\n standard,compiled = self.generic_test(expr,arg_dict,type,size)\n try:\n speed_up = standard/compiled\n except:\n speed_up = -1.\n print \"1st run(Numeric,compiled,speed up): %3.4f, %3.4f, \" \\\n \"%3.4f\" % (standard,compiled,speed_up) \n standard,compiled = self.generic_test(expr,arg_dict,type,size)\n try:\n speed_up = standard/compiled\n except:\n speed_up = -1. \n print \"2nd run(Numeric,compiled,speed up): %3.4f, %3.4f, \" \\\n \"%3.4f\" % (standard,compiled,speed_up) \n #def check_simple_2d(self):\n # \"\"\" result = a + b\"\"\" \n # expr = \"result = a + b\"\n # self.generic_2d(expr)\n def check_5point_avg_2d(self):\n \"\"\" result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\n + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n \"\"\" \n expr = \"result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n self.generic_2d(expr)\n \n def setUp(self):\n # try and get rid of any shared libraries that currently exist in \n # test directory. If some other program is using them though,\n # (another process is running exact same tests, this will to \n # fail clean-up stuff on NT) \n #remove_test_files()\n pass\n def tearDown(self):\n #print '\\n\\n\\ntearing down\\n\\n\\n'\n #remove_test_files()\n # Get rid of any files created by the test such as function catalogs\n # and compiled modules.\n # We'll assume any .pyd, .so files, .cpp, .def or .o \n # in the test directory is a test file. To make sure we\n # don't abliterate something desireable, we'll move it\n # to a file called 'test_trash'\n teardown_test_location()\n \ndef remove_test_files():\n import os,glob\n test_dir = compiler.compile_code.home_dir(__file__)\n trash = os.path.join(test_dir,'test_trash')\n files = glob.glob(os.path.join(test_dir,'*.so'))\n files += glob.glob(os.path.join(test_dir,'*.o'))\n files += glob.glob(os.path.join(test_dir,'*.a'))\n files += glob.glob(os.path.join(test_dir,'*.cpp'))\n files += glob.glob(os.path.join(test_dir,'*.pyd'))\n files += glob.glob(os.path.join(test_dir,'*.def'))\n files += glob.glob(os.path.join(test_dir,'*compiled_catalog*'))\n for i in files:\n try:\n #print i\n os.remove(i)\n except: \n pass \n #all this was to handle \"saving files in trash, but doesn't fly on NT\n #d,f=os.path.split(i)\n #trash_file = os.path.join(trash,f)\n #print 'tf:',trash_file\n #if os.path.exists(trash_file):\n # os.remove(trash_file)\n # print trash_file\n #os.renames(i,trash_file)\n\ndef setup_test_location():\n import tempfile\n pth = os.path.join(tempfile.tempdir,'test_files')\n if not os.path.exists(pth):\n os.mkdir(pth)\n #sys.path.insert(0,pth) \n return pth\n\ndef teardown_test_location():\n pass\n #import tempfile \n #pth = os.path.join(tempfile.tempdir,'test_files')\n #if sys.path[0] == pth:\n # sys.path = sys.path[1:]\n #return pth\n\ndef test_suite():\n suites = []\n suites.append( unittest.makeSuite(test_ast_to_blitz_expr,'check_') )\n suites.append( unittest.makeSuite(test_blitz,'check_') ) \n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\nif __name__ == \"__main__\":\n test()\n", "methods": [ { "name": "generic_test", "long_name": "generic_test( self , expr , desired )", "filename": "test_blitz_tools.py", "nloc": 8, "complexity": 1, "token_count": 54, "parameters": [ "self", "expr", "desired" ], "start_line": 23, "end_line": 30, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "check_simple_expr", "long_name": "check_simple_expr( self )", "filename": "test_blitz_tools.py", "nloc": 5, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 32, "end_line": 40, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "check_fdtd_expr", "long_name": "check_fdtd_expr( self )", "filename": "test_blitz_tools.py", "nloc": 14, "complexity": 1, "token_count": 40, "parameters": [ "self" ], "start_line": 42, "end_line": 62, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 21, "top_nesting_level": 1 }, { "name": "generic_test", "long_name": "generic_test( self , expr , arg_dict , type , size )", "filename": "test_blitz_tools.py", "nloc": 30, "complexity": 2, "token_count": 236, "parameters": [ "self", "expr", "arg_dict", "type", "size" ], "start_line": 69, "end_line": 101, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 33, "top_nesting_level": 1 }, { "name": "generic_2d", "long_name": "generic_2d( self , expr )", "filename": "test_blitz_tools.py", "nloc": 31, "complexity": 7, "token_count": 240, "parameters": [ "self", "expr" ], "start_line": 103, "end_line": 137, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 35, "top_nesting_level": 1 }, { "name": "check_5point_avg_2d", "long_name": "check_5point_avg_2d( self )", "filename": "test_blitz_tools.py", "nloc": 4, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 142, "end_line": 148, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "setUp", "long_name": "setUp( self )", "filename": "test_blitz_tools.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 150, "end_line": 156, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "tearDown", "long_name": "tearDown( self )", "filename": "test_blitz_tools.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 157, "end_line": 166, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "remove_test_files", "long_name": "remove_test_files( )", "filename": "test_blitz_tools.py", "nloc": 16, "complexity": 3, "token_count": 165, "parameters": [], "start_line": 168, "end_line": 184, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 0 }, { "name": "setup_test_location", "long_name": "setup_test_location( )", "filename": "test_blitz_tools.py", "nloc": 6, "complexity": 2, "token_count": 41, "parameters": [], "start_line": 194, "end_line": 200, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "teardown_test_location", "long_name": "teardown_test_location( )", "filename": "test_blitz_tools.py", "nloc": 2, "complexity": 1, "token_count": 5, "parameters": [], "start_line": 202, "end_line": 203, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_blitz_tools.py", "nloc": 6, "complexity": 1, "token_count": 44, "parameters": [], "start_line": 210, "end_line": 215, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_blitz_tools.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 217, "end_line": 221, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "methods_before": [ { "name": "generic_test", "long_name": "generic_test( self , expr , desired )", "filename": "test_blitz_tools.py", "nloc": 8, "complexity": 1, "token_count": 54, "parameters": [ "self", "expr", "desired" ], "start_line": 23, "end_line": 30, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "check_simple_expr", "long_name": "check_simple_expr( self )", "filename": "test_blitz_tools.py", "nloc": 5, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 32, "end_line": 40, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "check_fdtd_expr", "long_name": "check_fdtd_expr( self )", "filename": "test_blitz_tools.py", "nloc": 14, "complexity": 1, "token_count": 40, "parameters": [ "self" ], "start_line": 42, "end_line": 62, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 21, "top_nesting_level": 1 }, { "name": "generic_test", "long_name": "generic_test( self , expr , arg_dict , type , size )", "filename": "test_blitz_tools.py", "nloc": 30, "complexity": 2, "token_count": 236, "parameters": [ "self", "expr", "arg_dict", "type", "size" ], "start_line": 69, "end_line": 101, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 33, "top_nesting_level": 1 }, { "name": "generic_2d", "long_name": "generic_2d( self , expr )", "filename": "test_blitz_tools.py", "nloc": 31, "complexity": 7, "token_count": 240, "parameters": [ "self", "expr" ], "start_line": 103, "end_line": 137, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 35, "top_nesting_level": 1 }, { "name": "check_5point_avg_2d", "long_name": "check_5point_avg_2d( self )", "filename": "test_blitz_tools.py", "nloc": 4, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 142, "end_line": 148, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "setUp", "long_name": "setUp( self )", "filename": "test_blitz_tools.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 150, "end_line": 156, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "tearDown", "long_name": "tearDown( self )", "filename": "test_blitz_tools.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 157, "end_line": 166, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "remove_test_files", "long_name": "remove_test_files( )", "filename": "test_blitz_tools.py", "nloc": 16, "complexity": 3, "token_count": 165, "parameters": [], "start_line": 168, "end_line": 184, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 0 }, { "name": "setup_test_location", "long_name": "setup_test_location( )", "filename": "test_blitz_tools.py", "nloc": 6, "complexity": 2, "token_count": 39, "parameters": [], "start_line": 194, "end_line": 200, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "teardown_test_location", "long_name": "teardown_test_location( )", "filename": "test_blitz_tools.py", "nloc": 2, "complexity": 1, "token_count": 5, "parameters": [], "start_line": 202, "end_line": 203, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_blitz_tools.py", "nloc": 6, "complexity": 1, "token_count": 44, "parameters": [], "start_line": 210, "end_line": 215, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_blitz_tools.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 217, "end_line": 221, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "setup_test_location", "long_name": "setup_test_location( )", "filename": "test_blitz_tools.py", "nloc": 6, "complexity": 2, "token_count": 41, "parameters": [], "start_line": 194, "end_line": 200, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 } ], "nloc": 155, "complexity": 23, "token_count": 996, "diff_parsed": { "added": [ " pth = os.path.join(tempfile.gettempdir(),'test_files')", " #pth = os.path.join(tempfile.gettempdir(),'test_files')" ], "deleted": [ " pth = os.path.join(tempfile.tempdir,'test_files')", " #pth = os.path.join(tempfile.tempdir,'test_files')" ] } }, { "old_path": "weave/tests/test_scalar_spec.py", "new_path": "weave/tests/test_scalar_spec.py", "filename": "test_scalar_spec.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -284,7 +284,7 @@ class test_gcc_complex_specification(test_complex_specification):\n \n def setup_test_location():\n import tempfile\n- test_dir = os.path.join(tempfile.tempdir,'test_files')\n+ test_dir = os.path.join(tempfile.gettempdir(),'test_files')\n if not os.path.exists(test_dir):\n os.mkdir(test_dir)\n sys.path.insert(0,test_dir) \n@@ -292,7 +292,7 @@ def setup_test_location():\n \n def teardown_test_location():\n import tempfile\n- test_dir = os.path.join(tempfile.tempdir,'test_files')\n+ test_dir = os.path.join(tempfile.gettempdir(),'test_files')\n if sys.path[0] == test_dir:\n sys.path = sys.path[1:]\n return test_dir\n@@ -303,9 +303,9 @@ def test_suite():\n suites = []\n \n if msvc_exists():\n- #suites.append( unittest.makeSuite(test_msvc_int_specification,'check_'))\n- #suites.append( unittest.makeSuite(test_msvc_float_specification,'check_')) \n- #suites.append( unittest.makeSuite(test_msvc_complex_specification,'check_'))\n+ suites.append( unittest.makeSuite(test_msvc_int_specification,'check_'))\n+ suites.append( unittest.makeSuite(test_msvc_float_specification,'check_')) \n+ suites.append( unittest.makeSuite(test_msvc_complex_specification,'check_'))\n pass\n else: # unix\n suites.append( unittest.makeSuite(test_unix_int_specification,'check_'))\n@@ -313,8 +313,8 @@ def test_suite():\n suites.append( unittest.makeSuite(test_unix_complex_specification,'check_'))\n \n if gcc_exists(): \n- #suites.append( unittest.makeSuite(test_gcc_int_specification,'check_'))\n- #suites.append( unittest.makeSuite(test_gcc_float_specification,'check_')) \n+ suites.append( unittest.makeSuite(test_gcc_int_specification,'check_'))\n+ suites.append( unittest.makeSuite(test_gcc_float_specification,'check_')) \n suites.append( unittest.makeSuite(test_gcc_complex_specification,'check_'))\n \n total_suite = unittest.TestSuite(suites)\n", "added_lines": 7, "deleted_lines": 7, "source_code": "import unittest\nimport time\nimport os,sys\n\nfrom scipy_distutils.misc_util import add_grandparent_to_path, restore_path\n\nadd_grandparent_to_path(__name__)\nimport ext_tools\nfrom catalog import unique_file\nfrom build_tools import msvc_exists, gcc_exists\nimport scalar_spec\nrestore_path()\n\ndef unique_mod(d,file_name):\n f = os.path.basename(unique_file(d,file_name))\n m = os.path.splitext(f)[0]\n return m\n \ndef remove_whitespace(in_str):\n import string\n out = string.replace(in_str,\" \",\"\")\n out = string.replace(out,\"\\t\",\"\")\n out = string.replace(out,\"\\n\",\"\")\n return out\n \ndef print_assert_equal(test_string,actual,desired):\n \"\"\"this should probably be in scipy.scipy_test\n \"\"\"\n import pprint\n try:\n assert(actual == desired)\n except AssertionError:\n import cStringIO\n msg = cStringIO.StringIO()\n msg.write(test_string)\n msg.write(' failed\\nACTUAL: \\n')\n pprint.pprint(actual,msg)\n msg.write('DESIRED: \\n')\n pprint.pprint(desired,msg)\n raise AssertionError, msg.getvalue()\n\nclass test_int_specification(unittest.TestCase):\n compiler = '' \n def check_type_match_string(self):\n s = scalar_spec.int_specification()\n assert( not s.type_match('string') )\n def check_type_match_int(self):\n s = scalar_spec.int_specification() \n assert(s.type_match(5))\n def check_type_match_float(self):\n s = scalar_spec.int_specification() \n assert(not s.type_match(5.))\n def check_type_match_complex(self):\n s = scalar_spec.int_specification() \n assert(not s.type_match(5.+1j))\n def check_var_in(self):\n test_dir = setup_test_location()\n mod_name = 'int_var_in' + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1\n code = \"a=2;\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1\n test(b)\n try:\n b = 1.\n test(b)\n except TypeError:\n pass\n try:\n b = 'abc'\n test(b)\n except TypeError:\n pass\n teardown_test_location()\n \n def check_int_var_local(self):\n test_dir = setup_test_location()\n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1\n code = \"a=2;\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler= self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1\n q={}\n test(b,q)\n teardown_test_location()\n assert(q['a'] == 2)\n def check_int_return(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1\n code = \"\"\"\n a=a+2;\n return_val = Py::new_reference_to(Py::Int(a));\n \"\"\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1\n c = test(b)\n teardown_test_location()\n assert( c == 3)\n\nclass test_float_specification(unittest.TestCase): \n compiler = ''\n def check_type_match_string(self):\n s = scalar_spec.float_specification()\n assert( not s.type_match('string') )\n def check_type_match_int(self):\n s = scalar_spec.float_specification() \n assert(not s.type_match(5))\n def check_type_match_float(self):\n s = scalar_spec.float_specification() \n assert(s.type_match(5.))\n def check_type_match_complex(self):\n s = scalar_spec.float_specification() \n assert(not s.type_match(5.+1j))\n def check_float_var_in(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n\n a = 1.\n code = \"a=2.;\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1.\n test(b)\n try:\n b = 1.\n test(b)\n except TypeError:\n pass\n try:\n b = 'abc'\n test(b)\n except TypeError:\n pass\n teardown_test_location()\n def check_float_var_local(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1.\n code = \"a=2.;\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1.\n q={}\n test(b,q)\n teardown_test_location()\n assert(q['a'] == 2.)\n def check_float_return(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1.\n code = \"\"\"\n a=a+2.;\n return_val = Py::new_reference_to(Py::Float(a));\n \"\"\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1.\n c = test(b)\n teardown_test_location()\n assert( c == 3.)\n \nclass test_complex_specification(unittest.TestCase): \n compiler = ''\n def check_type_match_string(self):\n s = scalar_spec.complex_specification()\n assert( not s.type_match('string') )\n def check_type_match_int(self):\n s = scalar_spec.complex_specification() \n assert(not s.type_match(5))\n def check_type_match_float(self):\n s = scalar_spec.complex_specification() \n assert(not s.type_match(5.))\n def check_type_match_complex(self):\n s = scalar_spec.complex_specification() \n assert(s.type_match(5.+1j))\n def check_complex_var_in(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1.+1j\n code = \"a=std::complex(2.,2.);\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1.+1j\n test(b)\n try:\n b = 1.\n test(b)\n except TypeError:\n pass\n try:\n b = 'abc'\n test(b)\n except TypeError:\n pass\n teardown_test_location()\n def check_complex_var_local(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1.+1j\n code = \"a= a + std::complex(2.,2.);\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1.+1j\n q={}\n test(b,q)\n teardown_test_location() \n assert(q['a'] == 3.+3j)\n def check_complex_return(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1.+1j\n code = \"\"\"\n a= a + std::complex(2.,2.);\n return_val = Py::new_reference_to(Py::Complex(a.real(),a.imag()));\n \"\"\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1.+1j\n c = test(b)\n teardown_test_location() \n assert( c == 3.+3j)\n\nclass test_msvc_int_specification(test_int_specification): \n compiler = 'msvc'\nclass test_msvc_float_specification(test_float_specification): \n compiler = 'msvc'\nclass test_msvc_complex_specification(test_complex_specification): \n compiler = 'msvc'\n\nclass test_unix_int_specification(test_int_specification): \n compiler = ''\nclass test_unix_float_specification(test_float_specification): \n compiler = ''\nclass test_unix_complex_specification(test_complex_specification): \n compiler = ''\n\nclass test_gcc_int_specification(test_int_specification): \n compiler = 'gcc'\nclass test_gcc_float_specification(test_float_specification): \n compiler = 'gcc'\nclass test_gcc_complex_specification(test_complex_specification): \n compiler = 'gcc'\n \n\ndef setup_test_location():\n import tempfile\n test_dir = os.path.join(tempfile.gettempdir(),'test_files')\n if not os.path.exists(test_dir):\n os.mkdir(test_dir)\n sys.path.insert(0,test_dir) \n return test_dir\n\ndef teardown_test_location():\n import tempfile\n test_dir = os.path.join(tempfile.gettempdir(),'test_files')\n if sys.path[0] == test_dir:\n sys.path = sys.path[1:]\n return test_dir\n\ndef remove_file(name):\n test_dir = os.path.abspath(name)\ndef test_suite():\n suites = []\n\n if msvc_exists():\n suites.append( unittest.makeSuite(test_msvc_int_specification,'check_'))\n suites.append( unittest.makeSuite(test_msvc_float_specification,'check_')) \n suites.append( unittest.makeSuite(test_msvc_complex_specification,'check_'))\n pass\n else: # unix\n suites.append( unittest.makeSuite(test_unix_int_specification,'check_'))\n suites.append( unittest.makeSuite(test_unix_float_specification,'check_')) \n suites.append( unittest.makeSuite(test_unix_complex_specification,'check_'))\n \n if gcc_exists(): \n suites.append( unittest.makeSuite(test_gcc_int_specification,'check_'))\n suites.append( unittest.makeSuite(test_gcc_float_specification,'check_')) \n suites.append( unittest.makeSuite(test_gcc_complex_specification,'check_'))\n\n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\nif __name__ == \"__main__\":\n test()\n", "source_code_before": "import unittest\nimport time\nimport os,sys\n\nfrom scipy_distutils.misc_util import add_grandparent_to_path, restore_path\n\nadd_grandparent_to_path(__name__)\nimport ext_tools\nfrom catalog import unique_file\nfrom build_tools import msvc_exists, gcc_exists\nimport scalar_spec\nrestore_path()\n\ndef unique_mod(d,file_name):\n f = os.path.basename(unique_file(d,file_name))\n m = os.path.splitext(f)[0]\n return m\n \ndef remove_whitespace(in_str):\n import string\n out = string.replace(in_str,\" \",\"\")\n out = string.replace(out,\"\\t\",\"\")\n out = string.replace(out,\"\\n\",\"\")\n return out\n \ndef print_assert_equal(test_string,actual,desired):\n \"\"\"this should probably be in scipy.scipy_test\n \"\"\"\n import pprint\n try:\n assert(actual == desired)\n except AssertionError:\n import cStringIO\n msg = cStringIO.StringIO()\n msg.write(test_string)\n msg.write(' failed\\nACTUAL: \\n')\n pprint.pprint(actual,msg)\n msg.write('DESIRED: \\n')\n pprint.pprint(desired,msg)\n raise AssertionError, msg.getvalue()\n\nclass test_int_specification(unittest.TestCase):\n compiler = '' \n def check_type_match_string(self):\n s = scalar_spec.int_specification()\n assert( not s.type_match('string') )\n def check_type_match_int(self):\n s = scalar_spec.int_specification() \n assert(s.type_match(5))\n def check_type_match_float(self):\n s = scalar_spec.int_specification() \n assert(not s.type_match(5.))\n def check_type_match_complex(self):\n s = scalar_spec.int_specification() \n assert(not s.type_match(5.+1j))\n def check_var_in(self):\n test_dir = setup_test_location()\n mod_name = 'int_var_in' + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1\n code = \"a=2;\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1\n test(b)\n try:\n b = 1.\n test(b)\n except TypeError:\n pass\n try:\n b = 'abc'\n test(b)\n except TypeError:\n pass\n teardown_test_location()\n \n def check_int_var_local(self):\n test_dir = setup_test_location()\n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1\n code = \"a=2;\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler= self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1\n q={}\n test(b,q)\n teardown_test_location()\n assert(q['a'] == 2)\n def check_int_return(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1\n code = \"\"\"\n a=a+2;\n return_val = Py::new_reference_to(Py::Int(a));\n \"\"\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1\n c = test(b)\n teardown_test_location()\n assert( c == 3)\n\nclass test_float_specification(unittest.TestCase): \n compiler = ''\n def check_type_match_string(self):\n s = scalar_spec.float_specification()\n assert( not s.type_match('string') )\n def check_type_match_int(self):\n s = scalar_spec.float_specification() \n assert(not s.type_match(5))\n def check_type_match_float(self):\n s = scalar_spec.float_specification() \n assert(s.type_match(5.))\n def check_type_match_complex(self):\n s = scalar_spec.float_specification() \n assert(not s.type_match(5.+1j))\n def check_float_var_in(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n\n a = 1.\n code = \"a=2.;\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1.\n test(b)\n try:\n b = 1.\n test(b)\n except TypeError:\n pass\n try:\n b = 'abc'\n test(b)\n except TypeError:\n pass\n teardown_test_location()\n def check_float_var_local(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1.\n code = \"a=2.;\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1.\n q={}\n test(b,q)\n teardown_test_location()\n assert(q['a'] == 2.)\n def check_float_return(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1.\n code = \"\"\"\n a=a+2.;\n return_val = Py::new_reference_to(Py::Float(a));\n \"\"\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1.\n c = test(b)\n teardown_test_location()\n assert( c == 3.)\n \nclass test_complex_specification(unittest.TestCase): \n compiler = ''\n def check_type_match_string(self):\n s = scalar_spec.complex_specification()\n assert( not s.type_match('string') )\n def check_type_match_int(self):\n s = scalar_spec.complex_specification() \n assert(not s.type_match(5))\n def check_type_match_float(self):\n s = scalar_spec.complex_specification() \n assert(not s.type_match(5.))\n def check_type_match_complex(self):\n s = scalar_spec.complex_specification() \n assert(s.type_match(5.+1j))\n def check_complex_var_in(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1.+1j\n code = \"a=std::complex(2.,2.);\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1.+1j\n test(b)\n try:\n b = 1.\n test(b)\n except TypeError:\n pass\n try:\n b = 'abc'\n test(b)\n except TypeError:\n pass\n teardown_test_location()\n def check_complex_var_local(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1.+1j\n code = \"a= a + std::complex(2.,2.);\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1.+1j\n q={}\n test(b,q)\n teardown_test_location() \n assert(q['a'] == 3.+3j)\n def check_complex_return(self):\n test_dir = setup_test_location() \n mod_name = sys._getframe().f_code.co_name + self.compiler\n mod_name = unique_mod(test_dir,mod_name)\n mod = ext_tools.ext_module(mod_name)\n a = 1.+1j\n code = \"\"\"\n a= a + std::complex(2.,2.);\n return_val = Py::new_reference_to(Py::Complex(a.real(),a.imag()));\n \"\"\"\n test = ext_tools.ext_function('test',code,['a'])\n mod.add_function(test)\n mod.compile(location = test_dir, compiler = self.compiler)\n exec 'from ' + mod_name + ' import test'\n b=1.+1j\n c = test(b)\n teardown_test_location() \n assert( c == 3.+3j)\n\nclass test_msvc_int_specification(test_int_specification): \n compiler = 'msvc'\nclass test_msvc_float_specification(test_float_specification): \n compiler = 'msvc'\nclass test_msvc_complex_specification(test_complex_specification): \n compiler = 'msvc'\n\nclass test_unix_int_specification(test_int_specification): \n compiler = ''\nclass test_unix_float_specification(test_float_specification): \n compiler = ''\nclass test_unix_complex_specification(test_complex_specification): \n compiler = ''\n\nclass test_gcc_int_specification(test_int_specification): \n compiler = 'gcc'\nclass test_gcc_float_specification(test_float_specification): \n compiler = 'gcc'\nclass test_gcc_complex_specification(test_complex_specification): \n compiler = 'gcc'\n \n\ndef setup_test_location():\n import tempfile\n test_dir = os.path.join(tempfile.tempdir,'test_files')\n if not os.path.exists(test_dir):\n os.mkdir(test_dir)\n sys.path.insert(0,test_dir) \n return test_dir\n\ndef teardown_test_location():\n import tempfile\n test_dir = os.path.join(tempfile.tempdir,'test_files')\n if sys.path[0] == test_dir:\n sys.path = sys.path[1:]\n return test_dir\n\ndef remove_file(name):\n test_dir = os.path.abspath(name)\ndef test_suite():\n suites = []\n\n if msvc_exists():\n #suites.append( unittest.makeSuite(test_msvc_int_specification,'check_'))\n #suites.append( unittest.makeSuite(test_msvc_float_specification,'check_')) \n #suites.append( unittest.makeSuite(test_msvc_complex_specification,'check_'))\n pass\n else: # unix\n suites.append( unittest.makeSuite(test_unix_int_specification,'check_'))\n suites.append( unittest.makeSuite(test_unix_float_specification,'check_')) \n suites.append( unittest.makeSuite(test_unix_complex_specification,'check_'))\n \n if gcc_exists(): \n #suites.append( unittest.makeSuite(test_gcc_int_specification,'check_'))\n #suites.append( unittest.makeSuite(test_gcc_float_specification,'check_')) \n suites.append( unittest.makeSuite(test_gcc_complex_specification,'check_'))\n\n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\nif __name__ == \"__main__\":\n test()\n", "methods": [ { "name": "unique_mod", "long_name": "unique_mod( d , file_name )", "filename": "test_scalar_spec.py", "nloc": 4, "complexity": 1, "token_count": 37, "parameters": [ "d", "file_name" ], "start_line": 14, "end_line": 17, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 0 }, { "name": "remove_whitespace", "long_name": "remove_whitespace( in_str )", "filename": "test_scalar_spec.py", "nloc": 6, "complexity": 1, "token_count": 45, "parameters": [ "in_str" ], "start_line": 19, "end_line": 24, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 }, { "name": "print_assert_equal", "long_name": "print_assert_equal( test_string , actual , desired )", "filename": "test_scalar_spec.py", "nloc": 13, "complexity": 2, "token_count": 74, "parameters": [ "test_string", "actual", "desired" ], "start_line": 26, "end_line": 40, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "check_type_match_string", "long_name": "check_type_match_string( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 44, "end_line": 46, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_int", "long_name": "check_type_match_int( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 21, "parameters": [ "self" ], "start_line": 47, "end_line": 49, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_float", "long_name": "check_type_match_float( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 23, "parameters": [ "self" ], "start_line": 50, "end_line": 52, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_complex", "long_name": "check_type_match_complex( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 25, "parameters": [ "self" ], "start_line": 53, "end_line": 55, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_var_in", "long_name": "check_var_in( self )", "filename": "test_scalar_spec.py", "nloc": 24, "complexity": 3, "token_count": 116, "parameters": [ "self" ], "start_line": 56, "end_line": 79, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 24, "top_nesting_level": 1 }, { "name": "check_int_var_local", "long_name": "check_int_var_local( self )", "filename": "test_scalar_spec.py", "nloc": 16, "complexity": 1, "token_count": 112, "parameters": [ "self" ], "start_line": 81, "end_line": 96, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "check_int_return", "long_name": "check_int_return( self )", "filename": "test_scalar_spec.py", "nloc": 18, "complexity": 1, "token_count": 105, "parameters": [ "self" ], "start_line": 97, "end_line": 114, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 1 }, { "name": "check_type_match_string", "long_name": "check_type_match_string( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 118, "end_line": 120, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_int", "long_name": "check_type_match_int( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 121, "end_line": 123, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_float", "long_name": "check_type_match_float( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 124, "end_line": 126, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_complex", "long_name": "check_type_match_complex( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 25, "parameters": [ "self" ], "start_line": 127, "end_line": 129, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_float_var_in", "long_name": "check_float_var_in( self )", "filename": "test_scalar_spec.py", "nloc": 24, "complexity": 3, "token_count": 126, "parameters": [ "self" ], "start_line": 130, "end_line": 154, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 1 }, { "name": "check_float_var_local", "long_name": "check_float_var_local( self )", "filename": "test_scalar_spec.py", "nloc": 16, "complexity": 1, "token_count": 115, "parameters": [ "self" ], "start_line": 155, "end_line": 170, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "check_float_return", "long_name": "check_float_return( self )", "filename": "test_scalar_spec.py", "nloc": 18, "complexity": 1, "token_count": 108, "parameters": [ "self" ], "start_line": 171, "end_line": 188, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 1 }, { "name": "check_type_match_string", "long_name": "check_type_match_string( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 192, "end_line": 194, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_int", "long_name": "check_type_match_int( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 195, "end_line": 197, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_float", "long_name": "check_type_match_float( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 23, "parameters": [ "self" ], "start_line": 198, "end_line": 200, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_complex", "long_name": "check_type_match_complex( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 201, "end_line": 203, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_complex_var_in", "long_name": "check_complex_var_in( self )", "filename": "test_scalar_spec.py", "nloc": 24, "complexity": 3, "token_count": 130, "parameters": [ "self" ], "start_line": 204, "end_line": 227, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 24, "top_nesting_level": 1 }, { "name": "check_complex_var_local", "long_name": "check_complex_var_local( self )", "filename": "test_scalar_spec.py", "nloc": 16, "complexity": 1, "token_count": 121, "parameters": [ "self" ], "start_line": 228, "end_line": 243, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "check_complex_return", "long_name": "check_complex_return( self )", "filename": "test_scalar_spec.py", "nloc": 18, "complexity": 1, "token_count": 114, "parameters": [ "self" ], "start_line": 244, "end_line": 261, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 1 }, { "name": "setup_test_location", "long_name": "setup_test_location( )", "filename": "test_scalar_spec.py", "nloc": 7, "complexity": 2, "token_count": 51, "parameters": [], "start_line": 285, "end_line": 291, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "teardown_test_location", "long_name": "teardown_test_location( )", "filename": "test_scalar_spec.py", "nloc": 6, "complexity": 2, "token_count": 45, "parameters": [], "start_line": 293, "end_line": 298, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 }, { "name": "remove_file", "long_name": "remove_file( name )", "filename": "test_scalar_spec.py", "nloc": 2, "complexity": 1, "token_count": 15, "parameters": [ "name" ], "start_line": 300, "end_line": 301, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_scalar_spec.py", "nloc": 17, "complexity": 3, "token_count": 148, "parameters": [], "start_line": 302, "end_line": 321, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_scalar_spec.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 323, "end_line": 327, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "methods_before": [ { "name": "unique_mod", "long_name": "unique_mod( d , file_name )", "filename": "test_scalar_spec.py", "nloc": 4, "complexity": 1, "token_count": 37, "parameters": [ "d", "file_name" ], "start_line": 14, "end_line": 17, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 0 }, { "name": "remove_whitespace", "long_name": "remove_whitespace( in_str )", "filename": "test_scalar_spec.py", "nloc": 6, "complexity": 1, "token_count": 45, "parameters": [ "in_str" ], "start_line": 19, "end_line": 24, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 }, { "name": "print_assert_equal", "long_name": "print_assert_equal( test_string , actual , desired )", "filename": "test_scalar_spec.py", "nloc": 13, "complexity": 2, "token_count": 74, "parameters": [ "test_string", "actual", "desired" ], "start_line": 26, "end_line": 40, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "check_type_match_string", "long_name": "check_type_match_string( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 44, "end_line": 46, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_int", "long_name": "check_type_match_int( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 21, "parameters": [ "self" ], "start_line": 47, "end_line": 49, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_float", "long_name": "check_type_match_float( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 23, "parameters": [ "self" ], "start_line": 50, "end_line": 52, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_complex", "long_name": "check_type_match_complex( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 25, "parameters": [ "self" ], "start_line": 53, "end_line": 55, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_var_in", "long_name": "check_var_in( self )", "filename": "test_scalar_spec.py", "nloc": 24, "complexity": 3, "token_count": 116, "parameters": [ "self" ], "start_line": 56, "end_line": 79, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 24, "top_nesting_level": 1 }, { "name": "check_int_var_local", "long_name": "check_int_var_local( self )", "filename": "test_scalar_spec.py", "nloc": 16, "complexity": 1, "token_count": 112, "parameters": [ "self" ], "start_line": 81, "end_line": 96, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "check_int_return", "long_name": "check_int_return( self )", "filename": "test_scalar_spec.py", "nloc": 18, "complexity": 1, "token_count": 105, "parameters": [ "self" ], "start_line": 97, "end_line": 114, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 1 }, { "name": "check_type_match_string", "long_name": "check_type_match_string( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 118, "end_line": 120, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_int", "long_name": "check_type_match_int( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 121, "end_line": 123, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_float", "long_name": "check_type_match_float( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 124, "end_line": 126, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_complex", "long_name": "check_type_match_complex( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 25, "parameters": [ "self" ], "start_line": 127, "end_line": 129, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_float_var_in", "long_name": "check_float_var_in( self )", "filename": "test_scalar_spec.py", "nloc": 24, "complexity": 3, "token_count": 126, "parameters": [ "self" ], "start_line": 130, "end_line": 154, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 1 }, { "name": "check_float_var_local", "long_name": "check_float_var_local( self )", "filename": "test_scalar_spec.py", "nloc": 16, "complexity": 1, "token_count": 115, "parameters": [ "self" ], "start_line": 155, "end_line": 170, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "check_float_return", "long_name": "check_float_return( self )", "filename": "test_scalar_spec.py", "nloc": 18, "complexity": 1, "token_count": 108, "parameters": [ "self" ], "start_line": 171, "end_line": 188, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 1 }, { "name": "check_type_match_string", "long_name": "check_type_match_string( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 192, "end_line": 194, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_int", "long_name": "check_type_match_int( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 195, "end_line": 197, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_float", "long_name": "check_type_match_float( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 23, "parameters": [ "self" ], "start_line": 198, "end_line": 200, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_complex", "long_name": "check_type_match_complex( self )", "filename": "test_scalar_spec.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 201, "end_line": 203, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_complex_var_in", "long_name": "check_complex_var_in( self )", "filename": "test_scalar_spec.py", "nloc": 24, "complexity": 3, "token_count": 130, "parameters": [ "self" ], "start_line": 204, "end_line": 227, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 24, "top_nesting_level": 1 }, { "name": "check_complex_var_local", "long_name": "check_complex_var_local( self )", "filename": "test_scalar_spec.py", "nloc": 16, "complexity": 1, "token_count": 121, "parameters": [ "self" ], "start_line": 228, "end_line": 243, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "check_complex_return", "long_name": "check_complex_return( self )", "filename": "test_scalar_spec.py", "nloc": 18, "complexity": 1, "token_count": 114, "parameters": [ "self" ], "start_line": 244, "end_line": 261, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 1 }, { "name": "setup_test_location", "long_name": "setup_test_location( )", "filename": "test_scalar_spec.py", "nloc": 7, "complexity": 2, "token_count": 49, "parameters": [], "start_line": 285, "end_line": 291, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "teardown_test_location", "long_name": "teardown_test_location( )", "filename": "test_scalar_spec.py", "nloc": 6, "complexity": 2, "token_count": 43, "parameters": [], "start_line": 293, "end_line": 298, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 }, { "name": "remove_file", "long_name": "remove_file( name )", "filename": "test_scalar_spec.py", "nloc": 2, "complexity": 1, "token_count": 15, "parameters": [ "name" ], "start_line": 300, "end_line": 301, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_scalar_spec.py", "nloc": 12, "complexity": 3, "token_count": 83, "parameters": [], "start_line": 302, "end_line": 321, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_scalar_spec.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 323, "end_line": 327, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "setup_test_location", "long_name": "setup_test_location( )", "filename": "test_scalar_spec.py", "nloc": 7, "complexity": 2, "token_count": 51, "parameters": [], "start_line": 285, "end_line": 291, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "teardown_test_location", "long_name": "teardown_test_location( )", "filename": "test_scalar_spec.py", "nloc": 6, "complexity": 2, "token_count": 45, "parameters": [], "start_line": 293, "end_line": 298, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_scalar_spec.py", "nloc": 17, "complexity": 3, "token_count": 148, "parameters": [], "start_line": 302, "end_line": 321, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 } ], "nloc": 306, "complexity": 40, "token_count": 1947, "diff_parsed": { "added": [ " test_dir = os.path.join(tempfile.gettempdir(),'test_files')", " test_dir = os.path.join(tempfile.gettempdir(),'test_files')", " suites.append( unittest.makeSuite(test_msvc_int_specification,'check_'))", " suites.append( unittest.makeSuite(test_msvc_float_specification,'check_'))", " suites.append( unittest.makeSuite(test_msvc_complex_specification,'check_'))", " suites.append( unittest.makeSuite(test_gcc_int_specification,'check_'))", " suites.append( unittest.makeSuite(test_gcc_float_specification,'check_'))" ], "deleted": [ " test_dir = os.path.join(tempfile.tempdir,'test_files')", " test_dir = os.path.join(tempfile.tempdir,'test_files')", " #suites.append( unittest.makeSuite(test_msvc_int_specification,'check_'))", " #suites.append( unittest.makeSuite(test_msvc_float_specification,'check_'))", " #suites.append( unittest.makeSuite(test_msvc_complex_specification,'check_'))", " #suites.append( unittest.makeSuite(test_gcc_int_specification,'check_'))", " #suites.append( unittest.makeSuite(test_gcc_float_specification,'check_'))" ] } } ] }, { "hash": "d33eb99f6e64a721e9b76fbc8fa1969bdbdc5658", "msg": "added a short README to tell where the documentation files are located", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-04T16:21:11+00:00", "author_timezone": 0, "committer_date": "2002-01-04T16:21:11+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "a603ba140acaf24a365343c9c9b48904745e4386" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 0, "insertions": 5, "lines": 5, "files": 1, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": null, "new_path": "weave/README.txt", "filename": "README.txt", "extension": "txt", "change_type": "ADD", "diff": "@@ -0,0 +1,5 @@\n+weave provides tools for including C/C++ code within Python.\n+\n+For instructions on installation, see the tutorial file located\n+in doc/tutorial.html or weave/doc/tutorial.html, depending upon\n+how weave was packaged.\n\\ No newline at end of file\n", "added_lines": 5, "deleted_lines": 0, "source_code": "weave provides tools for including C/C++ code within Python.\n\nFor instructions on installation, see the tutorial file located\nin doc/tutorial.html or weave/doc/tutorial.html, depending upon\nhow weave was packaged.", "source_code_before": null, "methods": [], "methods_before": [], "changed_methods": [], "nloc": null, "complexity": null, "token_count": null, "diff_parsed": { "added": [ "weave provides tools for including C/C++ code within Python.", "", "For instructions on installation, see the tutorial file located", "in doc/tutorial.html or weave/doc/tutorial.html, depending upon", "how weave was packaged." ], "deleted": [] } } ] }, { "hash": "4b8ca90a8260c3718c5b1a7460bc24e22c083b23", "msg": "added legal license information to the file.", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-04T16:39:45+00:00", "author_timezone": 0, "committer_date": "2002-01-04T16:39:45+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "d33eb99f6e64a721e9b76fbc8fa1969bdbdc5658" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 31, "insertions": 228, "lines": 259, "files": 4, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": null, "new_path": "weave/LICENSE.txt", "filename": "LICENSE.txt", "extension": "txt", "change_type": "ADD", "diff": "@@ -0,0 +1,173 @@\n+weave is distributed under the same license as SciPy which uses a BSD Style \n+license. weave also includes CXX by Paul Dubois, portions of SCXX by\n+Gordon McMillan, and blitz++ by Todd Veldhuizen. The licenses for all of\n+these packages are different, but allow free use for both commercial and\n+non-commercial purposes. The licenses for each are listed below:\n+\n+-------------------------------------------------------------------------\n+\n+SciPy License\n+\n+Copyright (c) 2001, Enthought, Inc.\n+\n+All rights reserved.\n+\n+Redistribution and use in source and binary forms, with or without\n+modification, are permitted provided that the following conditions are met:\n+\n+ a. Redistributions of source code must retain the above copyright notice,\n+ this list of conditions and the following disclaimer.\n+ b. Redistributions in binary form must reproduce the above copyright\n+ notice, this list of conditions and the following disclaimer in the\n+ documentation and/or other materials provided with the distribution.\n+ c. Neither the name of the Enthought nor the names of its contributors\n+ may be used to endorse or promote products derived from this software\n+ without specific prior written permission.\n+\n+\n+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\"\n+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE\n+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE\n+ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR\n+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL\n+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR\n+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER\n+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT\n+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY\n+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH\n+DAMAGE.\n+\n+-------------------------------------------------------------------------\n+\n+CXX License\n+\n+*** Legal Notice for all LLNL-contributed files ***\n+\n+Copyright (c) 1996. The Regents of the University of California. \n+ All rights reserved. \n+\n+Permission to use, copy, modify, and distribute this software for any purpose \n+without fee is hereby granted, provided that this entire notice is included in \n+all copies of any software which is or includes a copy or modification of this \n+software and in all copies of the supporting documentation for such software.\n+\n+This work was produced at the University of California, Lawrence Livermore \n+National Laboratory under contract no. W-7405-ENG-48 between the U.S. \n+Department of Energy and The Regents of the University of California for the \n+operation of UC LLNL. \n+\n+DISCLAIMER \n+\n+This software was prepared as an account of work sponsored by an agency of the \n+United States Government. Neither the United States Government nor the \n+University of California nor any of their employees, makes any warranty, \n+express or implied, or assumes any liability or responsibility for the \n+accuracy, completeness, or usefulness of any information, apparatus, product, \n+or process disclosed, or represents that its use would not infringe privately-\n+owned rights. Reference herein to any specific commercial products, process, or \n+service by trade name, trademark, manufacturer, or otherwise, does not \n+necessarily constitute or imply its endorsement, recommendation, or favoring by \n+the United States Government or the University of California. The views and \n+opinions of authors expressed herein do not necessarily state or reflect those \n+of the United States Government or the University of California, and shall not \n+be used for advertising or product endorsement purposes.\n+\n+-------------------------------------------------------------------------\n+\n+SCXX License\n+\n+No restrictions on usage, modification or redistribution, as long as the \n+copyright notice is maintained. No warranty whatsoever.\n+\n+copyright 1999 McMillan Enterprises, Inc.\n+www.mcmillan-inc.com\n+\n+-------------------------------------------------------------------------\n+\n+Blitz License\n+\n+The `Blitz++ Artistic License'\n+(with thanks and apologies to authors of the Perl Artistic License)\n+\n+Preamble\n+\n+The intent of this document is to state the conditions under which \n+Blitz++ may be copied, such that the authors maintains some\n+semblance of artistic control over the development of the package,\n+while giving the users of the package the right to use and\n+distribute Blitz++ in a more-or-less customary fashion, plus the\n+right to make reasonable modifications.\n+\n+Definitions\n+\n+`Library' refers to the collection of files distributed by the\n+Copyright Holder, and derivatives of that collection of files\n+created through textual modification.\n+\n+`Standard Version' refers to such a Library if it has not been\n+modified, or has been modified in accordance with the wishes of the\n+Copyright Holder as specified below.\n+\n+Copyright Holder' is whoever is named in the copyright or\n+copyrights for the package.\n+\n+`You' is you, if you're thinking about copying, modifying or\n+distributing this Library.\n+\n+`Freely Available' means that no fee is charged for the item.\n+It also means that recipients of the item may redistribute it \n+under the same conditions they received it.\n+\n+``Reasonable copying fee'' is whatever you can justify on the basis\n+of media cost, duplication charges, time of people involved, and so\n+on. (You will not be required to justify it to the Copyright Holder,\n+but only to the computing community at large as a market that must\n+bear the fee.)\n+\n+1. You may make and give away verbatim copies of the \n+Standard Version of this Library without restriction, provided that\n+you duplicate all of the original copyright notices, this license,\n+and associated disclaimers. \n+\n+2. The Standard Version of the Library may be distributed as part\n+of a collection of software, provided no more than a reasonable\n+copying fee is charged for the software collection.\n+\n+3. You may apply bug fixes, portability fixes and other modifications\n+derived from the Public Domain or from the Copyright Holder. A\n+Library modified in such a way shall still be considered the\n+Standard Version.\n+\n+4. You may otherwise modify your copy of this Library in any way,\n+provided that you insert a prominent notice in each changed file\n+stating how and when you changed that file, and provided that you do\n+at least ONE of the following:\n+\n+a. place your modifications in the Public Domain or otherwise\n+make them Freely Available, such as by posting said\n+modifications to the Blitz++ development list, \n+and allowing the Copyright Holder to include\n+your modifications in the Standard Version of the Library.\n+\n+b. use the modified Library only within your corporation or\n+organization. \n+\n+c. make other distribution arrangements with the Copyright\n+Holder.\n+\n+5. You may distribute programs which use this Library\n+in object code or executable form without restriction.\n+\n+6. Any object code generated as a result of using this Library \n+does not fall under the copyright of this Library, but\n+belongs to whomever generated it, and may be sold commercially.\n+\n+7. The name of the Copyright Holder or the Library may not be used to \n+endorse or promote products derived from this software without \n+specific prior written permission.\n+\n+8. THIS PACKAGE IS PROVIDED `AS IS' AND WITHOUT ANY EXPRESS OR\n+IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED\n+WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.\n+\n+\n", "added_lines": 173, "deleted_lines": 0, "source_code": "weave is distributed under the same license as SciPy which uses a BSD Style \nlicense. weave also includes CXX by Paul Dubois, portions of SCXX by\nGordon McMillan, and blitz++ by Todd Veldhuizen. The licenses for all of\nthese packages are different, but allow free use for both commercial and\nnon-commercial purposes. The licenses for each are listed below:\n\n-------------------------------------------------------------------------\n\nSciPy License\n\nCopyright (c) 2001, Enthought, Inc.\n\nAll rights reserved.\n\nRedistribution and use in source and binary forms, with or without\nmodification, are permitted provided that the following conditions are met:\n\n a. Redistributions of source code must retain the above copyright notice,\n this list of conditions and the following disclaimer.\n b. Redistributions in binary form must reproduce the above copyright\n notice, this list of conditions and the following disclaimer in the\n documentation and/or other materials provided with the distribution.\n c. Neither the name of the Enthought nor the names of its contributors\n may be used to endorse or promote products derived from this software\n without specific prior written permission.\n\n\nTHIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\"\nAND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE\nIMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE\nARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR\nANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL\nDAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR\nSERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER\nCAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT\nLIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY\nOUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH\nDAMAGE.\n\n-------------------------------------------------------------------------\n\nCXX License\n\n*** Legal Notice for all LLNL-contributed files ***\n\nCopyright (c) 1996. The Regents of the University of California. \n All rights reserved. \n\nPermission to use, copy, modify, and distribute this software for any purpose \nwithout fee is hereby granted, provided that this entire notice is included in \nall copies of any software which is or includes a copy or modification of this \nsoftware and in all copies of the supporting documentation for such software.\n\nThis work was produced at the University of California, Lawrence Livermore \nNational Laboratory under contract no. W-7405-ENG-48 between the U.S. \nDepartment of Energy and The Regents of the University of California for the \noperation of UC LLNL. \n\nDISCLAIMER \n\nThis software was prepared as an account of work sponsored by an agency of the \nUnited States Government. Neither the United States Government nor the \nUniversity of California nor any of their employees, makes any warranty, \nexpress or implied, or assumes any liability or responsibility for the \naccuracy, completeness, or usefulness of any information, apparatus, product, \nor process disclosed, or represents that its use would not infringe privately-\nowned rights. Reference herein to any specific commercial products, process, or \nservice by trade name, trademark, manufacturer, or otherwise, does not \nnecessarily constitute or imply its endorsement, recommendation, or favoring by \nthe United States Government or the University of California. The views and \nopinions of authors expressed herein do not necessarily state or reflect those \nof the United States Government or the University of California, and shall not \nbe used for advertising or product endorsement purposes.\n\n-------------------------------------------------------------------------\n\nSCXX License\n\nNo restrictions on usage, modification or redistribution, as long as the \ncopyright notice is maintained. No warranty whatsoever.\n\ncopyright 1999 McMillan Enterprises, Inc.\nwww.mcmillan-inc.com\n\n-------------------------------------------------------------------------\n\nBlitz License\n\nThe `Blitz++ Artistic License'\n(with thanks and apologies to authors of the Perl Artistic License)\n\nPreamble\n\nThe intent of this document is to state the conditions under which \nBlitz++ may be copied, such that the authors maintains some\nsemblance of artistic control over the development of the package,\nwhile giving the users of the package the right to use and\ndistribute Blitz++ in a more-or-less customary fashion, plus the\nright to make reasonable modifications.\n\nDefinitions\n\n`Library' refers to the collection of files distributed by the\nCopyright Holder, and derivatives of that collection of files\ncreated through textual modification.\n\n`Standard Version' refers to such a Library if it has not been\nmodified, or has been modified in accordance with the wishes of the\nCopyright Holder as specified below.\n\nCopyright Holder' is whoever is named in the copyright or\ncopyrights for the package.\n\n`You' is you, if you're thinking about copying, modifying or\ndistributing this Library.\n\n`Freely Available' means that no fee is charged for the item.\nIt also means that recipients of the item may redistribute it \nunder the same conditions they received it.\n\n``Reasonable copying fee'' is whatever you can justify on the basis\nof media cost, duplication charges, time of people involved, and so\non. (You will not be required to justify it to the Copyright Holder,\nbut only to the computing community at large as a market that must\nbear the fee.)\n\n1. You may make and give away verbatim copies of the \nStandard Version of this Library without restriction, provided that\nyou duplicate all of the original copyright notices, this license,\nand associated disclaimers. \n\n2. The Standard Version of the Library may be distributed as part\nof a collection of software, provided no more than a reasonable\ncopying fee is charged for the software collection.\n\n3. You may apply bug fixes, portability fixes and other modifications\nderived from the Public Domain or from the Copyright Holder. A\nLibrary modified in such a way shall still be considered the\nStandard Version.\n\n4. You may otherwise modify your copy of this Library in any way,\nprovided that you insert a prominent notice in each changed file\nstating how and when you changed that file, and provided that you do\nat least ONE of the following:\n\na. place your modifications in the Public Domain or otherwise\nmake them Freely Available, such as by posting said\nmodifications to the Blitz++ development list, \nand allowing the Copyright Holder to include\nyour modifications in the Standard Version of the Library.\n\nb. use the modified Library only within your corporation or\norganization. \n\nc. make other distribution arrangements with the Copyright\nHolder.\n\n5. You may distribute programs which use this Library\nin object code or executable form without restriction.\n\n6. Any object code generated as a result of using this Library \ndoes not fall under the copyright of this Library, but\nbelongs to whomever generated it, and may be sold commercially.\n\n7. The name of the Copyright Holder or the Library may not be used to \nendorse or promote products derived from this software without \nspecific prior written permission.\n\n8. THIS PACKAGE IS PROVIDED `AS IS' AND WITHOUT ANY EXPRESS OR\nIMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED\nWARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.\n\n\n", "source_code_before": null, "methods": [], "methods_before": [], "changed_methods": [], "nloc": null, "complexity": null, "token_count": null, "diff_parsed": { "added": [ "weave is distributed under the same license as SciPy which uses a BSD Style", "license. weave also includes CXX by Paul Dubois, portions of SCXX by", "Gordon McMillan, and blitz++ by Todd Veldhuizen. The licenses for all of", "these packages are different, but allow free use for both commercial and", "non-commercial purposes. The licenses for each are listed below:", "", "-------------------------------------------------------------------------", "", "SciPy License", "", "Copyright (c) 2001, Enthought, Inc.", "", "All rights reserved.", "", "Redistribution and use in source and binary forms, with or without", "modification, are permitted provided that the following conditions are met:", "", " a. Redistributions of source code must retain the above copyright notice,", " this list of conditions and the following disclaimer.", " b. Redistributions in binary form must reproduce the above copyright", " notice, this list of conditions and the following disclaimer in the", " documentation and/or other materials provided with the distribution.", " c. Neither the name of the Enthought nor the names of its contributors", " may be used to endorse or promote products derived from this software", " without specific prior written permission.", "", "", "THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\"", "AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE", "IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE", "ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR", "ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL", "DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR", "SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER", "CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT", "LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY", "OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH", "DAMAGE.", "", "-------------------------------------------------------------------------", "", "CXX License", "", "*** Legal Notice for all LLNL-contributed files ***", "", "Copyright (c) 1996. The Regents of the University of California.", " All rights reserved.", "", "Permission to use, copy, modify, and distribute this software for any purpose", "without fee is hereby granted, provided that this entire notice is included in", "all copies of any software which is or includes a copy or modification of this", "software and in all copies of the supporting documentation for such software.", "", "This work was produced at the University of California, Lawrence Livermore", "National Laboratory under contract no. W-7405-ENG-48 between the U.S.", "Department of Energy and The Regents of the University of California for the", "operation of UC LLNL.", "", "DISCLAIMER", "", "This software was prepared as an account of work sponsored by an agency of the", "United States Government. Neither the United States Government nor the", "University of California nor any of their employees, makes any warranty,", "express or implied, or assumes any liability or responsibility for the", "accuracy, completeness, or usefulness of any information, apparatus, product,", "or process disclosed, or represents that its use would not infringe privately-", "owned rights. Reference herein to any specific commercial products, process, or", "service by trade name, trademark, manufacturer, or otherwise, does not", "necessarily constitute or imply its endorsement, recommendation, or favoring by", "the United States Government or the University of California. The views and", "opinions of authors expressed herein do not necessarily state or reflect those", "of the United States Government or the University of California, and shall not", "be used for advertising or product endorsement purposes.", "", "-------------------------------------------------------------------------", "", "SCXX License", "", "No restrictions on usage, modification or redistribution, as long as the", "copyright notice is maintained. No warranty whatsoever.", "", "copyright 1999 McMillan Enterprises, Inc.", "www.mcmillan-inc.com", "", "-------------------------------------------------------------------------", "", "Blitz License", "", "The `Blitz++ Artistic License'", "(with thanks and apologies to authors of the Perl Artistic License)", "", "Preamble", "", "The intent of this document is to state the conditions under which", "Blitz++ may be copied, such that the authors maintains some", "semblance of artistic control over the development of the package,", "while giving the users of the package the right to use and", "distribute Blitz++ in a more-or-less customary fashion, plus the", "right to make reasonable modifications.", "", "Definitions", "", "`Library' refers to the collection of files distributed by the", "Copyright Holder, and derivatives of that collection of files", "created through textual modification.", "", "`Standard Version' refers to such a Library if it has not been", "modified, or has been modified in accordance with the wishes of the", "Copyright Holder as specified below.", "", "Copyright Holder' is whoever is named in the copyright or", "copyrights for the package.", "", "`You' is you, if you're thinking about copying, modifying or", "distributing this Library.", "", "`Freely Available' means that no fee is charged for the item.", "It also means that recipients of the item may redistribute it", "under the same conditions they received it.", "", "``Reasonable copying fee'' is whatever you can justify on the basis", "of media cost, duplication charges, time of people involved, and so", "on. (You will not be required to justify it to the Copyright Holder,", "but only to the computing community at large as a market that must", "bear the fee.)", "", "1. You may make and give away verbatim copies of the", "Standard Version of this Library without restriction, provided that", "you duplicate all of the original copyright notices, this license,", "and associated disclaimers.", "", "2. The Standard Version of the Library may be distributed as part", "of a collection of software, provided no more than a reasonable", "copying fee is charged for the software collection.", "", "3. You may apply bug fixes, portability fixes and other modifications", "derived from the Public Domain or from the Copyright Holder. A", "Library modified in such a way shall still be considered the", "Standard Version.", "", "4. You may otherwise modify your copy of this Library in any way,", "provided that you insert a prominent notice in each changed file", "stating how and when you changed that file, and provided that you do", "at least ONE of the following:", "", "a. place your modifications in the Public Domain or otherwise", "make them Freely Available, such as by posting said", "modifications to the Blitz++ development list,", "and allowing the Copyright Holder to include", "your modifications in the Standard Version of the Library.", "", "b. use the modified Library only within your corporation or", "organization.", "", "c. make other distribution arrangements with the Copyright", "Holder.", "", "5. You may distribute programs which use this Library", "in object code or executable form without restriction.", "", "6. Any object code generated as a result of using this Library", "does not fall under the copyright of this Library, but", "belongs to whomever generated it, and may be sold commercially.", "", "7. The name of the Copyright Holder or the Library may not be used to", "endorse or promote products derived from this software without", "specific prior written permission.", "", "8. THIS PACKAGE IS PROVIDED `AS IS' AND WITHOUT ANY EXPRESS OR", "IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED", "WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.", "", "" ], "deleted": [] } }, { "old_path": "weave/README.txt", "new_path": "weave/README.txt", "filename": "README.txt", "extension": "txt", "change_type": "MODIFY", "diff": "@@ -1,5 +1,10 @@\n weave provides tools for including C/C++ code within Python.\n \n-For instructions on installation, see the tutorial file located\n-in doc/tutorial.html or weave/doc/tutorial.html, depending upon\n-how weave was packaged.\n\\ No newline at end of file\n+For instructions on installation, see the tutorial file located in \n+doc/tutorial.html or weave/doc/tutorial.html, depending upon how weave was \n+packaged.\n+\n+The LICENSE.txt file (either in this directory or in the weave directory) has \n+licenses for all the code distributed in this package. All licenses allow free \n+use of the package for both commercial and non-commercial\n+purposes.\n\\ No newline at end of file\n", "added_lines": 8, "deleted_lines": 3, "source_code": "weave provides tools for including C/C++ code within Python.\n\nFor instructions on installation, see the tutorial file located in \ndoc/tutorial.html or weave/doc/tutorial.html, depending upon how weave was \npackaged.\n\nThe LICENSE.txt file (either in this directory or in the weave directory) has \nlicenses for all the code distributed in this package. All licenses allow free \nuse of the package for both commercial and non-commercial\npurposes.", "source_code_before": "weave provides tools for including C/C++ code within Python.\n\nFor instructions on installation, see the tutorial file located\nin doc/tutorial.html or weave/doc/tutorial.html, depending upon\nhow weave was packaged.", "methods": [], "methods_before": [], "changed_methods": [], "nloc": null, "complexity": null, "token_count": null, "diff_parsed": { "added": [ "For instructions on installation, see the tutorial file located in", "doc/tutorial.html or weave/doc/tutorial.html, depending upon how weave was", "packaged.", "", "The LICENSE.txt file (either in this directory or in the weave directory) has", "licenses for all the code distributed in this package. All licenses allow free", "use of the package for both commercial and non-commercial", "purposes." ], "deleted": [ "For instructions on installation, see the tutorial file located", "in doc/tutorial.html or weave/doc/tutorial.html, depending upon", "how weave was packaged." ] } }, { "old_path": "weave/doc/tutorial.html", "new_path": "weave/doc/tutorial.html", "filename": "tutorial.html", "extension": "html", "change_type": "MODIFY", "diff": "@@ -250,13 +250,13 @@

      Installation and Testing

      \n \n This takes a loooong time. On windows, it is usually several minutes. On Unix \n with remote file systems, I've had it take 15 or so minutes. In the end, it \n-should run about 150 tests and spew some speed results along the way. If you \n+should run about 180 tests and spew some speed results along the way. If you \n get errors, please let me know.\n \n If you don't have Numeric installed, you'll get some module import errors \n during the test setup phase for modules that are Numeric specific (blitz_spec, \n blitz_tools, size_check, standard_array_spec, ast_tools), but all test should\n-pass (about 60 and the run time should be quite a bit less).\n+pass (about 100 and they should complete in several minutes).\n

      \n If you only want to test a single module of the package, you can do this by\n running test() for that specific module.\n@@ -269,17 +269,24 @@

      Installation and Testing

      \n Ran 7 tests in 23.284s\n
      \n \n-Note: I've had some test fail on windows machines where I have msvc, gcc-2.95.2 \n-(in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My environment \n-has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the path. The test \n-process runs very smoothly until the end where several test using gcc fail with \n-cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I \n-get gcc-2.95.3-6. If I check after running tests (and after failure), I get \n-gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\\gcc first in it and \n-is not corrupted (msvc/distutils messes with the environment variables, so we \n-have to undo its work in some places). If anyone else sees this, let me know -\n-- it may just be an quirk on my machine (unlikely). Testing with the gcc-\n-2.95.2 installation always works.\n+Windows Note: I've had some test fail on windows machines where I have msvc, \n+gcc-2.95.2 (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My \n+environment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the path. \n+The test process runs very smoothly until the end where several test using gcc \n+fail with cpp0 not found by g++. If I check os.system('gcc -v') before running \n+tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), \n+I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\\gcc first in it \n+and is not corrupted (msvc/distutils messes with the environment variables, so \n+we have to undo its work in some places). If anyone else sees this, let me \n+know - - it may just be an quirk on my machine (unlikely). Testing with the \n+gcc- 2.95.2 installation always works.\n+\n+

      \n+\n+wxPython Note: wxPython tests are not enabled by default because importing\n+wxPython on a Unix machine without access to a X-term will cause the \n+program to exit. Anyone know of a safe way to detect whether wxPython\n+can be imported and whether a display exists on a machine?\n \n \n \n@@ -514,6 +521,17 @@

      Binary search

      \n seq.length() returns the length of the list. A little more about\n CXX and its class methods, etc. is in the ** type conversions ** section.\n

      \n+\n+Note: CXX uses templates and therefore may be a little less portable than \n+another alternative by Gordan McMillan called SCXX which was inspired by\n+CXX. It doesn't use templates so it should compile faster and be more portable.\n+SCXX has a few less features, but it appears to me that it would mesh with\n+the needs of weave quite well. Hopefully xxx_spec files will be written\n+for SCXX in the future, and we'll be able to compare on a more empirical\n+basis. Both sets of spec files will probably stick around, it just a question\n+of which becomes the default.\n+\n+

      \n Most of the algorithm above looks similar in C to the original Python code. \n There are two main differences. The first is the setting of \n return_val instead of directly returning from the C code with a \n@@ -1435,26 +1453,28 @@

      Technical Details

      \n Generating the C/C++ code is handled by ext_function and \n ext_module classes and . For the most part, compiling the code is \n handled by distutils. Some customizations were needed, but they were \n-relatively minor and do not require changes to distutils itself (although a few \n-changes would be nice...). Cataloging is pretty simple in concept, but surprisingly\n-required the most code to implement (and still likely needs some work). So,\n-this section covers items 1 and 4 from the list. Item 2 is covered later in\n-the chapter covering the ext_tools module, and distutils is covered\n-by a completely separate document xxx.\n- \n+relatively minor and do not require changes to distutils itself. Cataloging is \n+pretty simple in concept, but surprisingly required the most code to implement \n+(and still likely needs some work). So, this section covers items 1 and 4 from \n+the list. Item 2 is covered later in the chapter covering the \n+ext_tools module, and distutils is covered by a completely \n+separate document xxx.\n+\n

      Passing Variables in/out of the C/C++ code

      \n \n Note: Passing variables into the C code is pretty straight forward, but there \n-are subtlties to how variable modifications in C are returned to Python. see \n-xxx for a more thorough discussion of this issue.\n+are subtlties to how variable modifications in C are returned to Python. see Returning Values for a more thorough discussion of \n+this issue.\n \n-\n+ \n \n

      Type Conversions

      \n \n \n-Note: Maybe xxx_converter instead of xxx_specification is a more descriptive \n-name.\n+Note: Maybe xxx_converter instead of \n+xxx_specification is a more descriptive name. Might change in \n+future version?\n \n \n

      \n@@ -1498,7 +1518,6 @@

      Type Conversions

      \n
    • \n Hopefully VTK will be added to the list soon
      • \n \n-
        \n \n

        \n \n", "added_lines": 45, "deleted_lines": 26, "source_code": "\n

        Weave Documentation

        \n

        \nBy Eric Jones eric@enthought.com\n

        \n

        Outline

        \n
        \n
        Introduction\n
        Requirements\n
        Installation and Testing\n
        Inline\n
        \n
        More with printf\n
        \n More examples\n
        \n
        Binary search\n
        Dictionary sort\n
        Numeric -- cast/copy/transpose\n
        wxPython
        \n
        \n
        Keyword options\n
        Returning values\n
        \n
        \n The issue with locals()
        \n
        \n
        A quick look at the code\n
        \n Technical Details\n
        \n
        Converting Types\n
        \n
        \n Numeric Argument Conversion\n
        \n String, List, Tuple, and Dictionary Conversion\n
        File Conversion \n
        \n Callable, Instance, and Module Conversion \n
        Customizing Conversions\n
        \n
        Compiling Code\n
        \"Cataloging\" functions\n
        \n
        Function Storage\n
        The PYTHONCOMPILED evnironment variable
        \n
        \n
        \n
        \n
        \n
        \n
        Blitz\n
        \n
        Requirements\n
        Limitations\n
        Numeric Efficiency Issues\n
        The Tools \n
        \n
        Parser\n
        Blitz and Numeric\n
        \n
        Type defintions and coersion\n
        Cataloging Compiled Functions\n
        Checking Array Sizes\n
        Creating the Extension Module\n
        \n
        Extension Modules\n
        \n
        A Simple Example\n
        Fibonacci Example\n
        \n
        Customizing Type Conversions -- Type Factories (not written)\n
        \n
        Type Specifications\n
        Type Information\n
        The Conversion Process \n
        \n
        \n\n

        Introduction

        \n\n

        \nThe weave package provides tools for including C/C++ code within\nin Python code. This offers both another level of optimization to those who need \nit, and an easy way to modify and extend any supported extension libraries such \nas wxPython and hopefully VTK soon. Inlining C/C++ code within Python generally\nresults in speed ups of 1.5x to 30x speed-up over algorithms written in pure\nPython (However, it is also possible to slow things down...). Generally \nalgorithms that require a large number of calls to the Python API don't benefit\nas much from the conversion to C/C++ as algorithms that have inner loops \ncompletely convertable to C.\n

        \nThere are three basic ways to use weave. The \nweave.inline() function executes C code directly within Python, \nand weave.blitz() translates Python Numeric expressions to C++ \nfor fast execution. blitz() was the original reason \nweave was built. For those interested in building extension\nlibraries, the ext_tools module provides classes for building \nextension modules within Python. \n

        \nMost of weave's functionality should work on Windows and Unix, \nalthough some of its functionality requires gcc or a similarly \nmodern C++ compiler that handles templates well. Up to now, most testing has \nbeen done on Windows 2000 with Microsoft's C++ compiler (MSVC) and with gcc \n(mingw32 2.95.2 and 2.95.3-6). All tests also pass on Linux (RH 7.1 \nwith gcc 2.96), and I've had reports that it works on Debian also (thanks \nPearu).\n

        \nThe inline and blitz provide new functionality to \nPython (although I've recently learned about the PyInline project which may offer \nsimilar functionality to inline). On the other hand, tools for \nbuilding Python extension modules already exists (SWIG, SIP, pycpp, CXX, and \nothers). As of yet, I'm not sure where weave fits in this \nspectrum. It is closest in flavor to CXX in that it makes creating new C/C++ \nextension modules pretty easy. However, if you're wrapping a gaggle of legacy \nfunctions or classes, SWIG and friends are definitely the better choice. \nweave is set up so that you can customize how Python types are \nconverted to C types in weave. This is great for \ninline(), but, for wrapping legacy code, it is more flexible to \nspecify things the other way around -- that is how C types map to Python types. \nThis weave does not do. I guess it would be possible to build \nsuch a tool on top of weave, but with good tools like SWIG around, \nI'm not sure the effort produces any new capabilities. Things like function \noverloading are probably easily implemented in weave and it might \nbe easier to mix Python/C code in function calls, but nothing beyond this comes \nto mind. So, if you're developing new extension modules or optimizing Python \nfunctions in C, weave.ext_tools() might be the tool \nfor you. If you're wrapping legacy code, stick with SWIG.\n

        \nThe next several sections give the basics of how to use weave.\nWe'll discuss what's happening under the covers in more detail later \non. Serious users will need to at least look at the type conversion section to \nunderstand how Python variables map to C/C++ types and how to customize this \nbehavior. One other note. If you don't know C or C++ then these docs are \nprobably of very little help to you. Further, it'd be helpful if you know \nsomething about writing Python extensions. weave does quite a \nbit for you, but for anything complex, you'll need to do some conversions, \nreference counting, etc.\n

        \n\nNote: weave is actually part of the SciPy package. However, it works fine as a \nstandalone package. The examples here are given as if it is used as a stand \nalone package. If you are using from within scipy, you can use from \nscipy import weave and the examples will work identically.\n\n\n

        Requirements

        \n
          \n
        • Python\n

          \n I use 2.1.1. Probably 2.0 or higher should work.\n

          \n

          • \n \n
        • C++ compiler\n

          \n weave uses distutils to actually build \n extension modules, so it uses whatever compiler was originally used to \n build Python. weave itself requires a C++ compiler. If \n you used a C++ compiler to build Python, your probably fine.\n

          \n On Unix gcc is the preferred choice, because I've done a little \n testing with it. All testing has been done with gcc, but I expect the \n majority of compilers should work for inline and \n ext_tools. The one issue I'm not sure about is that I've \n hard coded things so that compilations are linked with the \n stdc++ library. Is this standard across \n Unix compilers, or is this a gcc-ism?\n

          \n For blitz(), you'll need a reasonably recent version of \n gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n versions are likely to work. Its likely that KAI's C++ compiler and \n maybe some others will work, but I haven't tried. My advise is to use \n gcc for now unless your willing to tinker with the code some.\n

          \n On Windows, either MSVC or gcc (www.mingw.org\" > mingw32) should work. Again, \n you'll need gcc for blitz() as the\n MSVC compiler doesn't handle templates well.\n

          \n I have not tried Cygwin, so please report success if it works for you.\n

          \n

          • \n\n
        • Numeric (optional)\n

          \n The python Numeric module from here. is required for \n blitz() to work. Be sure and get NumPy, not NumArray\n which is the \"next generation\" implementation.\n

          \n

          • \n
        • scipy_distutils and scipy_test (packaged with weave)\n

          \n These two modules are packaged with weave in both\n the windows installer and the source distributions. If you are using\n CVS, however, you'll need to download these separately (also available\n through CVS at SciPy).\n

          \n

          • \n
        \n

        \n\n\n

        Installation and Testing

        \n

        \nThere are currently two ways to get weave. Fist, \nweave is part of SciPy and installed automatically (as a sub-\npackage) whenever SciPy is installed (although the latest version isn't in \nSciPy yet, so use this one for now). Second, since weave is \nuseful outside of the scientific community, it has been setup so that it can be\nused as a stand-alone module. \n\n

        \nThe stand-alone version can be downloaded from here. Unix users should grab the \ntar ball (.tgz file) and install it using the following commands.\n\n 

        \n    tar -xzvf weave-0.2.tar.gz\n    cd weave-0.2\n    python setup.py install\n
        \n\nThis will also install two other packages, scipy_distutils and \nscipy_test. The first is needed by the setup process itself and \nboth are used in the unit-testing process. For Windows users, it's even easier. \nThey can download the click-install .exe file and run it for automatic \ninstallation. Numeric is required if you want to use blitz(), but\nisn't necessary for inline() or ext_tools\n

        \nIf you're using the CVS version, you'll need to install scipy_distutils and \nscipy_test modules (also available from CVS) on your own.\n

        \n Note: The dependency issue here is a little sticky. I hate to make people \ndownload more than one file (and so I haven't), but distutils doesn't have a \nway to do conditional installation -- at least that I know about. This can \nlead to undesired clobbering of modules. What to do, what to do...\n

        \nOnce weave is installed, fire up python and run its unit tests.\n\n 

        \n    >>> import weave\n    >>> weave.test()\n    runs long time... spews tons of output\n
        \n\nThis takes a loooong time. On windows, it is usually several minutes. On Unix \nwith remote file systems, I've had it take 15 or so minutes. In the end, it \nshould run about 180 tests and spew some speed results along the way. If you \nget errors, please let me know.\n\nIf you don't have Numeric installed, you'll get some module import errors \nduring the test setup phase for modules that are Numeric specific (blitz_spec, \nblitz_tools, size_check, standard_array_spec, ast_tools), but all test should\npass (about 100 and they should complete in several minutes).\n

        \nIf you only want to test a single module of the package, you can do this by\nrunning test() for that specific module.\n\n 

        \n    >>> import weave.scalar_spec\n    >>> weave.scalar_spec.test()\n    .......\n    ----------------------------------------------------------------------\n    Ran 7 tests in 23.284s\n
        \n\nWindows Note: I've had some test fail on windows machines where I have msvc, \ngcc-2.95.2 (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My \nenvironment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the path. \nThe test process runs very smoothly until the end where several test using gcc \nfail with cpp0 not found by g++. If I check os.system('gcc -v') before running \ntests, I get gcc-2.95.3-6. If I check after running tests (and after failure), \nI get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\\gcc first in it \nand is not corrupted (msvc/distutils messes with the environment variables, so \nwe have to undo its work in some places). If anyone else sees this, let me \nknow - - it may just be an quirk on my machine (unlikely). Testing with the \ngcc- 2.95.2 installation always works.\n\n

        \n\nwxPython Note: wxPython tests are not enabled by default because importing\nwxPython on a Unix machine without access to a X-term will cause the \nprogram to exit. Anyone know of a safe way to detect whether wxPython\ncan be imported and whether a display exists on a machine?\n\n\n\n

        Inline

        \n

        \ninline() compiles and executes C/C++ code on the fly. Variables \nin the local and global Python scope are also available in the C/C++ code. \nValues are passed to the C/C++ code by assignment much like variables \nare passed into a standard Python function. Values are returned from the C/C++ \ncode through a special argument called return_val. Also, the contents of \nmutable objects can be changed within the C/C++ code and the changes remain \nafter the C code exits and returns to Python. (more on this later)\n

        \nHere's a trivial printf example using inline():\n\n 

        \n    >>> import weave    \n    >>> a  = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
        \n

        \nIn this, its most basic form, inline(c_code, var_list) requires two \narguments. c_code is a string of valid C/C++ code. \nvar_list is a list of variable names that are passed from \nPython into C/C++. Here we have a simple printf statement that \nwrites the Python variable a to the screen. The first time you run \nthis, there will be a pause while the code is written to a .cpp file, compiled \ninto an extension module, loaded into Python, cataloged for future use, and \nexecuted. On windows (850 MHz PIII), this takes about 1.5 seconds when using \nMicrosoft's C++ compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). \nAll subsequent executions of the code will happen very quickly because the code \nonly needs to be compiled once. If you kill and restart the interpreter and then \nexecute the same code fragment again, there will be a much shorter delay in the \nfractions of seconds range. This is because weave stores a \ncatalog of all previously compiled functions in an on disk cache. When it sees \na string that has been compiled, it loads the already compiled module and \nexecutes the appropriate function. \n

        \n\nNote: If you try the printf example in a GUI shell such as IDLE, \nPythonWin, PyShell, etc., you're unlikely to see the output. This is because the \nC code is writing to stdout, instead of to the GUI window. This doesn't mean \nthat inline doesn't work in these environments -- it only means that standard \nout in C is not the same as the standard out for Python in these cases. Non \ninput/output functions will work as expected.\n\n

        \nAlthough effort has been made to reduce the overhead associated with calling \ninline, it is still less efficient for simple code snippets than using \nequivalent Python code. The simple printf example is actually \nslower by 30% or so than using Python print statement. And, it is \nnot difficult to create code fragments that are 8-10 times slower using inline \nthan equivalent Python. However, for more complicated algorithms, \nthe speed up can be worth while -- anywhwere from 1.5- 30 times faster. \nAlgorithms that have to manipulate Python objects (sorting a list) usually only \nsee a factor of 2 or so improvement. Algorithms that are highly computational \nor manipulate Numeric arrays can see much larger improvements. The \nexamples/vq.py file shows a factor of 30 or more improvement on the vector \nquantization algorithm that is used heavily in information theory and \nclassification problems.\n

        \n\n\n

        More with printf

        \n

        \nMSVC users will actually see a bit of compiler output that distutils does not\nsupress the first time the code executes:\n\n 

            \n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    sc_e013937dbc8c647ac62438874e5795131.cpp\n       Creating library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\n       \\Release\\sc_e013937dbc8c647ac62438874e5795131.lib and object C:\\DOCUME\n       ~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_e013937dbc8c64\n       7ac62438874e5795131.exp\n    1\n
        \n

        \nNothing bead is happening, its just a bit annoying. Anyone know how to \nturn this off? \n

        \nThis example also demonstrates using 'raw strings'. The r \npreceeding the code string in the last example denotes that this is a 'raw \nstring'. In raw strings, the backslash character is not interpreted as an \nescape character, and so it isn't necessary to use a double backslash to \nindicate that the '\\n' is meant to be interpreted in the C printf \nstatement instead of by Python. If your C code contains a lot\nof strings and control characters, raw strings might make things easier.\nMost of the time, however, standard strings work just as well.\n\n

        \nThe printf statement in these examples is formatted to print \nout integers. What happens if a is a string? inline\nwill happily, compile a new version of the code to accept strings as input,\nand execute the code. The result?\n\n 

            \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    32956972\n
        \n

        \nIn this case, the result is non-sensical, but also non-fatal. In other \nsituations, it might produce a compile time error because a is \nrequired to be an integer at some point in the code, or it could produce a \nsegmentation fault. Its possible to protect against passing \ninline arguments of the wrong data type by using asserts in \nPython.\n\n 

            \n    >>> a = 'string'\n    >>> def protected_printf(a):    \n    ...     assert(type(a) == type(1))\n    ...     weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    >>> protected_printf(1)\n     1\n    >>> protected_printf('string')\n    AssertError...\n
        \n\n

        \nFor printing strings, the format statement needs to be changed.\n\n 

            \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%s\\n\",a);',['a'])\n    string\n
        \n\n

        \nAs in this case, C/C++ code fragments often have to change to accept different \ntypes. For the given printing task, however, C++ streams provide a way of a \nsingle statement that works for integers and strings. By default, the stream \nobjects live in the std (standard) namespace and thus require the use of \nstd::.\n\n 

            \n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    1    \n    >>> a = 'string'\n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    string\n
        \n \n

        \nExamples using printf and cout are included in \nexamples/print_example.py.\n\n\n

        More examples

        \n\nThis section shows several more advanced uses of inline. It \nincludes a few algorithms from the Python Cookbook \nthat have been re-written in inline C to improve speed as well as a couple \nexamples using Numeric and wxPython.\n\n\n

        Binary search

        \nLets look at the example of searching a sorted list of integers for a value. \nFor inspiration, we'll use Kalle Svensson's \nbinary_search() algorithm from the Python Cookbook. His recipe follows:\n\n 
        \n    def binary_search(seq, t):\n        min = 0; max = len(seq) - 1\n        while 1:\n            if max < min:\n                return -1\n            m = (min  + max)  / 2\n            if seq[m] < t: \n                min = m  + 1 \n            elif seq[m] > t: \n                max = m  - 1 \n            else:\n                return m    \n
        \n\nThis Python version works for arbitrary Python data types. The C version below is \nspecialized to handle integer values. There is a little type checking done in \nPython to assure that we're working with the correct data types before heading \ninto C. The variables seq and t don't need to be \ndeclared beacuse weave handles converting and declaring them in \nthe C code. All other temporary variables such as min, max, etc. \nmust be declared -- it is C after all. Here's the new mixed Python/C function:\n\n 
            \n    def c_int_binary_search(seq,t):\n        # do a little type checking in Python\n        assert(type(t) == type(1))\n        assert(type(seq) == type([]))\n        \n        # now the C code\n        code = \"\"\"\n               #line 29 \"binary_search.py\"\n               int val, m, min = 0;  \n               int max = seq.length() - 1;\n               PyObject *py_val; \n               for(;;)\n               {\n                   if (max < min  ) \n                   { \n                       return_val =  Py::new_reference_to(Py::Int(-1)); \n                       break;\n                   } \n                   m =  (min + max) /2;\n                   val =    py_to_int(PyList_GetItem(seq.ptr(),m),\"val\"); \n                   if (val  < t) \n                       min = m  + 1;\n                   else if (val >  t)\n                       max = m - 1;\n                   else\n                   {\n                       return_val = Py::new_reference_to(Py::Int(m));\n                       break;\n                   }\n               }\n               \"\"\"\n        return inline(code,['seq','t'])\n
        \n

        \nWe have two variables seq and t passed in. \nt is guaranteed (by the assert) to be an integer. \nPython integers are converted to C int types in the transition from Python to \nC. seq is a Python list. By default, it is translated to a CXX \nlist object. Full documentation for the CXX library can be found at its website. The basics are that the CXX \nprovides C++ class equivalents for Python objects that simplify, or at \nleast object orientify, working with Python objects in C/C++. For example, \nseq.length() returns the length of the list. A little more about\nCXX and its class methods, etc. is in the ** type conversions ** section.\n

        \n\nNote: CXX uses templates and therefore may be a little less portable than \nanother alternative by Gordan McMillan called SCXX which was inspired by\nCXX. It doesn't use templates so it should compile faster and be more portable.\nSCXX has a few less features, but it appears to me that it would mesh with\nthe needs of weave quite well. Hopefully xxx_spec files will be written\nfor SCXX in the future, and we'll be able to compare on a more empirical\nbasis. Both sets of spec files will probably stick around, it just a question\nof which becomes the default.\n\n

        \nMost of the algorithm above looks similar in C to the original Python code. \nThere are two main differences. The first is the setting of \nreturn_val instead of directly returning from the C code with a \nreturn statement. return_val is an automatically \ndefined variable of type PyObject* that is returned from the C \ncode back to Python. You'll have to handle reference counting issues when \nsetting this variable. In this example, CXX classes and functions handle the \ndirty work. All CXX functions and classes live in the namespace \nPy::. The following code converts the integer m to a \nCXX Int() object and then to a PyObject* with an \nincremented reference count using Py::new_reference_to().\n\n 

           \n    return_val = Py::new_reference_to(Py::Int(m));\n
        \n

        \nThe second big differences shows up in the retrieval of integer values from the \nPython list. The simple Python seq[i] call balloons into a C \nPython API call to grab the value out of the list and then a separate call to \npy_to_int() that converts the PyObject* to an integer. \npy_to_int() includes both a NULL cheack and a \nPyInt_Check() call as well as the conversion call. If either of \nthe checks fail, an exception is raised. The entire C++ code block is executed \nwith in a try/catch block that handles exceptions much like Python \ndoes. This removes the need for most error checking code.\n

        \nIt is worth note that CXX lists do have indexing operators that result \nin code that looks much like Python. However, the overhead in using them \nappears to be relatively high, so the standard Python API was used on the \nseq.ptr() which is the underlying PyObject* of the \nList object.\n

        \nThe #line directive that is the first line of the C code \nblock isn't necessary, but it's nice for debugging. If the compilation fails \nbecause of the syntax error in the code, the error will be reported as an error \nin the Python file \"binary_search.py\" with an offset from the given line number \n(29 here).\n

        \nSo what was all our effort worth in terms of efficiency? Well not a lot in \nthis case. The examples/binary_search.py file runs both Python and C versions \nof the functions As well as using the standard bisect module. If \nwe run it on a 1 million element list and run the search 3000 times (for 0-\n2999), here are the results we get:\n\n 

           \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python binary_search.py\n    Binary search for 3000 items in 1000000 length list of integers:\n     speed in python: 0.159999966621\n     speed of bisect: 0.121000051498\n     speed up: 1.32\n     speed in c: 0.110000014305\n     speed up: 1.45\n     speed in c(no asserts): 0.0900000333786\n     speed up: 1.78\n
        \n

        \nSo, we get roughly a 50-75% improvement depending on whether we use the Python \nasserts in our C version. If we move down to searching a 10000 element list, \nthe advantage evaporates. Even smaller lists might result in the Python \nversion being faster. I'd like to say that moving to Numeric lists (and \ngetting rid of the GetItem() call) offers a substantial speed up, but my \npreliminary efforts didn't produce one. I think the log(N) algorithm is to \nblame. Because the algorithm is nice, there just isn't much time spent \ncomputing things, so moving to C isn't that big of a win. If there are ways to \nreduce conversion overhead of values, this may improve the C/Python speed \nup. Anyone have other explanations or faster code, please let me know.\n\n\n

        Dictionary Sort

        \n

        \nThe demo in examples/dict_sort.py is another example from the Python CookBook. \nThis \nsubmission, by Alex Martelli, demonstrates how to return the values from a \ndictionary sorted by their keys:\n\n 

               \n    def sortedDictValues3(adict):\n        keys = adict.keys()\n        keys.sort()\n        return map(adict.get, keys)\n
        \n

        \nAlex provides 3 algorithms and this is the 3rd and fastest of the set. The C \nversion of this same algorithm follows:\n\n 

               \n    def c_sort(adict):\n        assert(type(adict) == type({}))\n        code = \"\"\"     \n        #line 21 \"dict_sort.py\"  \n        Py::List keys = adict.keys();\n        Py::List items(keys.length()); keys.sort();     \n        PyObject* item = NULL; \n        for(int i = 0;  i < keys.length();i++)\n        {\n            item = PyList_GET_ITEM(keys.ptr(),i);\n            item = PyDict_GetItem(adict.ptr(),item);\n            Py_XINCREF(item);\n            PyList_SetItem(items.ptr(),i,item);              \n        }           \n        return_val = Py::new_reference_to(items);\n        \"\"\"   \n        return inline_tools.inline(code,['adict'],verbose=1)\n
        \n

        \nLike the original Python function, the C++ version can handle any Python \ndictionary regardless of the key/value pair types. It uses CXX objects for the \nmost part to declare python types in C++, but uses Python API calls to manipulate \ntheir contents. Again, this choice is made for speed. The C++ version, while\nmore complicated, is about a factor of 2 faster than Python.\n\n 

               \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python dict_sort.py\n    Dict sort of 1000 items for 300 iterations:\n     speed in python: 0.319999933243\n    [0, 1, 2, 3, 4]\n     speed in c: 0.151000022888\n     speed up: 2.12\n    [0, 1, 2, 3, 4]\n
        \n

        \n\n

        Numeric -- cast/copy/transpose

        \n\nCastCopyTranspose is a function called quite heavily by Linear Algebra routines\nin the Numeric library. Its needed in part because of the row-major memory layout\nof multi-demensional Python (and C) arrays vs. the col-major order of the underlying\nFortran algorithms. For small matrices (say 100x100 or less), a significant\nportion of the common routines such as LU decompisition or singular value decompostion\nare spent in this setup routine. This shouldn't happen. Here is the Python\nversion of the function using standard Numeric operations.\n\n 
               \n    def _castCopyAndTranspose(type, array):\n        if a.typecode() == type:\n            cast_array = copy.copy(Numeric.transpose(a))\n        else:\n            cast_array = copy.copy(Numeric.transpose(a).astype(type))\n        return cast_array\n
        \n\nAnd the following is a inline C version of the same function:\n\n 
        \n    from weave.blitz_tools import blitz_type_factories\n    from weave import scalar_spec\n    from weave import inline\n    def _cast_copy_transpose(type,a_2d):\n        assert(len(shape(a_2d)) == 2)\n        new_array = zeros(shape(a_2d),type)\n        numeric_type = scalar_spec.numeric_to_blitz_type_mapping[type]\n        code = \\\n        \"\"\"  \n        for(int i = 0;i < _Na_2d[0]; i++)  \n            for(int j = 0;  j < _Na_2d[1]; j++)\n                new_array(i,j) = (%s) a_2d(j,i);\n        \"\"\" % numeric_type\n        inline(code,['new_array','a_2d'],\n               type_factories = blitz_type_factories,compiler='gcc')\n        return new_array\n
        \n\nThis example uses blitz++ arrays instead of the standard representation of \nNumeric arrays so that indexing is simplier to write. This is accomplished by \npassing in the blitz++ \"type factories\" to override the standard Python to C++ \ntype conversions. Blitz++ arrays allow you to write clean, fast code, but they \nalso are sloooow to compile (20 seconds or more for this snippet). This is why \nthey aren't the default type used for Numeric arrays (and also because most \ncompilers can't compile blitz arrays...). inline() is also forced \nto use 'gcc' as the compiler because the default compiler on Windows (MSVC) \nwill not compile blitz code. 'gcc' I think will use the standard compiler \non Unix machine instead of explicitly forcing gcc (check this) \n\nComparisons of the Python vs inline C++ code show a factor of 3 speed up. Also \nshown are the results of an \"inplace\" transpose routine that can be used if the \noutput of the linear algebra routine can overwrite the original matrix (this is \noften appropriate). This provides another factor of 2 improvement.\n\n 
        \n     #C:\\home\\ej\\wrk\\scipy\\weave\\examples> python cast_copy_transpose.py\n    # Cast/Copy/Transposing (150,150)array 1 times\n    #  speed in python: 0.870999932289\n    #  speed in c: 0.25\n    #  speed up: 3.48\n    #  inplace transpose c: 0.129999995232\n    #  speed up: 6.70\n
        \n\n\n

        wxPython

        \n\ninline knows how to handle wxPython objects. Thats nice in and of\nitself, but it also demonstrates that the type conversion mechanism is reasonably \nflexible. Chances are, it won't take a ton of effort to support special types\nyou might have. The examples/wx_example.py borrows the scrolled window\nexample from the wxPython demo, accept that it mixes inline C code in the middle\nof the drawing function.\n\n 
        \n    def DoDrawing(self, dc):\n        \n        red = wxNamedColour(\"RED\");\n        blue = wxNamedColour(\"BLUE\");\n        grey_brush = wxLIGHT_GREY_BRUSH;\n        code = \\\n        \"\"\"\n        #line 108 \"wx_example.py\" \n        dc->BeginDrawing();\n        dc->SetPen(wxPen(*red,4,wxSOLID));\n        dc->DrawRectangle(5,5,50,50);\n        dc->SetBrush(*grey_brush);\n        dc->SetPen(wxPen(*blue,4,wxSOLID));\n        dc->DrawRectangle(15, 15, 50, 50);\n        \"\"\"\n        inline(code,['dc','red','blue','grey_brush'])\n        \n        dc.SetFont(wxFont(14, wxSWISS, wxNORMAL, wxNORMAL))\n        dc.SetTextForeground(wxColour(0xFF, 0x20, 0xFF))\n        te = dc.GetTextExtent(\"Hello World\")\n        dc.DrawText(\"Hello World\", 60, 65)\n\n        dc.SetPen(wxPen(wxNamedColour('VIOLET'), 4))\n        dc.DrawLine(5, 65+te[1], 60+te[0], 65+te[1])\n        ...\n
        \n\nHere, some of the Python calls to wx objects were just converted to C++ calls. There\nisn't any benefit, it just demonstrates the capabilities. You might want to use this\nif you have a computationally intensive loop in your drawing code that you want to \nspeed up.\n\nOn windows, you'll have to use the MSVC compiler if you use the standard wxPython\nDLLs distributed by Robin Dunn. Thats because MSVC and gcc, while binary\ncompatible in C, are not binary compatible for C++. In fact, its probably best, no \nmatter what platform you're on, to specify that inline use the same\ncompiler that was used to build wxPython to be on the safe side. There isn't currently\na way to learn this info from the library -- you just have to know. Also, at least\non the windows platform, you'll need to install the wxWindows libraries and link to \nthem. I think there is a way around this, but I haven't found it yet -- I get some\nlinking errors dealing with wxString. One final note. You'll probably have to\ntweak weave/wx_spec.py or weave/wx_info.py for your machine's configuration to\npoint at the correct directories etc. There. That should sufficiently scare people\ninto not even looking at this... :)\n\n        \n

        Keyword Options

        \n

        \nThe basic definition of the inline() function has a slew of \noptional variables. It also takes keyword arguments that are passed to \ndistutils as compiler options. The following is a formatted \ncut/paste of the argument section of inline's doc-string. It \nexplains all of the variables. Some examples using various options will \nfollow.\n\n 

               \n    def inline(code,arg_names,local_dict = None, global_dict = None, \n               force = 0, \n               compiler='',\n               verbose = 0, \n               support_code = None,\n               customize=None, \n               type_factories = None, \n               auto_downcast=1,\n               **kw):\n
        \n\n \ninline has quite \na few options as listed below. Also, the keyword arguments for distutils \nextension modules are accepted to specify extra information needed for \ncompiling. \n
        \n

        inline Arguments:

        \n
        \n
        \n
        code
        \n \n
        \nstring. A string of valid C++ code. It should not \n specify a return statement. Instead it should assign results that need to be \n returned to Python in the return_val. \n
        \n\n
        arg_names
        \n \n
        \nlist of strings. A list of Python variable names \n that should be transferred from Python into the C/C++ code. \n
        \n\n
        local_dict
        \n \n
        \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the local scope for the C/C++ \n code. If local_dict is not specified the local dictionary of the calling \n function is used. \n
        \n\n
        global_dict
        \n \n
        \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the global scope for the C/C++ \n code. If global_dict is not specified the global dictionary of the calling \n function is used. \n
        \n\n
        force
        \n \n
        \noptional. 0 or 1. default 0. If 1, the C++ code is \n compiled every time inline is called. This is really only useful for \n debugging, and probably only useful if you're editing support_code a lot. \n
        \n\n
        compiler
        \n \n
        \noptional. string. The name of compiler to use when compiling. On windows, it \nunderstands 'msvc' and 'gcc' as well as all the compiler names understood by \ndistutils. On Unix, it'll only understand the values understoof by distutils. \n(I should add 'gcc' though to this).\n

        \nOn windows, the compiler defaults to the Microsoft C++ compiler. If this isn't \navailable, it looks for mingw32 (the gcc compiler).\n

        \nOn Unix, it'll probably use the same compiler that was used when compiling \nPython. Cygwin's behavior should be similar.

        \n
        \n\n
        verbose
        \n \n
        \noptional. 0,1, or 2. defualt 0. Speficies how much \n much information is printed during the compile phase of inlining code. 0 is \n silent (except on windows with msvc where it still prints some garbage). 1 \n informs you when compiling starts, finishes, and how long it took. 2 prints \n out the command lines for the compilation process and can be useful if you're \n having problems getting code to work. Its handy for finding the name of the \n .cpp file if you need to examine it. verbose has no affect if the \n compilation isn't necessary. \n
        \n\n
        support_code
        \n \n
        \noptional. string. A string of valid C++ code \n declaring extra code that might be needed by your compiled function. This \n could be declarations of functions, classes, or structures. \n
        \n\n
        customize
        \n \n
        \noptional. base_info.custom_info object. An \n alternative way to specifiy support_code, headers, etc. needed by the \n function see the weave.base_info module for more details. (not sure \n this'll be used much). \n \n
        \n
        type_factories
        \n \n
        \noptional. list of type specification factories. These guys are what convert \nPython data types to C/C++ data types. If you'd like to use a different set of \ntype conversions than the default, specify them here. Look in the type \nconversions section of the main documentation for examples.\n
        \n
        auto_downcast
        \n \n
        \noptional. 0 or 1. default 1. This only affects functions that have Numeric \narrays as input variables. Setting this to 1 will cause all floating point \nvalues to be cast as float instead of double if all the Numeric arrays are of \ntype float. If even one of the arrays has type double or double complex, all \nvariables maintain there standard types.\n
        \n
        \n
        \n\n

        Distutils keywords:

        \n
        \ninline() also accepts a number of distutils keywords \nfor controlling how the code is compiled. The following descriptions have been \ncopied from Greg Ward's distutils.extension.Extension class doc-\nstrings for convenience:\n\n
        \n
        sources
        \n \n
        \n[string] list of source filenames, relative to the \n distribution root (where the setup script lives), in Unix form \n (slash-separated) for portability. Source files may be C, C++, SWIG (.i), \n platform-specific resource files, or whatever else is recognized by the \n \"build_ext\" command as source for a Python extension. Note: The module_path \n file is always appended to the front of this list \n
        \n\n
        include_dirs
        \n \n
        \n[string] list of directories to search for C/C++ \n header files (in Unix form for portability) \n
        \n\n
        define_macros
        \n \n
        \n[(name : string, value : string|None)] list of \n macros to define; each macro is defined using a 2-tuple, where 'value' is \n either the string to define it to or None to define it without a particular \n value (equivalent of \"#define FOO\" in source or -DFOO on Unix C compiler \n command line) \n
        \n
        undef_macros
        \n \n
        \n[string] list of macros to undefine explicitly \n
        \n
        library_dirs
        \n
        \n[string] list of directories to search for C/C++ libraries at link time \n
        \n
        libraries
        \n
        \n[string] list of library names (not filenames or paths) to link against \n
        \n
        runtime_library_dirs
        \n
        \n[string] list of directories to search for C/C++ libraries at run time (for \nshared extensions, this is when the extension is loaded) \n
        \n\n
        extra_objects
        \n \n
        \n[string] list of extra files to link with (eg. \n object files not implied by 'sources', static library that must be \n explicitly specified, binary resource files, etc.) \n
        \n\n
        extra_compile_args
        \n \n
        \n[string] any extra platform- and compiler-specific \n information to use when compiling the source files in 'sources'. For \n platforms and compilers where \"command line\" makes sense, this is typically \n a list of command-line arguments, but for other platforms it could be \n anything. \n
        \n
        extra_link_args
        \n \n
        \n[string] any extra platform- and compiler-specific \n information to use when linking object files together to create the \n extension (or to create a new static Python interpreter). Similar \n interpretation as for 'extra_compile_args'. \n
        \n
        export_symbols
        \n \n
        \n[string] list of symbols to be exported from a shared extension. Not used on \nall platforms, and not generally necessary for Python extensions, which \ntypically export exactly one symbol: \"init\" + extension_name. \n
        \n
        \n
        \n\n\n

        Keyword Option Examples

        \nWe'll walk through several examples here to demonstrate the behavior of \ninline and also how the various arguments are used.\n\nIn the simplest (most) cases, code and arg_names\nare the only arguments that need to be specified. Here's a simple example\nrun on Windows machine that has Microsoft VC++ installed.\n\n 
        \n    >>> from weave import inline\n    >>> a = 'string'\n    >>> code = \"\"\"\n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));\n    ...        \"\"\"\n    >>> inline(code,['a'])\n     sc_86e98826b65b047ffd2cd5f479c627f12.cpp\n    Creating\n       library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f12.lib\n    and object C:\\DOCUME~ 1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ff\n    d2cd5f479c627f12.exp\n    6\n    >>> inline(code,['a'])\n    6\n
        \n \nWhen inline is first run, you'll notice that pause and some \ntrash printed to the screen. The \"trash\" is acutually part of the compilers\noutput that distutils does not supress. On Unix or windows machines with only\ngcc installed, the trash will not appear. On the second call, the code \nfragment is not compiled since it already exists, and only the answer is \nreturned. Now kill the interpreter and restart, and run the same code with\na different string.\n\n 
        \n    >>> from weave import inline\n    >>> a = 'a longer string' \n    >>> code = \"\"\" \n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));  \n    ...        \"\"\"\n    >>> inline(code,['a'])\n    15\n
        \n

        \nNotice this time, inline() did not recompile the code because it\nfound the compiled function in the persistent catalog of functions. There is\na short pause as it looks up and loads the function, but it is much shorter \nthan compiling would require.\n

        \nYou can specify the local and global dictionaries if you'd like (much like \nexec or eval() in Python), but if they aren't \nspecified, the \"expected\" ones are used -- i.e. the ones from the function that \ncalled inline() . This is accomplished through a little call \nframe trickery. Here is an example where the local_dict is specified using\nthe same code example from above:\n\n 

        \n    >>> a = 'a longer string'\n    >>> b = 'an even  longer string' \n    >>> my_dict = {'a':b}\n    >>> inline(code,['a'])\n    15\n    >>> inline(code,['a'],my_dict)\n    21\n
        \n \n

        \nEverytime, the code is changed, inline does a \nrecompile. However, changing any of the other options in inline does not\nforce a recompile. The force option was added so that one\ncould force a recompile when tinkering with other variables. In practice,\nit is just as easy to change the code by a single character\n(like adding a space some place) to force the recompile. Note: It also \nmight be nice to add some methods for purging the cache and on disk \ncatalogs.\n

        \nI use verbose sometimes for debugging. When set to 2, it'll \noutput all the information (including the name of the .cpp file) that you'd\nexpect from running a make file. This is nice if you need to examine the\ngenerated code to see where things are going haywire. Note that error\nmessages from failed compiles are printed to the screen even if verbose\n is set to 0.\n

        \nThe following example demonstrates using gcc instead of the standard msvc \ncompiler on windows using same code fragment as above. Because the example has \nalready been compiled, the force=1 flag is needed to make \ninline() ignore the previously compiled version and recompile \nusing gcc. The verbose flag is added to show what is printed out:\n\n 

        \n    >>>inline(code,['a'],compiler='gcc',verbose=2,force=1)\n    running build_ext    \n    building 'sc_86e98826b65b047ffd2cd5f479c627f13' extension \n    c:\\gcc-2.95.2\\bin\\g++.exe -mno-cygwin -mdll -O2 -w -Wstrict-prototypes -IC:\n    \\home\\ej\\wrk\\scipy\\weave -IC:\\Python21\\Include -c C:\\DOCUME~1\\eric\\LOCAL\n    S~1\\Temp\\python21_compiled\\sc_86e98826b65b047ffd2cd5f479c627f13.cpp -o C:\\D\n    OCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b04\n    7ffd2cd5f479c627f13.o    \n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxextensions.c (C:\\DOCUME~1\\eri\n    c\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxextensions.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxsupport.cxx (C:\\DOCUME~1\\eric\n    \\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxsupport.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\IndirectPythonInterface.cxx (C:\\\n    DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\indirectpythonin\n    terface.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxx_extensions.cxx (C:\\DOCUME~1\\\n    eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxx_extensions.o up-to-da\n    te)\n    writing C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86\n    e98826b65b047ffd2cd5f479c627f13.def\n    c:\\gcc-2.95.2\\bin\\dllwrap.exe --driver-name g++ -mno-cygwin -mdll -static -\n    -output-lib C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\l\n    ibsc_86e98826b65b047ffd2cd5f479c627f13.a --def C:\\DOCUME~1\\eric\\LOCALS~1\\Te\n    mp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f13.def \n    -s C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e9882\n    6b65b047ffd2cd5f479c627f13.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compil\n    ed\\temp\\Release\\cxxextensions.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\cxxsupport.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\indirectpythoninterface.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\n    \\python21_compiled\\temp\\Release\\cxx_extensions.o -LC:\\Python21\\libs -lpytho\n    n21 -o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\sc_86e98826b65b047f\n    fd2cd5f479c627f13.pyd\n    15\n
        \n\nThat's quite a bit of output. verbose=1 just prints the compile\ntime.\n\n 
        \n    >>>inline(code,['a'],compiler='gcc',verbose=1,force=1)\n    Compiling code...\n    finished compiling (sec):  6.00800001621\n    15\n
        \n\n

        \n Note: I've only used the weave option for switching between 'msvc'\nand 'gcc' on windows. It may have use on Unix also, but I don't know yet.\n\n\n

        \nThe support_code argument is likely to be used a lot. It allows \nyou to specify extra code fragments such as function, structure or class \ndefinitions that you want to use in the code string. Note that \nchanges to support_code do not force a recompile. The \ncatalog only relies on code (for performance reasons) to determine \nwhether recompiling is necessary. So, if you make a change to support_code, \nyou'll need to alter code in some way or use the \nforce argument to get the code to recompile. I usually just add \nsome inocuous whitespace to the end of one of the lines in code \nsomewhere. Here's an example of defining a separate method for calculating\nthe string length:\n\n 

        \n    >>> from weave import inline\n    >>> a = 'a longer string'\n    >>> support_code = \"\"\"\n    ...                PyObject* length(Py::String a)\n    ...                {\n    ...                    int l = a.length();  \n    ...                    return Py::new_reference_to(Py::Int(l)); \n    ...                }\n    ...                \"\"\"        \n    >>> inline(\"return_val = length(a);\",['a'],\n    ...        support_code = support_code)\n    15\n
        \n

        \ncustomize is a left over from a previous way of specifying \ncompiler options. It is a custom_info object that can specify \nquite a bit of information about how a file is compiled. These \ninfo objects are the standard way of defining compile information \nfor type conversion classes. However, I don't think they are as handy here, \nespecially since we've exposed all the keyword arguments that distutils can \nhandle. Between these keywords, and the support_code option, I \nthink customize may be obsolete. We'll see if anyone cares to use \nit. If not, it'll get axed in the next version.\n

        \nThe type_factories variable is important to people who want to\ncustomize the way arguments are converted from Python to C. We'll talk about\nthis in the next chapter **xx** of this document when we discuss type\nconversions.\n

        \nauto_downcast handles one of the big type conversion issues that\nis common when using Numeric arrays in conjunction with Python scalar values.\nIf you have an array of single precision values and multiply that array by a \nPython scalar, the result is upcast to a double precision array because the\nscalar value is double precision. This is not usually the desired behavior\nbecause it can double your memory usage. auto_downcast goes\nsome distance towards changing the casting precedence of arrays and scalars.\nIf your only using single precision arrays, it will automatically downcast all\nscalar values from double to single precision when they are passed into the\nC++ code. This is the default behavior. If you want all values to keep there\ndefault type, set auto_downcast to 0.\n

        \n\n\n\n

        Returning Values

        \n\nPython variables in the local and global scope transfer seemlessly from Python \ninto the C++ snippets. And, if inline were to completely live up\nto its name, any modifications to variables in the C++ code would be reflected\nin the Python variables when control was passed back to Python. For example,\nthe desired behavior would be something like:\n\n 
        \n    # THIS DOES NOT WORK\n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    2\n
        \n\nInstead you get:\n\n 
        \n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    1\n
        \n \nVariables are passed into C++ as if you are calling a Python function. Python's \ncalling convention is sometimes called \"pass by assignment\". This means its as \nif a c_a = a assignment is made right before inline \ncall is made and the c_a variable is used within the C++ code. \nThus, any changes made to c_a are not reflected in Python's \na variable. Things do get a little more confusing, however, when \nlooking at variables with mutable types. Changes made in C++ to the contents \nof mutable types are reflected in the Python variables.\n\n 
        \n    >>> a= [1,2]\n    >>> weave.inline(\"PyList_SetItem(a.ptr(),0,PyInt_FromLong(3));\",['a'])\n    >>> print a\n    [3, 2]\n
        \n\nSo modifications to the contents of mutable types in C++ are seen when control\nis returned to Python. Modifications to immutable types such as tuples,\nstrings, and numbers do not alter the Python variables.\n\nIf you need to make changes to an immutable variable, you'll need to assign\nthe new value to the \"magic\" variable return_val in C++. This\nvalue is returned by the inline() function:\n\n 
        \n    >>> a = 1\n    >>> a = weave.inline(\"return_val = Py::new_reference_to(Py::Int(a+1));\",['a'])  \n    >>> a\n    2\n
        \n\nThe return_val variable can also be used to return newly created \nvalues. This is possible by returning a tuple. The following trivial example \nillustrates how this can be done:\n\n 
               \n    # python version\n    def multi_return():\n        return 1, '2nd'\n    \n    # C version.\n    def c_multi_return():    \n        code =  \"\"\"\n     \t        Py::Tuple results(2);\n     \t        results[0] = Py::Int(1);\n     \t        results[1] = Py::String(\"2nd\");\n     \t        return_val = Py::new_reference_to(results); \t        \n                \"\"\"\n        return inline_tools.inline(code)\n
        \n

        \nThe example is available in examples/tuple_return.py. It also\nhas the dubious honor of demonstrating how much inline() can \nslow things down. The C version here is about 10 times slower than the Python\nversion. Of course, something so trivial has no reason to be written in\nC anyway.\n\n\n

        The issue with locals()

        \n

        \ninline passes the locals() and globals() \ndictionaries from Python into the C++ function from the calling function. It \nextracts the variables that are used in the C++ code from these dictionaries, \nconverts then to C++ variables, and then calculates using them. It seems like \nit would be trivial, then, after the calculations were finished to then insert \nthe new values back into the locals() and globals() \ndictionaries so that the modified values were reflected in Python. \nUnfortunately, as pointed out by the Python manual, the locals() dictionary is \nnot writable. \n

        \n\nI suspect locals() is not writable because there are some \noptimizations done to speed lookups of the local namespace. I'm guessing local \nlookups don't always look at a dictionary to find values. Can someone \"in the \nknow\" confirm or correct this? Another thing I'd like to know is whether there \nis a way to write to the local namespace of another stack frame from C/C++. If \nso, it would be possible to have some clean up code in compiled functions that \nwrote final values of variables in C++ back to the correct Python stack frame. \nI think this goes a long way toward making inline truely live up \nto its name. I don't think we'll get to the point of creating variables in \nPython for variables created in C -- although I suppose with a C/C++ parser you \ncould do that also.\n\n

        \n\n\n

        A quick look at the code

        \n\nweave generates a C++ file holding an extension function for \neach inline code snippet. These file names are generated using \nfrom the md5 signature of the code snippet and saved to a location specified by \nthe PYTHONCOMPILED environment variable (discussed later). The cpp files are \ngenerally about 200-400 lines long and include quite a few functions to support \ntype conversions, etc. However, the actual compiled function is pretty simple. \nBelow is the familiar printf example:\n\n 
        \n    >>> import weave    \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
        \n\nAnd here is the extension function generated by inline:\n\n 
        \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        // The Py_None needs an incref before returning\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n        \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try                              \n        {                                \n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n            /* Here is the inline code */            \n            printf(\"%d\\n\",a);\n            /* I would like to fill in changed locals and globals here... */\n        }                                       \n        catch( Py::Exception& e)           \n        {                                \n            return_val =  Py::Null();    \n            exception_occured = 1;       \n        }                                 \n        if(!return_val && !exception_occured)\n        {\n                                      \n            Py_INCREF(Py_None);              \n            return_val = Py_None;            \n        }\n        /* clean up code */\n        \n        /* return */                              \n        return return_val;           \n    }                                \n
        \n\nEvery inline function takes exactly two arguments -- the local and global\ndictionaries for the current scope. All variable values are looked up out\nof these dictionaries. The lookups, along with all inline code \nexecution, are done within a C++ try block. If the variables\naren't found, or there is an error converting a Python variable to the \nappropriate type in C++, an exception is raised. The C++ exception\nis automatically converted to a Python exception by CXX and returned to Python.\n\nThe py_to_int() function illustrates how the conversions and\nexception handling works. py_to_int first checks that the given PyObject*\npointer is not NULL and is a Python integer. If all is well, it calls the\nPython API to convert the value to an int. Otherwise, it calls\nhandle_bad_type() which gathers information about what went wrong\nand then raises a CXX TypeError which returns to Python as a TypeError.\n\n 
        \n    int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
        \n\n 
        \n    void handle_bad_type(PyObject* py_obj, char* good_type, char*  var_name)\n    {\n        char msg[500];\n        sprintf(msg,\"received '%s' type instead of '%s' for variable '%s'\",\n                find_type(py_obj),good_type,var_name);\n        throw Py::TypeError(msg);\n    }\n    \n    char* find_type(PyObject* py_obj)\n    {\n        if(py_obj == NULL) return \"C NULL value\";\n        if(PyCallable_Check(py_obj)) return \"callable\";\n        if(PyString_Check(py_obj)) return \"string\";\n        if(PyInt_Check(py_obj)) return \"int\";\n        if(PyFloat_Check(py_obj)) return \"float\";\n        if(PyDict_Check(py_obj)) return \"dict\";\n        if(PyList_Check(py_obj)) return \"list\";\n        if(PyTuple_Check(py_obj)) return \"tuple\";\n        if(PyFile_Check(py_obj)) return \"file\";\n        if(PyModule_Check(py_obj)) return \"module\";\n        \n        //should probably do more interagation (and thinking) on these.\n        if(PyCallable_Check(py_obj) && PyInstance_Check(py_obj)) return \"callable\";\n        if(PyInstance_Check(py_obj)) return \"instance\"; \n        if(PyCallable_Check(py_obj)) return \"callable\";\n        return \"unkown type\";\n    }\n
        \n\nSince the inline is also executed within the try/catch\nblock, you can use CXX exceptions within your code. It is usually a bad idea\nto directly return from your code, even if an error occurs. This\nskips the clean up section of the extension function. In this simple example,\nthere isn't any clean up code, but in more complicated examples, there may\nbe some reference counting that needs to be taken care of here on converted\nvariables. To avoid this, either uses exceptions or set \nreturn_val to NULL and use if/then's to skip code\nafter errors.\n\n\n

        Technical Details

        \n

        \nThere are \n

          \n
        1. Type conversion \n
        2. Generating C/C++ code \n
        3. Compile the code to an extension module \n
        4. Catalog (and cache) the function for future use
          5. \n
        \n

        \nItems 1 and 2 above are related, but most easily discussed separately. Type \nconversions are customizable by the user if needed. Understanding them is \npretty important for anything beyond trivial uses of inline. \nGenerating the C/C++ code is handled by ext_function and \next_module classes and . For the most part, compiling the code is \nhandled by distutils. Some customizations were needed, but they were \nrelatively minor and do not require changes to distutils itself. Cataloging is \npretty simple in concept, but surprisingly required the most code to implement \n(and still likely needs some work). So, this section covers items 1 and 4 from \nthe list. Item 2 is covered later in the chapter covering the \next_tools module, and distutils is covered by a completely \nseparate document xxx.\n\n

        Passing Variables in/out of the C/C++ code

        \n\nNote: Passing variables into the C code is pretty straight forward, but there \nare subtlties to how variable modifications in C are returned to Python. see Returning Values for a more thorough discussion of \nthis issue.\n \n \n\n

        Type Conversions

        \n\n\nNote: Maybe xxx_converter instead of \nxxx_specification is a more descriptive name. Might change in \nfuture version?\n\n\n

        \nBy default, inline() makes the following type conversions between\nPython and C++ types.\n

        \n\n

        \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
        \n

        Default Data Type Conversions

        \n

        Python

        		\n

        C++

           int   int
           float   double
           complex   std::complex
           string   Py::String
           list   Py::List
           dict   Py::Dict
           tuple   Py::Tuple
           file   FILE*
           callable   PyObject*
           instance   PyObject*
           Numeric.array   PyArrayObject*
           wxXXX   wxXXX*
        \n
        \n

        \nThe Py:: namespace is defined by the \nCXX library which has C++ class\nequivalents for many Python types. std:: is the namespace of the\nstandard library in C++.\n

        \n\nNote: \n

          \n
        • I haven't figured out how to handle long int yet (I think they are currenlty converted \n to int - - check this). \n \n
        • \nHopefully VTK will be added to the list soon
          • \n
        \n\n

        \n\nPython to C++ conversions fill in code in several locations in the generated\ninline extension function. Below is the basic template for the\nfunction. This is actually the exact code that is generated by calling\nweave.inline(\"\").\n\n 

        \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n    \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try\n        {\n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            /* argument conversion code */\n            /* inline code */\n            /*I would like to fill in changed locals and globals here...*/\n    \n        }\n        catch( Py::Exception& e)\n        {\n            return_val =  Py::Null();\n            exception_occured = 1;\n        }\n        /* cleanup code */\n        if(!return_val && !exception_occured)\n        {\n    \n            Py_INCREF(Py_None);\n            return_val = Py_None;\n        }\n    \n        return return_val;\n    }\n
        \n\nThe /* inline code */ section is filled with the code passed to\nthe inline() function call. The \n/*argument convserion code*/ and /* cleanup code */\nsections are filled with code that handles conversion from Python to C++\ntypes and code that deallocates memory or manipulates reference counts before\nthe function returns. The following sections demostrate how these two areas\nare filled in by the default conversion methods.\n\n \nNote: I'm not sure I have reference counting correct on a few of these. The \nonly thing I increase/decrease the ref count on is Numeric arrays. If you\nsee an issue, please let me know.\n\n\n\n

        Numeric Argument Conversion

        \n\nInteger, floating point, and complex arguments are handled in a very similar\nfashion. Consider the following inline function that has a single integer \nvariable passed in:\n\n 
        \n    >>> a = 1\n    >>> inline(\"\",['a'])\n
        \n\nThe argument conversion code inserted for a is:\n\n 
        \n    /* argument conversion code */\n    int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
        \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_int() has the following\nform:\n\n 
        \n    static int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
        \n\nSimilarly, the float and complex conversion routines look like:\n\n 
            \n    static double py_to_float(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyFloat_Check(py_obj))\n            handle_bad_type(py_obj,\"float\", name);\n        return PyFloat_AsDouble(py_obj);\n    }\n    \n    static std::complex py_to_complex(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyComplex_Check(py_obj))\n            handle_bad_type(py_obj,\"complex\", name);\n        return std::complex(PyComplex_RealAsDouble(py_obj),\n                                    PyComplex_ImagAsDouble(py_obj));    \n    }\n
        \n\nNumeric conversions do not require any clean up code.\n\n\n

        String, List, Tuple, and Dictionary Conversion

        \n\nStrings, Lists, Tuples and Dictionary conversions are all converted to \nCXX types by default.\n\nFor the following code, \n\n 
        \n    >>> a = [1]\n    >>> inline(\"\",['a'])\n
        \n\nThe argument conversion code inserted for a is:\n\n 
        \n    /* argument conversion code */\n    Py::List a = py_to_list (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
        \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_list() and its\nfriends has the following form:\n\n 
            \n    static Py::List py_to_list(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyList_Check(py_obj))\n            handle_bad_type(py_obj,\"list\", name);\n        return Py::List(py_obj);\n    }\n    \n    static Py::String py_to_string(PyObject* py_obj,char* name)\n    {\n        if (!PyString_Check(py_obj))\n            handle_bad_type(py_obj,\"string\", name);\n        return Py::String(py_obj);\n    }\n\n    static Py::Dict py_to_dict(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyDict_Check(py_obj))\n            handle_bad_type(py_obj,\"dict\", name);\n        return Py::Dict(py_obj);\n    }\n    \n    static Py::Tuple py_to_tuple(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyTuple_Check(py_obj))\n            handle_bad_type(py_obj,\"tuple\", name);\n        return Py::Tuple(py_obj);\n    }\n
        \n\nCXX handles reference counts on for strings, lists, tuples, and dictionaries,\nso clean up code isn't necessary.\n\n\n

        File Conversion

        \n\nFor the following code, \n\n 
        \n    >>> a = open(\"bob\",'w')  \n    >>> inline(\"\",['a'])\n
        \n\nThe argument conversion code is:\n\n 
        \n    /* argument conversion code */\n    PyObject* py_a = get_variable(\"a\",raw_locals,raw_globals);\n    FILE* a = py_to_file(py_a,\"a\");\n
        \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_file() converts\nPyObject* to a FILE* and increments the reference count of the PyObject*:\n\n 
        \n    FILE* py_to_file(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"file\", name);\n    \n        Py_INCREF(py_obj);\n        return PyFile_AsFile(py_obj);\n    }\n
        \n\nBecause the PyObject* was incremented, the clean up code needs to decrement\nthe counter\n\n 
        \n    /* cleanup code */\n    Py_XDECREF(py_a);\n
        \n\nIts important to understand that file conversion only works on actual files --\ni.e. ones created using the open() command in Python. It does\nnot support converting arbitrary objects that support the file interface into\nC FILE* pointers. This can affect many things. For example, in\ninitial printf() examples, one might be tempted to solve the \nproblem of C and Python IDE's (PythonWin, PyCrust, etc.) writing to different\nstdout and stderr by using fprintf() and passing in \nsys.stdout and sys.stderr. For example, instead of\n\n 
        \n    >>> weave.inline('printf(\"hello\\\\n\");')\n
        \n \nYou might try:\n\n 
        \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n
        \n\nThis will work as expected from a standard python interpreter, but in PythonWin,\nthe following occurs:\n\n 
        \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n    Traceback (most recent call last):\n        File \"\", line 1, in ?\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 315, in inline\n            auto_downcast = auto_downcast,\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 386, in compile_function\n            type_factories = type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 197, in __init__\n            auto_downcast, type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 390, in assign_variable_types\n            raise TypeError, format_error_msg(errors)\n        TypeError: {'buf': \"Unable to convert variable 'buf' to a C++ type.\"}\n
        \n\nThe traceback tells us that inline() was unable to convert 'buf' to a\nC++ type (If instance conversion was implemented, the error would have occurred at \nruntime instead). Why is this? Let's look at what the buf object \nreally is:\n\n 
        \n    >>> buf\n    pywin.framework.interact.InteractiveView instance at 00EAD014\n
        \n\nPythonWin has reassigned sys.stdout to a special object that \nimplements the Python file interface. This works great in Python, but since \nthe special object doesn't have a FILE* pointer underlying it, fprintf doesn't \nknow what to do with it (well this will be the problem when instance conversion \nis implemented...).\n\n\n

        Callable, Instance, and Module Conversion

        \n\nNote: Need to look into how ref counts should be handled. Also,\nInstance and Module conversion are not currently implemented.\n\n\n 
        \n    >>> def a(): \n        pass\n    >>> inline(\"\",['a'])\n
        \n\nCallable and instance variables are converted to PyObject*. Nothing is done\nto there reference counts.\n\n 
        \n    /* argument conversion code */\n    PyObject* a = py_to_callable(get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
        \n\nget_variable() reads the variable a\nfrom the local and global namespaces. The py_to_callable() and\npy_to_instance() don't currently increment the ref count.\n\n 
            \n    PyObject* py_to_callable(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyCallable_Check(py_obj))\n            handle_bad_type(py_obj,\"callable\", name);    \n        return py_obj;\n    }\n\n    PyObject* py_to_instance(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"instance\", name);    \n        return py_obj;\n    }\n
        \n \nThere is no cleanup code for callables, modules, or instances.\n\n\n

        Customizing Conversions

        \n

        \nConverting from Python to C++ types is handled by xxx_specification classes. A \ntype specification class actually serve in two related but different \nroles. The first is in determining whether a Python variable that needs to be \nconverted should be represented by the given class. The second is as a code \ngenerator that generate C++ code needed to convert from Python to C++ types for \na specific variable.\n

        \nWhen \n\n 

        \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\",a);',['a'])\n
        \n \nis called for the first time, the code snippet has to be compiled. In this \nprocess, the variable 'a' is tested against a list of type specifications (the \ndefault list is stored in weave/ext_tools.py). The first \nspecification in the list is used to represent the variable. \n\n

        \nExamples of xxx_specification are scattered throughout numerous \n\"xxx_spec.py\" files in the weave package. Closely related to \nthe xxx_specification classes are yyy_info classes. \nThese classes contain compiler, header, and support code information necessary \nfor including a certain set of capabilities (such as blitz++ or CXX support)\nin a compiled module. xxx_specification classes have one or more\nyyy_info classes associated with them.\n\nIf you'd like to define your own set of type specifications, the current best route\nis to examine some of the existing spec and info files. Maybe looking over\nsequence_spec.py and cxx_info.py are a good place to start. After defining \nspecification classes, you'll need to pass them into inline using the \ntype_factories argument. \n\nA lot of times you may just want to change how a specific variable type is \nrepresented. Say you'd rather have Python strings converted to \nstd::string or maybe char* instead of using the CXX \nstring object, but would like all other type conversions to have default \nbehavior. This requires that a new specification class that handles strings\nis written and then prepended to a list of the default type specifications. Since\nit is closer to the front of the list, it effectively overrides the default\nstring specification.\n\nThe following code demonstrates how this is done:\n\n...\n\n\n

        The Catalog

        \n

        \ncatalog.py has a class called catalog that helps keep \ntrack of previously compiled functions. This prevents inline() \nand related functions from having to compile functions everytime they are \ncalled. Instead, catalog will check an in memory cache to see if the function \nhas already been loaded into python. If it hasn't, then it starts searching \nthrough persisent catalogs on disk to see if it finds an entry for the given \nfunction. By saving information about compiled functions to disk, it isn't\nnecessary to re-compile functions everytime you stop and restart the interpreter.\nFunctions are compiled once and stored for future use.\n\n

        \nWhen inline(cpp_code) is called the following things happen:\n

          \n
        1. \n A fast local cache of functions is checked for the last function called for \n cpp_code. If an entry for cpp_code doesn't exist in the \n cache or the cached function call fails (perhaps because the function doesn't \n have compatible types) then the next step is to check the catalog. \n
        2. \n The catalog class also keeps an in-memory cache with a list of all the \n functions compiled for cpp_code. If cpp_code has\n ever been called, then this cache will be present (loaded from disk). If\n the cache isn't present, then it is loaded from disk.\n

          \n If the cache is present, each function in the cache is \n called until one is found that was compiled for the correct argument types. If \n none of the functions work, a new function is compiled with the given argument \n types. This function is written to the on-disk catalog as well as into the \n in-memory cache.

          \n
        3. \n When a lookup for cpp_code fails, the catalog looks through \n the on-disk function catalogs for the entries. The PYTHONCOMPILED variable \n determines where to search for these catalogs and in what order. If \n PYTHONCOMPILED is not present several platform dependent locations are \n searched. All functions found for cpp_code in the path are \n loaded into the in-memory cache with functions found earlier in the search \n path closer to the front of the call list.\n

          \n If the function isn't found in the on-disk catalog, \n then the function is compiled, written to the first writable directory in the \n PYTHONCOMPILED path, and also loaded into the in-memory cache.

          \n
          4. \n
        \n\n\n

        Function Storage: How functions are stored in caches and on disk

        \n

        \nFunction caches are stored as dictionaries where the key is the entire C++\ncode string and the value is either a single function (as in the \"level 1\"\ncache) or a list of functions (as in the main catalog cache). On disk\ncatalogs are stored in the same manor using standard Python shelves.\n

        \nEarly on, there was a question as to whether md5 check sums of the C++\ncode strings should be used instead of the actual code strings. I think this\nis the route inline Perl took. Some (admittedly quick) tests of the md5 vs.\nthe entire string showed that using the entire string was at least a\nfactor of 3 or 4 faster for Python. I think this is because it is more\ntime consuming to compute the md5 value than it is to do look-ups of long\nstrings in the dictionary. Look at the examples/md5_speed.py file for the\ntest run. \n\n\n

        Catalog search paths and the PYTHONCOMPILED variable

        \n

        \nThe default location for catalog files on Unix is is ~/.pythonXX_compiled where \nXX is version of Python being used. If this directory doesn't exist, it is \ncreated the first time a catalog is used. The directory must be writable. If, \nfor any reason it isn't, then the catalog attempts to create a directory based \non your user id in the /tmp directory. The directory permissions are set so \nthat only you have access to the directory. If this fails, I think you're out of \nluck. I don't think either of these should ever fail though. On Windows, a \ndirectory called pythonXX_compiled is created in the user's temporary \ndirectory. \n

        \nThe actual catalog file that lives in this directory is a Python shelve with\na platform specific name such as \"nt21compiled_catalog\" so that multiple OSes\ncan share the same file systems without trampling on each other. Along with\nthe catalog file, the .cpp and .so or .pyd files created by inline will live\nin this directory. The catalog file simply contains keys which are the C++\ncode strings with values that are lists of functions. The function lists point\nat functions within these compiled modules. Each function in the lists \nexecutes the same C++ code string, but compiled for different input variables.\n

        \nYou can use the PYTHONCOMPILED environment variable to specify alternative\nlocations for compiled functions. On Unix this is a colon (':') separated\nlist of directories. On windows, it is a (';') separated list of directories.\nThese directories will be searched prior to the default directory for a\ncompiled function catalog. Also, the first writable directory in the list\nis where all new compiled function catalogs, .cpp and .so or .pyd files are\nwritten. Relative directory paths ('.' and '..') should work fine in the\nPYTHONCOMPILED variable as should environement variables.\n

        \nThere is a \"special\" path variable called MODULE that can be placed in the \nPYTHONCOMPILED variable. It specifies that the compiled catalog should\nreside in the same directory as the module that called it. This is useful\nif an admin wants to build a lot of compiled functions during the build\nof a package and then install them in site-packages along with the package.\nUser's who specify MODULE in their PYTHONCOMPILED variable will have access\nto these compiled functions. Note, however, that if they call the function\nwith a set of argument types that it hasn't previously been built for, the\nnew function will be stored in their default directory (or some other writable\ndirectory in the PYTHONCOMPILED path) because the user will not have write\naccess to the site-packages directory.\n

        \nAn example of using the PYTHONCOMPILED path on bash follows:\n\n 

        \n    PYTHONCOMPILED=MODULE:/some/path;export PYTHONCOMPILED;\n
        \n\nIf you are using python21 on linux, and the module bob.py in site-packages\nhas a compiled function in it, then the catalog search order when calling that\nfunction for the first time in a python session would be:\n\n 
        \n    /usr/lib/python21/site-packages/linuxpython_compiled\n    /some/path/linuxpython_compiled\n    ~/.python21_compiled/linuxpython_compiled\n
        \n\nThe default location is always included in the search path.\n

        \n \nNote: hmmm. see a possible problem here. I should probably make a sub-\ndirectory such as /usr/lib/python21/site-\npackages/python21_compiled/linuxpython_compiled so that library files compiled \nwith python21 are tried to link with python22 files in some strange scenarios. \nNeed to check this.\n\n\n

        \nThe in-module cache (in weave.inline_tools reduces the overhead \nof calling inline functions by about a factor of 2. It can be reduced a little \nmore for type loop calls where the same function is called over and over again \nif the cache was a single value instead of a dictionary, but the benefit is \nvery small (less than 5%) and the utility is quite a bit less. So, we'll stick \nwith a dictionary as the cache.\n

        \n\n\n

        Blitz

        \n Note: most of this section is lifted from old documentation. It should be\npretty accurate, but there may be a few discrepancies.\n

        \nweave.blitz() compiles Numeric Python expressions for fast \nexecution. For most applications, compiled expressions should provide a \nfactor of 2-10 speed-up over Numeric arrays. Using compiled \nexpressions is meant to be as unobtrusive as possible and works much like \npythons exec statement. As an example, the following code fragment takes a 5 \npoint average of the 512x512 2d image, b, and stores it in array, a:\n\n 

        \n    from scipy import *  # or from Numeric import *\n    a = ones((512,512), Float64) \n    b = ones((512,512), Float64) \n    # ...do some stuff to fill in b...\n    # now average\n    a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] \\\n                   + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n
        \n \nTo compile the expression, convert the expression to a string by putting\nquotes around it and then use weave.blitz:\n\n 
        \n    import weave\n    expr = \"a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n                          \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n    weave.blitz(expr)\n
        \n\nThe first time weave.blitz is run for a given expression and \nset of arguements, C++ code that accomplishes the exact same task as the Python \nexpression is generated and compiled to an extension module. This can take up \nto a couple of minutes depending on the complexity of the function. Subsequent \ncalls to the function are very fast. Futher, the generated module is saved \nbetween program executions so that the compilation is only done once for a \ngiven expression and associated set of array types. If the given expression\nis executed with a new set of array types, the code most be compiled again. This\ndoes not overwrite the previously compiled function -- both of them are saved and\navailable for exectution. \n

        \nThe following table compares the run times for standard Numeric code and \ncompiled code for the 5 point averaging.\n

        \n

        \n\n\n\n\n\n
        Method Run Time (seconds)
        Standard Numeric 0.46349
        blitz (1st time compiling) 78.95526
        blitz (subsequent calls) 0.05843 (factor of 8 speedup)
        \n
        \n

        \nThese numbers are for a 512x512 double precision image run on a 400 MHz Celeron \nprocessor under RedHat Linux 6.2.\n

        \nBecause of the slow compile times, its probably most effective to develop \nalgorithms as you usually do using the capabilities of scipy or the Numeric \nmodule. Once the algorithm is perfected, put quotes around it and execute it \nusing weave.blitz. This provides the standard rapid \nprototyping strengths of Python and results in algorithms that run close to \nthat of hand coded C or Fortran.\n\n\n

        Requirements

        \n\nCurrently, the weave.blitz has only been tested under Linux \nwith gcc-2.95-3 and on Windows with Mingw32 (2.95.2). Its compiler \nrequirements are pretty heavy duty (see the \nblitz++ home page), so it won't \nwork with just any compiler. Particularly MSVC++ isn't up to snuff. A number \nof other compilers such as KAI++ will also work, but my suspicions are that gcc \nwill get the most use.\n\n\n

        Limitations

        \n
          \n
        1. \nCurrently, weave.blitz handles all standard mathematic \noperators except for the ** power operator. The built-in trigonmetric, log, \nfloor/ceil, and fabs functions might work (but haven't been tested). It also \nhandles all types of array indexing supported by the Numeric module. \n

          \nweave.blitz does not currently support operations that use \narray broadcasting, nor have any of the special purpose functions in Numeric \nsuch as take, compress, etc. been implemented. Note that there are no obvious \nreasons why most of this functionality cannot be added to scipy.weave, so it \nwill likely trickle into future versions. Using slice() objects \ndirectly instead of start:stop:step is also not supported.\n

          2. \n
        2. \nCurrently Python only works on expressions that include assignment such as\n \n 
          \n    >>> result = b + c + d\n
          \n\nThis means that the result array must exist before calling \nweave.blitz. Future versions will allow the following:\n\n 
          \n    >>> result = weave.blitz_eval(\"b + c + d\")\n
          \n
          3. \n
        3. \nweave.blitz works best when algorithms can be expressed in a \n\"vectorized\" form. Algorithms that have a large number of if/thens and other \nconditions are better hand written in C or Fortran. Further, the restrictions \nimposed by requiring vectorized expressions sometimes preclude the use of more \nefficient data structures or algorithms. For maximum speed in these cases, \nhand-coded C or Fortran code is the only way to go.\n
          4. \n
        4. \nOne other point deserves mention lest people be confused. \nweave.blitz is not a general purpose Python->C compiler. It \nonly works for expressions that contain Numeric arrays and/or \nPython scalar values. This focused scope concentrates effort on the \ncompuationally intensive regions of the program and sidesteps the difficult \nissues associated with a general purpose Python->C compiler.\n
          5. \n
        \n\n\n

        Numeric efficiency issues: What compilation buys you

        \n\nSome might wonder why compiling Numeric expressions to C++ is beneficial since \noperations on Numeric array operations are already executed within C loops. \nThe problem is that anything other than the simplest expression are executed in \nless than optimal fashion. Consider the following Numeric expression:\n\n 
        \n    a = 1.2 * b + c * d\n
        \n \nWhen Numeric calculates the value for the 2d array, a, it does \nthe following steps:\n\n 
        \n    temp1 = 1.2 * b\n    temp2 = c * d\n    a = temp1 + temp2\n
        \n \nTwo things to note. Since c is an (perhaps large) array, a large \ntemporary array must be created to store the results of 1.2 * b. \nThe same is true for temp2. Allocation is slow. The second thing \nis that we have 3 loops executing, one to calculate temp1, one for \ntemp2 and one for adding them up. A C loop for the same problem \nmight look like:\n\n 
        \n    for(int i = 0; i < M; i++)\n        for(int j = 0; j < N; j++)\n            a[i,j] = 1.2 * b[i,j] + c[i,j] * d[i,j]\n
        \n \nHere, the 3 loops have been fused into a single loop and there is no longer\na need for a temporary array. This provides a significant speed improvement\nover the above example (write me and tell me what you get). \n

        \nSo, converting Numeric expressions into C/C++ loops that fuse the loops and \neliminate temporary arrays can provide big gains. The goal then,is to convert \nNumeric expression to C/C++ loops, compile them in an extension module, and \nthen call the compiled extension function. The good news is that there is an \nobvious correspondence between the Numeric expression above and the C loop. The \nbad news is that Numeric is generally much more powerful than this simple \nexample illustrates and handling all possible indexing possibilities results in \nloops that are less than straight forward to write. (take a peak in Numeric for \nconfirmation). Luckily, there are several available tools that simplify the \nprocess.\n\n\n

        The Tools

        \n\nweave.blitz relies heavily on several remarkable tools. On the \nPython side, the main facilitators are Jermey Hylton's parser module and Jim \nHuginin's Numeric module. On the compiled language side, Todd Veldhuizen's \nblitz++ array library, written in C++ (shhhh. don't tell David Beazley), does \nthe heavy lifting. Don't assume that, because it's C++, it's much slower than C \nor Fortran. Blitz++ uses a jaw dropping array of template techniques \n(metaprogramming, template expression, etc) to convert innocent looking and \nreadable C++ expressions into to code that usually executes within a few \npercentage points of Fortran code for the same problem. This is good. \nUnfortunately all the template raz-ma-taz is very expensive to compile, so the \n200 line extension modules often take 2 or more minutes to compile. This isn't so \ngood. weave.blitz works to minimize this issue by remembering \nwhere compiled modules live and reusing them instead of re-compiling every time \na program is re-run.\n\n\n

        Parser

        \nTearing Numeric expressions apart, examining the pieces, and then rebuilding \nthem as C++ (blitz) expressions requires a parser of some sort. I can imagine \nsomeone attacking this problem with regular expressions, but it'd likely be \nugly and fragile. Amazingly, Python solves this problem for us. It actually \nexposes its parsing engine to the world through the parser module. \nThe following fragment creates an Abstract Syntax Tree (AST) object for the \nexpression and then converts to a (rather unpleasant looking) deeply nested list \nrepresentation of the tree. \n \n 
        \n    >>> import parser\n    >>> import scipy.weave.misc\n    >>> ast = parser.suite(\"a = b * c + d\")\n    >>> ast_list = ast.tolist()\n    >>> sym_list = scipy.weave.misc.translate_symbols(ast_list)\n    >>> pprint.pprint(sym_list)\n    ['file_input',\n     ['stmt',\n      ['simple_stmt',\n       ['small_stmt',\n        ['expr_stmt',\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'a']]]]]]]]]]]]]]],\n         ['EQUAL', '='],\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'b']]]],\n                    ['STAR', '*'],\n                    ['factor', ['power', ['atom', ['NAME', 'c']]]]],\n                   ['PLUS', '+'],\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'd']]]]]]]]]]]]]]]]],\n       ['NEWLINE', '']]],\n     ['ENDMARKER', '']]\n
        \n\nDespite its looks, with some tools developed by Jermey H., its possible\nto search these trees for specific patterns (sub-trees), extract the \nsub-tree, manipulate them converting python specific code fragments\nto blitz code fragments, and then re-insert it in the parse tree. The parser\nmodule documentation has some details on how to do this. Traversing the \nnew blitzified tree, writing out the terminal symbols as you go, creates\nour new blitz++ expression string.\n\n \n

        Blitz and Numeric

        \nThe other nice discovery in the project is that the data structure used\nfor Numeric arrays and blitz arrays is nearly identical. Numeric stores\n\"strides\" as byte offsets and blitz stores them as element offsets, but\nother than that, they are the same. Further, most of the concept and\ncapabilities of the two libraries are remarkably similar. It is satisfying \nthat two completely different implementations solved the problem with \nsimilar basic architectures. It is also fortitous. The work involved in \nconverting Numeric expressions to blitz expressions was greatly diminished.\nAs an example, consider the code for slicing an array in Python with a\nstride:\n\n 
        \n    >>> a = b[0:4:2] + c\n    >>> a\n    [0,2,4]\n
        \n\n\nIn Blitz it is as follows:\n\n 
        \n    Array<2,int> b(10);\n    Array<2,int> c(3);\n    // ...\n    Array<2,int> a = b(Range(0,3,2)) + c;\n
        \n\n\nHere the range object works exactly like Python slice objects with the exception\nthat the top index (3) is inclusive where as Python's (4) is exclusive. Other \ndifferences include the type declaraions in C++ and parentheses instead of \nbrackets for indexing arrays. Currently, weave.blitz handles the \ninclusive/exclusive issue by subtracting one from upper indices during the\ntranslation. An alternative that is likely more robust/maintainable in the \nlong run, is to write a PyRange class that behaves like Python's range. \nThis is likely very easy.\n

        \nThe stock blitz also doesn't handle negative indices in ranges. The current \nimplementation of the blitz() has a partial solution to this \nproblem. It calculates and index that starts with a '-' sign by subtracting it \nfrom the maximum index in the array so that:\n\n 

        \n                    upper index limit\n                        /-----\\\n    b[:-1] -> b(Range(0,Nb[0]-1-1))\n
        \n\nThis approach fails, however, when the top index is calculated from other \nvalues. In the following scenario, if i+j evaluates to a negative \nvalue, the compiled code will produce incorrect results and could even core-\ndump. Right now, all calculated indices are assumed to be positive.\n \n 
        \n    b[:i-j] -> b(Range(0,i+j))\n
        \n\nA solution is to calculate all indices up front using if/then to handle the\n+/- cases. This is a little work and results in more code, so it hasn't been\ndone. I'm holding out to see if blitz++ can be modified to handle negative\nindexing, but haven't looked into how much effort is involved yet. While it \nneeds fixin', I don't think there is a ton of code where this is an issue.\n

        \nThe actual translation of the Python expressions to blitz expressions is \ncurrently a two part process. First, all x:y:z slicing expression are removed\nfrom the AST, converted to slice(x,y,z) and re-inserted into the tree. Any\nmath needed on these expressions (subtracting from the \nmaximum index, etc.) are also preformed here. _beg and _end are used as special\nvariables that are defined as blitz::fromBegin and blitz::toEnd.\n\n 

        \n    a[i+j:i+j+1,:] = b[2:3,:] \n
        \n\nbecomes a more verbose:\n \n 
        \n    a[slice(i+j,i+j+1),slice(_beg,_end)] = b[slice(2,3),slice(_beg,_end)]\n
        \n \nThe second part does a simple string search/replace to convert to a blitz \nexpression with the following translations:\n\n 
        \n    slice(_beg,_end) -> _all  # not strictly needed, but cuts down on code.\n    slice            -> blitz::Range\n    [                -> (\n    ]                -> )\n    _stp             -> 1\n
        \n\n_all is defined in the compiled function as \nblitz::Range.all(). These translations could of course happen \ndirectly in the syntax tree. But the string replacement is slightly easier. \nNote that name spaces are maintained in the C++ code to lessen the likelyhood \nof name clashes. Currently no effort is made to detect name clashes. A good \nrule of thumb is don't use values that start with '_' or 'py_' in compiled \nexpressions and you'll be fine.\n\n \n

        Type definitions and coersion

        \n\nSo far we've glossed over the dynamic vs. static typing issue between Python \nand C++. In Python, the type of value that a variable holds can change\nthrough the course of program execution. C/C++, on the other hand, forces you\nto declare the type of value a variables will hold prior at compile time.\nweave.blitz handles this issue by examining the types of the\nvariables in the expression being executed, and compiling a function for those\nexplicit types. For example:\n\n 
        \n    a = ones((5,5),Float32)\n    b = ones((5,5),Float32)\n    weave.blitz(\"a = a + b\")\n
        \n\nWhen compiling this expression to C++, weave.blitz sees that the\nvalues for a and b in the local scope have type Float32, or 'float'\non a 32 bit architecture. As a result, it compiles the function using \nthe float type (no attempt has been made to deal with 64 bit issues).\nIt also goes one step further. If all arrays have the same type, a templated\nversion of the function is made and instantiated for float, double, \ncomplex, and complex arrays. Note: This feature has been \nremoved from the current version of the code. Each version will be compiled\nseparately \n

        \nWhat happens if you call a compiled function with array types that are \ndifferent than the ones for which it was originally compiled? No biggie, you'll \njust have to wait on it to compile a new version for your new types. This \ndoesn't overwrite the old functions, as they are still accessible. See the \ncatalog section in the inline() documentation to see how this is handled. \nSuffice to say, the mechanism is transparent to the user and behaves \nlike dynamic typing with the occasional wait for compiling newly typed \nfunctions.\n

        \nWhen working with combined scalar/array operations, the type of the array is \nalways used. This is similar to the savespace flag that was recently \nadded to Numeric. This prevents issues with the following expression perhaps \nunexpectedly being calculated at a higher (more expensive) precision that can \noccur in Python:\n\n 

        \n    >>> a = array((1,2,3),typecode = Float32)\n    >>> b = a * 2.1 # results in b being a Float64 array.\n
        \n \nIn this example, \n\n 
        \n    >>> a = ones((5,5),Float32)\n    >>> b = ones((5,5),Float32)\n    >>> weave.blitz(\"b = a * 2.1\")\n
        \n \nthe 2.1 is cast down to a float before carrying out \nthe operation. If you really want to force the calculation to be a \ndouble, define a and b as \ndouble arrays.\n

        \nOne other point of note. Currently, you must include both the right hand side \nand left hand side (assignment side) of your equation in the compiled \nexpression. Also, the array being assigned to must be created prior to calling \nweave.blitz. I'm pretty sure this is easily changed so that a \ncompiled_eval expression can be defined, but no effort has been made to \nallocate new arrays (and decern their type) on the fly.\n\n \n

        Cataloging Compiled Functions

        \n\nSee the Cataloging functions section in the \nweave.inline() documentation.\n\n \n

        Checking Array Sizes

        \n\nSurprisingly, one of the big initial problems with compiled code was making\nsure all the arrays in an operation were of compatible type. The following\ncase, is of course, trivially easy:\n\n 
        \n    a = b + c\n
        \n \nIt only requires that arrays a, b, and c \nhave the same shape. However, expressions like:\n\n 
        \n    a[i+j:i+j+1,:] = b[2:3,:] + c\n
        \n\nare not so trivial. Since slicing is involved, the size of the slices, not the \ninput arrays must be checked. Broadcasting complicates things further because \narrays and slices with different dimensions and shapes may be compatible for \nmath operations (broadcasting isn't yet supported by \nweave.blitz). Reductions have a similar effect as their \nresults are different shapes than their input operand. The binary operators in \nNumeric compare the shapes of their two operands just before they operate on \nthem. This is possible because Numeric treats each operation independently. \nThe intermediate (temporary) arrays created during sub-operations in an \nexpression are tested for the correct shape before they are combined by another \noperation. Because weave.blitz fuses all operations into a \nsingle loop, this isn't possible. The shape comparisons must be done and \nguaranteed compatible before evaluating the expression.\n

        \nThe solution chosen converts input arrays to \"dummy arrays\" that only represent \nthe dimensions of the arrays, not the data. Binary operations on dummy arrays \ncheck that input array sizes are comptible and return a dummy array with the \nsize correct size. Evaluating an expression of dummy arrays traces the \nchanging array sizes through all operations and fails if incompatible array \nsizes are ever found. \n

        \nThe machinery for this is housed in weave.size_check. It \nbasically involves writing a new class (dummy array) and overloading it math \noperators to calculate the new sizes correctly. All the code is in Python and \nthere is a fair amount of logic (mainly to handle indexing and slicing) so the \noperation does impose some overhead. For large arrays (ie. 50x50x50), the \noverhead is negligible compared to evaluating the actual expression. For small \narrays (ie. 16x16), the overhead imposed for checking the shapes with this \nmethod can cause the weave.blitz to be slower than evaluating \nthe expression in Python. \n

        \nWhat can be done to reduce the overhead? (1) The size checking code could be \nmoved into C. This would likely remove most of the overhead penalty compared \nto Numeric (although there is also some calling overhead), but no effort has \nbeen made to do this. (2) You can also call weave.blitz with\ncheck_size=0 and the size checking isn't done. However, if the \nsizes aren't compatible, it can cause a core-dump. So, foregoing size_checking\nisn't advisable until your code is well debugged.\n\n \n

        Creating the Extension Module

        \n\nweave.blitz uses the same machinery as \nweave.inline to build the extension module. The only difference\nis the code included in the function is automatically generated from the\nNumeric array expression instead of supplied by the user.\n\n\n

        Extension Modules

        \nweave.inline and weave.blitz are high level tools\nthat generate extension modules automatically. Under the covers, they use several\nclasses from weave.ext_tools to help generate the extension module.\nThe main two classes are ext_module and ext_function (I'd\nlike to add ext_class and ext_method also). These classes\nsimplify the process of generating extension modules by handling most of the \"boiler\nplate\" code automatically.\n\n\nNote: inline actually sub-classes weave.ext_tools.ext_function \nto generate slightly different code than the standard ext_function.\nThe main difference is that the standard class converts function arguments to\nC types, while inline always has two arguments, the local and global dicts, and\nthe grabs the variables that need to be convereted to C from these.\n\n\n\n

        A Simple Example

        \nThe following simple example demonstrates how to build an extension module within\na Python function:\n\n 
        \n    # examples/increment_example.py\n    from weave import ext_tools\n    \n    def build_increment_ext():\n        \"\"\" Build a simple extension with functions that increment numbers.\n            The extension will be built in the local directory.\n        \"\"\"        \n        mod = ext_tools.ext_module('increment_ext')\n    \n        a = 1 # effectively a type declaration for 'a' in the \n              # following functions.\n    \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n        mod.add_function(func)\n        \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+2));\"    \n        func = ext_tools.ext_function('increment_by_2',ext_code,['a'])\n        mod.add_function(func)\n                \n        mod.compile()\n
        \n\n\nThe function build_increment_ext() creates an extension module \nnamed increment_ext and compiles it to a shared library (.so or \n.pyd) that can be loaded into Python.. increment_ext contains two \nfunctions, increment and increment_by_2. \n\nThe first line of build_increment_ext(),\n\n 
        \n        mod = ext_tools.ext_module('increment_ext') \n
        \n\ncreates an ext_module instance that is ready to have \next_function instances added to it. ext_function \ninstances are created much with a calling convention similar to \nweave.inline(). The most common call includes a C/C++ code \nsnippet and a list of the arguments for the function. The following\n\n 
        \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n
        \n \ncreates a C/C++ extension function that is equivalent to the following Python\nfunction:\n\n 
        \n        def increment(a):\n            return a + 1\n
        \n\nA second method is also added to the module and then,\n\n 
        \n        mod.compile()\n
        \n\nis called to build the extension module. By default, the module is created\nin the current working directory.\n\nThis example is available in the examples/increment_example.py file\nfound in the weave directory. At the bottom of the file in the\nmodule's \"main\" program, an attempt to import increment_ext without\nbuilding it is made. If this fails (the module doesn't exist in the PYTHONPATH), \nthe module is built by calling build_increment_ext(). This approach\nonly takes the time consuming ( a few seconds for this example) process of building\nthe module if it hasn't been built before.\n\n 
        \n    if __name__ == \"__main__\":\n        try:\n            import increment_ext\n        except ImportError:\n            build_increment_ext()\n            import increment_ext\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
        \n\n\nNote: If we were willing to always pay the penalty of building the C++ code for \na module, we could store the md5 checksum of the C++ code along with some \ninformation about the compiler, platform, etc. Then, \next_module.compile() could try importing the module before it actually\ncompiles it, check the md5 checksum and other meta-data in the imported module\nwith the meta-data of the code it just produced and only compile the code if\nthe module didn't exist or the meta-data didn't match. This would reduce the\nabove code to:\n\n 
        \n    if __name__ == \"__main__\":\n        build_increment_ext()\n\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
        \n\nNote: There would always be the overhead of building the C++ code, but it would only actually compile the code once. You pay a little in overhead and get cleaner\n\"import\" code. Needs some thought.\n\n

        \n\nIf you run increment_example.py from the command line, you get\nthe following:\n\n 

        \n    [eric@n0]$ python increment_example.py\n    a, a+1: 1 2\n    a, a+2: 1 3\n
        \n\nIf the module didn't exist before it was run, the module is created. If it did\nexist, it is just imported and used.\n\n\n

        Fibonacci Example

        \nexamples/fibonacci.py provides a little more complex example of \nhow to use ext_tools. Fibonacci numbers are a series of numbers \nwhere each number in the series is the sum of the previous two: 1, 1, 2, 3, 5, \n8, etc. Here, the first two numbers in the series are taken to be 1. One \napproach to calculating Fibonacci numbers uses recursive function calls. In \nPython, it might be written as:\n\n 
        \n    def fib(a):\n        if a <= 2:\n            return 1\n        else:\n            return fib(a-2) + fib(a-1)\n
        \n\nIn C, the same function would look something like this:\n\n 
        \n     int fib(int a)\n     {                   \n         if(a <= 2)\n             return 1;\n         else\n             return fib(a-2) + fib(a-1);  \n     }                      \n
        \n\nRecursion is much faster in C than in Python, so it would be beneficial\nto use the C version for fibonacci number calculations instead of the\nPython version. We need an extension function that calls this C function\nto do this. This is possible by including the above code snippet as \n\"support code\" and then calling it from the extension function. Support \ncode snippets (usually structure definitions, helper functions and the like)\nare inserted into the extension module C/C++ file before the extension\nfunction code. Here is how to build the C version of the fibonacci number\ngenerator:\n\n 
        \ndef build_fibonacci():\n    \"\"\" Builds an extension module with fibonacci calculators.\n    \"\"\"\n    mod = ext_tools.ext_module('fibonacci_ext')\n    a = 1 # this is effectively a type declaration\n    \n    # recursive fibonacci in C \n    fib_code = \"\"\"\n                   int fib1(int a)\n                   {                   \n                       if(a <= 2)\n                           return 1;\n                       else\n                           return fib1(a-2) + fib1(a-1);  \n                   }                         \n               \"\"\"\n    ext_code = \"\"\"\n                   int val = fib1(a);\n                   return_val = Py::new_reference_to(Py::Int(val));\n               \"\"\"    \n    fib = ext_tools.ext_function('fib',ext_code,['a'])\n    fib.customize.add_support_code(fib_code)\n    mod.add_function(fib)\n\n    mod.compile()\n\n
        \n\nXXX More about custom_info, and what xxx_info instances are good for.\n\n

        \n\nNote: recursion is not the fastest way to calculate fibonacci numbers, but this \napproach serves nicely for this example.\n\n

        \n\n

        Customizing Type Conversions -- Type Factories

        \nnot written\n\n

        Things I wish weave did

        \n\nIt is possible to get name clashes if you uses a variable name that is already defined\nin a header automatically included (such as stdio.h) For instance, if you\ntry to pass in a variable named stdout, you'll get a cryptic error report\ndue to the fact that stdio.h also defines the name. weave\nshould probably try and handle this in some way.\n\nOther things...", "source_code_before": "\n

        Weave Documentation

        \n

        \nBy Eric Jones eric@enthought.com\n

        \n

        Outline

        \n
        \n
        Introduction\n
        Requirements\n
        Installation and Testing\n
        Inline\n
        \n
        More with printf\n
        \n More examples\n
        \n
        Binary search\n
        Dictionary sort\n
        Numeric -- cast/copy/transpose\n
        wxPython
        \n
        \n
        Keyword options\n
        Returning values\n
        \n
        \n The issue with locals()
        \n
        \n
        A quick look at the code\n
        \n Technical Details\n
        \n
        Converting Types\n
        \n
        \n Numeric Argument Conversion\n
        \n String, List, Tuple, and Dictionary Conversion\n
        File Conversion \n
        \n Callable, Instance, and Module Conversion \n
        Customizing Conversions\n
        \n
        Compiling Code\n
        \"Cataloging\" functions\n
        \n
        Function Storage\n
        The PYTHONCOMPILED evnironment variable
        \n
        \n
        \n
        \n
        \n
        \n
        Blitz\n
        \n
        Requirements\n
        Limitations\n
        Numeric Efficiency Issues\n
        The Tools \n
        \n
        Parser\n
        Blitz and Numeric\n
        \n
        Type defintions and coersion\n
        Cataloging Compiled Functions\n
        Checking Array Sizes\n
        Creating the Extension Module\n
        \n
        Extension Modules\n
        \n
        A Simple Example\n
        Fibonacci Example\n
        \n
        Customizing Type Conversions -- Type Factories (not written)\n
        \n
        Type Specifications\n
        Type Information\n
        The Conversion Process \n
        \n
        \n\n

        Introduction

        \n\n

        \nThe weave package provides tools for including C/C++ code within\nin Python code. This offers both another level of optimization to those who need \nit, and an easy way to modify and extend any supported extension libraries such \nas wxPython and hopefully VTK soon. Inlining C/C++ code within Python generally\nresults in speed ups of 1.5x to 30x speed-up over algorithms written in pure\nPython (However, it is also possible to slow things down...). Generally \nalgorithms that require a large number of calls to the Python API don't benefit\nas much from the conversion to C/C++ as algorithms that have inner loops \ncompletely convertable to C.\n

        \nThere are three basic ways to use weave. The \nweave.inline() function executes C code directly within Python, \nand weave.blitz() translates Python Numeric expressions to C++ \nfor fast execution. blitz() was the original reason \nweave was built. For those interested in building extension\nlibraries, the ext_tools module provides classes for building \nextension modules within Python. \n

        \nMost of weave's functionality should work on Windows and Unix, \nalthough some of its functionality requires gcc or a similarly \nmodern C++ compiler that handles templates well. Up to now, most testing has \nbeen done on Windows 2000 with Microsoft's C++ compiler (MSVC) and with gcc \n(mingw32 2.95.2 and 2.95.3-6). All tests also pass on Linux (RH 7.1 \nwith gcc 2.96), and I've had reports that it works on Debian also (thanks \nPearu).\n

        \nThe inline and blitz provide new functionality to \nPython (although I've recently learned about the PyInline project which may offer \nsimilar functionality to inline). On the other hand, tools for \nbuilding Python extension modules already exists (SWIG, SIP, pycpp, CXX, and \nothers). As of yet, I'm not sure where weave fits in this \nspectrum. It is closest in flavor to CXX in that it makes creating new C/C++ \nextension modules pretty easy. However, if you're wrapping a gaggle of legacy \nfunctions or classes, SWIG and friends are definitely the better choice. \nweave is set up so that you can customize how Python types are \nconverted to C types in weave. This is great for \ninline(), but, for wrapping legacy code, it is more flexible to \nspecify things the other way around -- that is how C types map to Python types. \nThis weave does not do. I guess it would be possible to build \nsuch a tool on top of weave, but with good tools like SWIG around, \nI'm not sure the effort produces any new capabilities. Things like function \noverloading are probably easily implemented in weave and it might \nbe easier to mix Python/C code in function calls, but nothing beyond this comes \nto mind. So, if you're developing new extension modules or optimizing Python \nfunctions in C, weave.ext_tools() might be the tool \nfor you. If you're wrapping legacy code, stick with SWIG.\n

        \nThe next several sections give the basics of how to use weave.\nWe'll discuss what's happening under the covers in more detail later \non. Serious users will need to at least look at the type conversion section to \nunderstand how Python variables map to C/C++ types and how to customize this \nbehavior. One other note. If you don't know C or C++ then these docs are \nprobably of very little help to you. Further, it'd be helpful if you know \nsomething about writing Python extensions. weave does quite a \nbit for you, but for anything complex, you'll need to do some conversions, \nreference counting, etc.\n

        \n\nNote: weave is actually part of the SciPy package. However, it works fine as a \nstandalone package. The examples here are given as if it is used as a stand \nalone package. If you are using from within scipy, you can use from \nscipy import weave and the examples will work identically.\n\n\n

        Requirements

        \n
          \n
        • Python\n

          \n I use 2.1.1. Probably 2.0 or higher should work.\n

          \n

          • \n \n
        • C++ compiler\n

          \n weave uses distutils to actually build \n extension modules, so it uses whatever compiler was originally used to \n build Python. weave itself requires a C++ compiler. If \n you used a C++ compiler to build Python, your probably fine.\n

          \n On Unix gcc is the preferred choice, because I've done a little \n testing with it. All testing has been done with gcc, but I expect the \n majority of compilers should work for inline and \n ext_tools. The one issue I'm not sure about is that I've \n hard coded things so that compilations are linked with the \n stdc++ library. Is this standard across \n Unix compilers, or is this a gcc-ism?\n

          \n For blitz(), you'll need a reasonably recent version of \n gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n versions are likely to work. Its likely that KAI's C++ compiler and \n maybe some others will work, but I haven't tried. My advise is to use \n gcc for now unless your willing to tinker with the code some.\n

          \n On Windows, either MSVC or gcc (www.mingw.org\" > mingw32) should work. Again, \n you'll need gcc for blitz() as the\n MSVC compiler doesn't handle templates well.\n

          \n I have not tried Cygwin, so please report success if it works for you.\n

          \n

          • \n\n
        • Numeric (optional)\n

          \n The python Numeric module from here. is required for \n blitz() to work. Be sure and get NumPy, not NumArray\n which is the \"next generation\" implementation.\n

          \n

          • \n
        • scipy_distutils and scipy_test (packaged with weave)\n

          \n These two modules are packaged with weave in both\n the windows installer and the source distributions. If you are using\n CVS, however, you'll need to download these separately (also available\n through CVS at SciPy).\n

          \n

          • \n
        \n

        \n\n\n

        Installation and Testing

        \n

        \nThere are currently two ways to get weave. Fist, \nweave is part of SciPy and installed automatically (as a sub-\npackage) whenever SciPy is installed (although the latest version isn't in \nSciPy yet, so use this one for now). Second, since weave is \nuseful outside of the scientific community, it has been setup so that it can be\nused as a stand-alone module. \n\n

        \nThe stand-alone version can be downloaded from here. Unix users should grab the \ntar ball (.tgz file) and install it using the following commands.\n\n 

        \n    tar -xzvf weave-0.2.tar.gz\n    cd weave-0.2\n    python setup.py install\n
        \n\nThis will also install two other packages, scipy_distutils and \nscipy_test. The first is needed by the setup process itself and \nboth are used in the unit-testing process. For Windows users, it's even easier. \nThey can download the click-install .exe file and run it for automatic \ninstallation. Numeric is required if you want to use blitz(), but\nisn't necessary for inline() or ext_tools\n

        \nIf you're using the CVS version, you'll need to install scipy_distutils and \nscipy_test modules (also available from CVS) on your own.\n

        \n Note: The dependency issue here is a little sticky. I hate to make people \ndownload more than one file (and so I haven't), but distutils doesn't have a \nway to do conditional installation -- at least that I know about. This can \nlead to undesired clobbering of modules. What to do, what to do...\n

        \nOnce weave is installed, fire up python and run its unit tests.\n\n 

        \n    >>> import weave\n    >>> weave.test()\n    runs long time... spews tons of output\n
        \n\nThis takes a loooong time. On windows, it is usually several minutes. On Unix \nwith remote file systems, I've had it take 15 or so minutes. In the end, it \nshould run about 150 tests and spew some speed results along the way. If you \nget errors, please let me know.\n\nIf you don't have Numeric installed, you'll get some module import errors \nduring the test setup phase for modules that are Numeric specific (blitz_spec, \nblitz_tools, size_check, standard_array_spec, ast_tools), but all test should\npass (about 60 and the run time should be quite a bit less).\n

        \nIf you only want to test a single module of the package, you can do this by\nrunning test() for that specific module.\n\n 

        \n    >>> import weave.scalar_spec\n    >>> weave.scalar_spec.test()\n    .......\n    ----------------------------------------------------------------------\n    Ran 7 tests in 23.284s\n
        \n\nNote: I've had some test fail on windows machines where I have msvc, gcc-2.95.2 \n(in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My environment \nhas c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the path. The test \nprocess runs very smoothly until the end where several test using gcc fail with \ncpp0 not found by g++. If I check os.system('gcc -v') before running tests, I \nget gcc-2.95.3-6. If I check after running tests (and after failure), I get \ngcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\\gcc first in it and \nis not corrupted (msvc/distutils messes with the environment variables, so we \nhave to undo its work in some places). If anyone else sees this, let me know -\n- it may just be an quirk on my machine (unlikely). Testing with the gcc-\n2.95.2 installation always works.\n\n\n\n

        Inline

        \n

        \ninline() compiles and executes C/C++ code on the fly. Variables \nin the local and global Python scope are also available in the C/C++ code. \nValues are passed to the C/C++ code by assignment much like variables \nare passed into a standard Python function. Values are returned from the C/C++ \ncode through a special argument called return_val. Also, the contents of \nmutable objects can be changed within the C/C++ code and the changes remain \nafter the C code exits and returns to Python. (more on this later)\n

        \nHere's a trivial printf example using inline():\n\n 

        \n    >>> import weave    \n    >>> a  = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
        \n

        \nIn this, its most basic form, inline(c_code, var_list) requires two \narguments. c_code is a string of valid C/C++ code. \nvar_list is a list of variable names that are passed from \nPython into C/C++. Here we have a simple printf statement that \nwrites the Python variable a to the screen. The first time you run \nthis, there will be a pause while the code is written to a .cpp file, compiled \ninto an extension module, loaded into Python, cataloged for future use, and \nexecuted. On windows (850 MHz PIII), this takes about 1.5 seconds when using \nMicrosoft's C++ compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). \nAll subsequent executions of the code will happen very quickly because the code \nonly needs to be compiled once. If you kill and restart the interpreter and then \nexecute the same code fragment again, there will be a much shorter delay in the \nfractions of seconds range. This is because weave stores a \ncatalog of all previously compiled functions in an on disk cache. When it sees \na string that has been compiled, it loads the already compiled module and \nexecutes the appropriate function. \n

        \n\nNote: If you try the printf example in a GUI shell such as IDLE, \nPythonWin, PyShell, etc., you're unlikely to see the output. This is because the \nC code is writing to stdout, instead of to the GUI window. This doesn't mean \nthat inline doesn't work in these environments -- it only means that standard \nout in C is not the same as the standard out for Python in these cases. Non \ninput/output functions will work as expected.\n\n

        \nAlthough effort has been made to reduce the overhead associated with calling \ninline, it is still less efficient for simple code snippets than using \nequivalent Python code. The simple printf example is actually \nslower by 30% or so than using Python print statement. And, it is \nnot difficult to create code fragments that are 8-10 times slower using inline \nthan equivalent Python. However, for more complicated algorithms, \nthe speed up can be worth while -- anywhwere from 1.5- 30 times faster. \nAlgorithms that have to manipulate Python objects (sorting a list) usually only \nsee a factor of 2 or so improvement. Algorithms that are highly computational \nor manipulate Numeric arrays can see much larger improvements. The \nexamples/vq.py file shows a factor of 30 or more improvement on the vector \nquantization algorithm that is used heavily in information theory and \nclassification problems.\n

        \n\n\n

        More with printf

        \n

        \nMSVC users will actually see a bit of compiler output that distutils does not\nsupress the first time the code executes:\n\n 

            \n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    sc_e013937dbc8c647ac62438874e5795131.cpp\n       Creating library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\n       \\Release\\sc_e013937dbc8c647ac62438874e5795131.lib and object C:\\DOCUME\n       ~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_e013937dbc8c64\n       7ac62438874e5795131.exp\n    1\n
        \n

        \nNothing bead is happening, its just a bit annoying. Anyone know how to \nturn this off? \n

        \nThis example also demonstrates using 'raw strings'. The r \npreceeding the code string in the last example denotes that this is a 'raw \nstring'. In raw strings, the backslash character is not interpreted as an \nescape character, and so it isn't necessary to use a double backslash to \nindicate that the '\\n' is meant to be interpreted in the C printf \nstatement instead of by Python. If your C code contains a lot\nof strings and control characters, raw strings might make things easier.\nMost of the time, however, standard strings work just as well.\n\n

        \nThe printf statement in these examples is formatted to print \nout integers. What happens if a is a string? inline\nwill happily, compile a new version of the code to accept strings as input,\nand execute the code. The result?\n\n 

            \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    32956972\n
        \n

        \nIn this case, the result is non-sensical, but also non-fatal. In other \nsituations, it might produce a compile time error because a is \nrequired to be an integer at some point in the code, or it could produce a \nsegmentation fault. Its possible to protect against passing \ninline arguments of the wrong data type by using asserts in \nPython.\n\n 

            \n    >>> a = 'string'\n    >>> def protected_printf(a):    \n    ...     assert(type(a) == type(1))\n    ...     weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    >>> protected_printf(1)\n     1\n    >>> protected_printf('string')\n    AssertError...\n
        \n\n

        \nFor printing strings, the format statement needs to be changed.\n\n 

            \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%s\\n\",a);',['a'])\n    string\n
        \n\n

        \nAs in this case, C/C++ code fragments often have to change to accept different \ntypes. For the given printing task, however, C++ streams provide a way of a \nsingle statement that works for integers and strings. By default, the stream \nobjects live in the std (standard) namespace and thus require the use of \nstd::.\n\n 

            \n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    1    \n    >>> a = 'string'\n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    string\n
        \n \n

        \nExamples using printf and cout are included in \nexamples/print_example.py.\n\n\n

        More examples

        \n\nThis section shows several more advanced uses of inline. It \nincludes a few algorithms from the Python Cookbook \nthat have been re-written in inline C to improve speed as well as a couple \nexamples using Numeric and wxPython.\n\n\n

        Binary search

        \nLets look at the example of searching a sorted list of integers for a value. \nFor inspiration, we'll use Kalle Svensson's \nbinary_search() algorithm from the Python Cookbook. His recipe follows:\n\n 
        \n    def binary_search(seq, t):\n        min = 0; max = len(seq) - 1\n        while 1:\n            if max < min:\n                return -1\n            m = (min  + max)  / 2\n            if seq[m] < t: \n                min = m  + 1 \n            elif seq[m] > t: \n                max = m  - 1 \n            else:\n                return m    \n
        \n\nThis Python version works for arbitrary Python data types. The C version below is \nspecialized to handle integer values. There is a little type checking done in \nPython to assure that we're working with the correct data types before heading \ninto C. The variables seq and t don't need to be \ndeclared beacuse weave handles converting and declaring them in \nthe C code. All other temporary variables such as min, max, etc. \nmust be declared -- it is C after all. Here's the new mixed Python/C function:\n\n 
            \n    def c_int_binary_search(seq,t):\n        # do a little type checking in Python\n        assert(type(t) == type(1))\n        assert(type(seq) == type([]))\n        \n        # now the C code\n        code = \"\"\"\n               #line 29 \"binary_search.py\"\n               int val, m, min = 0;  \n               int max = seq.length() - 1;\n               PyObject *py_val; \n               for(;;)\n               {\n                   if (max < min  ) \n                   { \n                       return_val =  Py::new_reference_to(Py::Int(-1)); \n                       break;\n                   } \n                   m =  (min + max) /2;\n                   val =    py_to_int(PyList_GetItem(seq.ptr(),m),\"val\"); \n                   if (val  < t) \n                       min = m  + 1;\n                   else if (val >  t)\n                       max = m - 1;\n                   else\n                   {\n                       return_val = Py::new_reference_to(Py::Int(m));\n                       break;\n                   }\n               }\n               \"\"\"\n        return inline(code,['seq','t'])\n
        \n

        \nWe have two variables seq and t passed in. \nt is guaranteed (by the assert) to be an integer. \nPython integers are converted to C int types in the transition from Python to \nC. seq is a Python list. By default, it is translated to a CXX \nlist object. Full documentation for the CXX library can be found at its website. The basics are that the CXX \nprovides C++ class equivalents for Python objects that simplify, or at \nleast object orientify, working with Python objects in C/C++. For example, \nseq.length() returns the length of the list. A little more about\nCXX and its class methods, etc. is in the ** type conversions ** section.\n

        \nMost of the algorithm above looks similar in C to the original Python code. \nThere are two main differences. The first is the setting of \nreturn_val instead of directly returning from the C code with a \nreturn statement. return_val is an automatically \ndefined variable of type PyObject* that is returned from the C \ncode back to Python. You'll have to handle reference counting issues when \nsetting this variable. In this example, CXX classes and functions handle the \ndirty work. All CXX functions and classes live in the namespace \nPy::. The following code converts the integer m to a \nCXX Int() object and then to a PyObject* with an \nincremented reference count using Py::new_reference_to().\n\n 

           \n    return_val = Py::new_reference_to(Py::Int(m));\n
        \n

        \nThe second big differences shows up in the retrieval of integer values from the \nPython list. The simple Python seq[i] call balloons into a C \nPython API call to grab the value out of the list and then a separate call to \npy_to_int() that converts the PyObject* to an integer. \npy_to_int() includes both a NULL cheack and a \nPyInt_Check() call as well as the conversion call. If either of \nthe checks fail, an exception is raised. The entire C++ code block is executed \nwith in a try/catch block that handles exceptions much like Python \ndoes. This removes the need for most error checking code.\n

        \nIt is worth note that CXX lists do have indexing operators that result \nin code that looks much like Python. However, the overhead in using them \nappears to be relatively high, so the standard Python API was used on the \nseq.ptr() which is the underlying PyObject* of the \nList object.\n

        \nThe #line directive that is the first line of the C code \nblock isn't necessary, but it's nice for debugging. If the compilation fails \nbecause of the syntax error in the code, the error will be reported as an error \nin the Python file \"binary_search.py\" with an offset from the given line number \n(29 here).\n

        \nSo what was all our effort worth in terms of efficiency? Well not a lot in \nthis case. The examples/binary_search.py file runs both Python and C versions \nof the functions As well as using the standard bisect module. If \nwe run it on a 1 million element list and run the search 3000 times (for 0-\n2999), here are the results we get:\n\n 

           \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python binary_search.py\n    Binary search for 3000 items in 1000000 length list of integers:\n     speed in python: 0.159999966621\n     speed of bisect: 0.121000051498\n     speed up: 1.32\n     speed in c: 0.110000014305\n     speed up: 1.45\n     speed in c(no asserts): 0.0900000333786\n     speed up: 1.78\n
        \n

        \nSo, we get roughly a 50-75% improvement depending on whether we use the Python \nasserts in our C version. If we move down to searching a 10000 element list, \nthe advantage evaporates. Even smaller lists might result in the Python \nversion being faster. I'd like to say that moving to Numeric lists (and \ngetting rid of the GetItem() call) offers a substantial speed up, but my \npreliminary efforts didn't produce one. I think the log(N) algorithm is to \nblame. Because the algorithm is nice, there just isn't much time spent \ncomputing things, so moving to C isn't that big of a win. If there are ways to \nreduce conversion overhead of values, this may improve the C/Python speed \nup. Anyone have other explanations or faster code, please let me know.\n\n\n

        Dictionary Sort

        \n

        \nThe demo in examples/dict_sort.py is another example from the Python CookBook. \nThis \nsubmission, by Alex Martelli, demonstrates how to return the values from a \ndictionary sorted by their keys:\n\n 

               \n    def sortedDictValues3(adict):\n        keys = adict.keys()\n        keys.sort()\n        return map(adict.get, keys)\n
        \n

        \nAlex provides 3 algorithms and this is the 3rd and fastest of the set. The C \nversion of this same algorithm follows:\n\n 

               \n    def c_sort(adict):\n        assert(type(adict) == type({}))\n        code = \"\"\"     \n        #line 21 \"dict_sort.py\"  \n        Py::List keys = adict.keys();\n        Py::List items(keys.length()); keys.sort();     \n        PyObject* item = NULL; \n        for(int i = 0;  i < keys.length();i++)\n        {\n            item = PyList_GET_ITEM(keys.ptr(),i);\n            item = PyDict_GetItem(adict.ptr(),item);\n            Py_XINCREF(item);\n            PyList_SetItem(items.ptr(),i,item);              \n        }           \n        return_val = Py::new_reference_to(items);\n        \"\"\"   \n        return inline_tools.inline(code,['adict'],verbose=1)\n
        \n

        \nLike the original Python function, the C++ version can handle any Python \ndictionary regardless of the key/value pair types. It uses CXX objects for the \nmost part to declare python types in C++, but uses Python API calls to manipulate \ntheir contents. Again, this choice is made for speed. The C++ version, while\nmore complicated, is about a factor of 2 faster than Python.\n\n 

               \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python dict_sort.py\n    Dict sort of 1000 items for 300 iterations:\n     speed in python: 0.319999933243\n    [0, 1, 2, 3, 4]\n     speed in c: 0.151000022888\n     speed up: 2.12\n    [0, 1, 2, 3, 4]\n
        \n

        \n\n

        Numeric -- cast/copy/transpose

        \n\nCastCopyTranspose is a function called quite heavily by Linear Algebra routines\nin the Numeric library. Its needed in part because of the row-major memory layout\nof multi-demensional Python (and C) arrays vs. the col-major order of the underlying\nFortran algorithms. For small matrices (say 100x100 or less), a significant\nportion of the common routines such as LU decompisition or singular value decompostion\nare spent in this setup routine. This shouldn't happen. Here is the Python\nversion of the function using standard Numeric operations.\n\n 
               \n    def _castCopyAndTranspose(type, array):\n        if a.typecode() == type:\n            cast_array = copy.copy(Numeric.transpose(a))\n        else:\n            cast_array = copy.copy(Numeric.transpose(a).astype(type))\n        return cast_array\n
        \n\nAnd the following is a inline C version of the same function:\n\n 
        \n    from weave.blitz_tools import blitz_type_factories\n    from weave import scalar_spec\n    from weave import inline\n    def _cast_copy_transpose(type,a_2d):\n        assert(len(shape(a_2d)) == 2)\n        new_array = zeros(shape(a_2d),type)\n        numeric_type = scalar_spec.numeric_to_blitz_type_mapping[type]\n        code = \\\n        \"\"\"  \n        for(int i = 0;i < _Na_2d[0]; i++)  \n            for(int j = 0;  j < _Na_2d[1]; j++)\n                new_array(i,j) = (%s) a_2d(j,i);\n        \"\"\" % numeric_type\n        inline(code,['new_array','a_2d'],\n               type_factories = blitz_type_factories,compiler='gcc')\n        return new_array\n
        \n\nThis example uses blitz++ arrays instead of the standard representation of \nNumeric arrays so that indexing is simplier to write. This is accomplished by \npassing in the blitz++ \"type factories\" to override the standard Python to C++ \ntype conversions. Blitz++ arrays allow you to write clean, fast code, but they \nalso are sloooow to compile (20 seconds or more for this snippet). This is why \nthey aren't the default type used for Numeric arrays (and also because most \ncompilers can't compile blitz arrays...). inline() is also forced \nto use 'gcc' as the compiler because the default compiler on Windows (MSVC) \nwill not compile blitz code. 'gcc' I think will use the standard compiler \non Unix machine instead of explicitly forcing gcc (check this) \n\nComparisons of the Python vs inline C++ code show a factor of 3 speed up. Also \nshown are the results of an \"inplace\" transpose routine that can be used if the \noutput of the linear algebra routine can overwrite the original matrix (this is \noften appropriate). This provides another factor of 2 improvement.\n\n 
        \n     #C:\\home\\ej\\wrk\\scipy\\weave\\examples> python cast_copy_transpose.py\n    # Cast/Copy/Transposing (150,150)array 1 times\n    #  speed in python: 0.870999932289\n    #  speed in c: 0.25\n    #  speed up: 3.48\n    #  inplace transpose c: 0.129999995232\n    #  speed up: 6.70\n
        \n\n\n

        wxPython

        \n\ninline knows how to handle wxPython objects. Thats nice in and of\nitself, but it also demonstrates that the type conversion mechanism is reasonably \nflexible. Chances are, it won't take a ton of effort to support special types\nyou might have. The examples/wx_example.py borrows the scrolled window\nexample from the wxPython demo, accept that it mixes inline C code in the middle\nof the drawing function.\n\n 
        \n    def DoDrawing(self, dc):\n        \n        red = wxNamedColour(\"RED\");\n        blue = wxNamedColour(\"BLUE\");\n        grey_brush = wxLIGHT_GREY_BRUSH;\n        code = \\\n        \"\"\"\n        #line 108 \"wx_example.py\" \n        dc->BeginDrawing();\n        dc->SetPen(wxPen(*red,4,wxSOLID));\n        dc->DrawRectangle(5,5,50,50);\n        dc->SetBrush(*grey_brush);\n        dc->SetPen(wxPen(*blue,4,wxSOLID));\n        dc->DrawRectangle(15, 15, 50, 50);\n        \"\"\"\n        inline(code,['dc','red','blue','grey_brush'])\n        \n        dc.SetFont(wxFont(14, wxSWISS, wxNORMAL, wxNORMAL))\n        dc.SetTextForeground(wxColour(0xFF, 0x20, 0xFF))\n        te = dc.GetTextExtent(\"Hello World\")\n        dc.DrawText(\"Hello World\", 60, 65)\n\n        dc.SetPen(wxPen(wxNamedColour('VIOLET'), 4))\n        dc.DrawLine(5, 65+te[1], 60+te[0], 65+te[1])\n        ...\n
        \n\nHere, some of the Python calls to wx objects were just converted to C++ calls. There\nisn't any benefit, it just demonstrates the capabilities. You might want to use this\nif you have a computationally intensive loop in your drawing code that you want to \nspeed up.\n\nOn windows, you'll have to use the MSVC compiler if you use the standard wxPython\nDLLs distributed by Robin Dunn. Thats because MSVC and gcc, while binary\ncompatible in C, are not binary compatible for C++. In fact, its probably best, no \nmatter what platform you're on, to specify that inline use the same\ncompiler that was used to build wxPython to be on the safe side. There isn't currently\na way to learn this info from the library -- you just have to know. Also, at least\non the windows platform, you'll need to install the wxWindows libraries and link to \nthem. I think there is a way around this, but I haven't found it yet -- I get some\nlinking errors dealing with wxString. One final note. You'll probably have to\ntweak weave/wx_spec.py or weave/wx_info.py for your machine's configuration to\npoint at the correct directories etc. There. That should sufficiently scare people\ninto not even looking at this... :)\n\n        \n

        Keyword Options

        \n

        \nThe basic definition of the inline() function has a slew of \noptional variables. It also takes keyword arguments that are passed to \ndistutils as compiler options. The following is a formatted \ncut/paste of the argument section of inline's doc-string. It \nexplains all of the variables. Some examples using various options will \nfollow.\n\n 

               \n    def inline(code,arg_names,local_dict = None, global_dict = None, \n               force = 0, \n               compiler='',\n               verbose = 0, \n               support_code = None,\n               customize=None, \n               type_factories = None, \n               auto_downcast=1,\n               **kw):\n
        \n\n \ninline has quite \na few options as listed below. Also, the keyword arguments for distutils \nextension modules are accepted to specify extra information needed for \ncompiling. \n
        \n

        inline Arguments:

        \n
        \n
        \n
        code
        \n \n
        \nstring. A string of valid C++ code. It should not \n specify a return statement. Instead it should assign results that need to be \n returned to Python in the return_val. \n
        \n\n
        arg_names
        \n \n
        \nlist of strings. A list of Python variable names \n that should be transferred from Python into the C/C++ code. \n
        \n\n
        local_dict
        \n \n
        \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the local scope for the C/C++ \n code. If local_dict is not specified the local dictionary of the calling \n function is used. \n
        \n\n
        global_dict
        \n \n
        \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the global scope for the C/C++ \n code. If global_dict is not specified the global dictionary of the calling \n function is used. \n
        \n\n
        force
        \n \n
        \noptional. 0 or 1. default 0. If 1, the C++ code is \n compiled every time inline is called. This is really only useful for \n debugging, and probably only useful if you're editing support_code a lot. \n
        \n\n
        compiler
        \n \n
        \noptional. string. The name of compiler to use when compiling. On windows, it \nunderstands 'msvc' and 'gcc' as well as all the compiler names understood by \ndistutils. On Unix, it'll only understand the values understoof by distutils. \n(I should add 'gcc' though to this).\n

        \nOn windows, the compiler defaults to the Microsoft C++ compiler. If this isn't \navailable, it looks for mingw32 (the gcc compiler).\n

        \nOn Unix, it'll probably use the same compiler that was used when compiling \nPython. Cygwin's behavior should be similar.

        \n
        \n\n
        verbose
        \n \n
        \noptional. 0,1, or 2. defualt 0. Speficies how much \n much information is printed during the compile phase of inlining code. 0 is \n silent (except on windows with msvc where it still prints some garbage). 1 \n informs you when compiling starts, finishes, and how long it took. 2 prints \n out the command lines for the compilation process and can be useful if you're \n having problems getting code to work. Its handy for finding the name of the \n .cpp file if you need to examine it. verbose has no affect if the \n compilation isn't necessary. \n
        \n\n
        support_code
        \n \n
        \noptional. string. A string of valid C++ code \n declaring extra code that might be needed by your compiled function. This \n could be declarations of functions, classes, or structures. \n
        \n\n
        customize
        \n \n
        \noptional. base_info.custom_info object. An \n alternative way to specifiy support_code, headers, etc. needed by the \n function see the weave.base_info module for more details. (not sure \n this'll be used much). \n \n
        \n
        type_factories
        \n \n
        \noptional. list of type specification factories. These guys are what convert \nPython data types to C/C++ data types. If you'd like to use a different set of \ntype conversions than the default, specify them here. Look in the type \nconversions section of the main documentation for examples.\n
        \n
        auto_downcast
        \n \n
        \noptional. 0 or 1. default 1. This only affects functions that have Numeric \narrays as input variables. Setting this to 1 will cause all floating point \nvalues to be cast as float instead of double if all the Numeric arrays are of \ntype float. If even one of the arrays has type double or double complex, all \nvariables maintain there standard types.\n
        \n
        \n
        \n\n

        Distutils keywords:

        \n
        \ninline() also accepts a number of distutils keywords \nfor controlling how the code is compiled. The following descriptions have been \ncopied from Greg Ward's distutils.extension.Extension class doc-\nstrings for convenience:\n\n
        \n
        sources
        \n \n
        \n[string] list of source filenames, relative to the \n distribution root (where the setup script lives), in Unix form \n (slash-separated) for portability. Source files may be C, C++, SWIG (.i), \n platform-specific resource files, or whatever else is recognized by the \n \"build_ext\" command as source for a Python extension. Note: The module_path \n file is always appended to the front of this list \n
        \n\n
        include_dirs
        \n \n
        \n[string] list of directories to search for C/C++ \n header files (in Unix form for portability) \n
        \n\n
        define_macros
        \n \n
        \n[(name : string, value : string|None)] list of \n macros to define; each macro is defined using a 2-tuple, where 'value' is \n either the string to define it to or None to define it without a particular \n value (equivalent of \"#define FOO\" in source or -DFOO on Unix C compiler \n command line) \n
        \n
        undef_macros
        \n \n
        \n[string] list of macros to undefine explicitly \n
        \n
        library_dirs
        \n
        \n[string] list of directories to search for C/C++ libraries at link time \n
        \n
        libraries
        \n
        \n[string] list of library names (not filenames or paths) to link against \n
        \n
        runtime_library_dirs
        \n
        \n[string] list of directories to search for C/C++ libraries at run time (for \nshared extensions, this is when the extension is loaded) \n
        \n\n
        extra_objects
        \n \n
        \n[string] list of extra files to link with (eg. \n object files not implied by 'sources', static library that must be \n explicitly specified, binary resource files, etc.) \n
        \n\n
        extra_compile_args
        \n \n
        \n[string] any extra platform- and compiler-specific \n information to use when compiling the source files in 'sources'. For \n platforms and compilers where \"command line\" makes sense, this is typically \n a list of command-line arguments, but for other platforms it could be \n anything. \n
        \n
        extra_link_args
        \n \n
        \n[string] any extra platform- and compiler-specific \n information to use when linking object files together to create the \n extension (or to create a new static Python interpreter). Similar \n interpretation as for 'extra_compile_args'. \n
        \n
        export_symbols
        \n \n
        \n[string] list of symbols to be exported from a shared extension. Not used on \nall platforms, and not generally necessary for Python extensions, which \ntypically export exactly one symbol: \"init\" + extension_name. \n
        \n
        \n
        \n\n\n

        Keyword Option Examples

        \nWe'll walk through several examples here to demonstrate the behavior of \ninline and also how the various arguments are used.\n\nIn the simplest (most) cases, code and arg_names\nare the only arguments that need to be specified. Here's a simple example\nrun on Windows machine that has Microsoft VC++ installed.\n\n 
        \n    >>> from weave import inline\n    >>> a = 'string'\n    >>> code = \"\"\"\n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));\n    ...        \"\"\"\n    >>> inline(code,['a'])\n     sc_86e98826b65b047ffd2cd5f479c627f12.cpp\n    Creating\n       library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f12.lib\n    and object C:\\DOCUME~ 1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ff\n    d2cd5f479c627f12.exp\n    6\n    >>> inline(code,['a'])\n    6\n
        \n \nWhen inline is first run, you'll notice that pause and some \ntrash printed to the screen. The \"trash\" is acutually part of the compilers\noutput that distutils does not supress. On Unix or windows machines with only\ngcc installed, the trash will not appear. On the second call, the code \nfragment is not compiled since it already exists, and only the answer is \nreturned. Now kill the interpreter and restart, and run the same code with\na different string.\n\n 
        \n    >>> from weave import inline\n    >>> a = 'a longer string' \n    >>> code = \"\"\" \n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));  \n    ...        \"\"\"\n    >>> inline(code,['a'])\n    15\n
        \n

        \nNotice this time, inline() did not recompile the code because it\nfound the compiled function in the persistent catalog of functions. There is\na short pause as it looks up and loads the function, but it is much shorter \nthan compiling would require.\n

        \nYou can specify the local and global dictionaries if you'd like (much like \nexec or eval() in Python), but if they aren't \nspecified, the \"expected\" ones are used -- i.e. the ones from the function that \ncalled inline() . This is accomplished through a little call \nframe trickery. Here is an example where the local_dict is specified using\nthe same code example from above:\n\n 

        \n    >>> a = 'a longer string'\n    >>> b = 'an even  longer string' \n    >>> my_dict = {'a':b}\n    >>> inline(code,['a'])\n    15\n    >>> inline(code,['a'],my_dict)\n    21\n
        \n \n

        \nEverytime, the code is changed, inline does a \nrecompile. However, changing any of the other options in inline does not\nforce a recompile. The force option was added so that one\ncould force a recompile when tinkering with other variables. In practice,\nit is just as easy to change the code by a single character\n(like adding a space some place) to force the recompile. Note: It also \nmight be nice to add some methods for purging the cache and on disk \ncatalogs.\n

        \nI use verbose sometimes for debugging. When set to 2, it'll \noutput all the information (including the name of the .cpp file) that you'd\nexpect from running a make file. This is nice if you need to examine the\ngenerated code to see where things are going haywire. Note that error\nmessages from failed compiles are printed to the screen even if verbose\n is set to 0.\n

        \nThe following example demonstrates using gcc instead of the standard msvc \ncompiler on windows using same code fragment as above. Because the example has \nalready been compiled, the force=1 flag is needed to make \ninline() ignore the previously compiled version and recompile \nusing gcc. The verbose flag is added to show what is printed out:\n\n 

        \n    >>>inline(code,['a'],compiler='gcc',verbose=2,force=1)\n    running build_ext    \n    building 'sc_86e98826b65b047ffd2cd5f479c627f13' extension \n    c:\\gcc-2.95.2\\bin\\g++.exe -mno-cygwin -mdll -O2 -w -Wstrict-prototypes -IC:\n    \\home\\ej\\wrk\\scipy\\weave -IC:\\Python21\\Include -c C:\\DOCUME~1\\eric\\LOCAL\n    S~1\\Temp\\python21_compiled\\sc_86e98826b65b047ffd2cd5f479c627f13.cpp -o C:\\D\n    OCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b04\n    7ffd2cd5f479c627f13.o    \n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxextensions.c (C:\\DOCUME~1\\eri\n    c\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxextensions.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxsupport.cxx (C:\\DOCUME~1\\eric\n    \\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxsupport.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\IndirectPythonInterface.cxx (C:\\\n    DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\indirectpythonin\n    terface.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxx_extensions.cxx (C:\\DOCUME~1\\\n    eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxx_extensions.o up-to-da\n    te)\n    writing C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86\n    e98826b65b047ffd2cd5f479c627f13.def\n    c:\\gcc-2.95.2\\bin\\dllwrap.exe --driver-name g++ -mno-cygwin -mdll -static -\n    -output-lib C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\l\n    ibsc_86e98826b65b047ffd2cd5f479c627f13.a --def C:\\DOCUME~1\\eric\\LOCALS~1\\Te\n    mp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f13.def \n    -s C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e9882\n    6b65b047ffd2cd5f479c627f13.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compil\n    ed\\temp\\Release\\cxxextensions.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\cxxsupport.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\indirectpythoninterface.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\n    \\python21_compiled\\temp\\Release\\cxx_extensions.o -LC:\\Python21\\libs -lpytho\n    n21 -o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\sc_86e98826b65b047f\n    fd2cd5f479c627f13.pyd\n    15\n
        \n\nThat's quite a bit of output. verbose=1 just prints the compile\ntime.\n\n 
        \n    >>>inline(code,['a'],compiler='gcc',verbose=1,force=1)\n    Compiling code...\n    finished compiling (sec):  6.00800001621\n    15\n
        \n\n

        \n Note: I've only used the weave option for switching between 'msvc'\nand 'gcc' on windows. It may have use on Unix also, but I don't know yet.\n\n\n

        \nThe support_code argument is likely to be used a lot. It allows \nyou to specify extra code fragments such as function, structure or class \ndefinitions that you want to use in the code string. Note that \nchanges to support_code do not force a recompile. The \ncatalog only relies on code (for performance reasons) to determine \nwhether recompiling is necessary. So, if you make a change to support_code, \nyou'll need to alter code in some way or use the \nforce argument to get the code to recompile. I usually just add \nsome inocuous whitespace to the end of one of the lines in code \nsomewhere. Here's an example of defining a separate method for calculating\nthe string length:\n\n 

        \n    >>> from weave import inline\n    >>> a = 'a longer string'\n    >>> support_code = \"\"\"\n    ...                PyObject* length(Py::String a)\n    ...                {\n    ...                    int l = a.length();  \n    ...                    return Py::new_reference_to(Py::Int(l)); \n    ...                }\n    ...                \"\"\"        \n    >>> inline(\"return_val = length(a);\",['a'],\n    ...        support_code = support_code)\n    15\n
        \n

        \ncustomize is a left over from a previous way of specifying \ncompiler options. It is a custom_info object that can specify \nquite a bit of information about how a file is compiled. These \ninfo objects are the standard way of defining compile information \nfor type conversion classes. However, I don't think they are as handy here, \nespecially since we've exposed all the keyword arguments that distutils can \nhandle. Between these keywords, and the support_code option, I \nthink customize may be obsolete. We'll see if anyone cares to use \nit. If not, it'll get axed in the next version.\n

        \nThe type_factories variable is important to people who want to\ncustomize the way arguments are converted from Python to C. We'll talk about\nthis in the next chapter **xx** of this document when we discuss type\nconversions.\n

        \nauto_downcast handles one of the big type conversion issues that\nis common when using Numeric arrays in conjunction with Python scalar values.\nIf you have an array of single precision values and multiply that array by a \nPython scalar, the result is upcast to a double precision array because the\nscalar value is double precision. This is not usually the desired behavior\nbecause it can double your memory usage. auto_downcast goes\nsome distance towards changing the casting precedence of arrays and scalars.\nIf your only using single precision arrays, it will automatically downcast all\nscalar values from double to single precision when they are passed into the\nC++ code. This is the default behavior. If you want all values to keep there\ndefault type, set auto_downcast to 0.\n

        \n\n\n\n

        Returning Values

        \n\nPython variables in the local and global scope transfer seemlessly from Python \ninto the C++ snippets. And, if inline were to completely live up\nto its name, any modifications to variables in the C++ code would be reflected\nin the Python variables when control was passed back to Python. For example,\nthe desired behavior would be something like:\n\n 
        \n    # THIS DOES NOT WORK\n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    2\n
        \n\nInstead you get:\n\n 
        \n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    1\n
        \n \nVariables are passed into C++ as if you are calling a Python function. Python's \ncalling convention is sometimes called \"pass by assignment\". This means its as \nif a c_a = a assignment is made right before inline \ncall is made and the c_a variable is used within the C++ code. \nThus, any changes made to c_a are not reflected in Python's \na variable. Things do get a little more confusing, however, when \nlooking at variables with mutable types. Changes made in C++ to the contents \nof mutable types are reflected in the Python variables.\n\n 
        \n    >>> a= [1,2]\n    >>> weave.inline(\"PyList_SetItem(a.ptr(),0,PyInt_FromLong(3));\",['a'])\n    >>> print a\n    [3, 2]\n
        \n\nSo modifications to the contents of mutable types in C++ are seen when control\nis returned to Python. Modifications to immutable types such as tuples,\nstrings, and numbers do not alter the Python variables.\n\nIf you need to make changes to an immutable variable, you'll need to assign\nthe new value to the \"magic\" variable return_val in C++. This\nvalue is returned by the inline() function:\n\n 
        \n    >>> a = 1\n    >>> a = weave.inline(\"return_val = Py::new_reference_to(Py::Int(a+1));\",['a'])  \n    >>> a\n    2\n
        \n\nThe return_val variable can also be used to return newly created \nvalues. This is possible by returning a tuple. The following trivial example \nillustrates how this can be done:\n\n 
               \n    # python version\n    def multi_return():\n        return 1, '2nd'\n    \n    # C version.\n    def c_multi_return():    \n        code =  \"\"\"\n     \t        Py::Tuple results(2);\n     \t        results[0] = Py::Int(1);\n     \t        results[1] = Py::String(\"2nd\");\n     \t        return_val = Py::new_reference_to(results); \t        \n                \"\"\"\n        return inline_tools.inline(code)\n
        \n

        \nThe example is available in examples/tuple_return.py. It also\nhas the dubious honor of demonstrating how much inline() can \nslow things down. The C version here is about 10 times slower than the Python\nversion. Of course, something so trivial has no reason to be written in\nC anyway.\n\n\n

        The issue with locals()

        \n

        \ninline passes the locals() and globals() \ndictionaries from Python into the C++ function from the calling function. It \nextracts the variables that are used in the C++ code from these dictionaries, \nconverts then to C++ variables, and then calculates using them. It seems like \nit would be trivial, then, after the calculations were finished to then insert \nthe new values back into the locals() and globals() \ndictionaries so that the modified values were reflected in Python. \nUnfortunately, as pointed out by the Python manual, the locals() dictionary is \nnot writable. \n

        \n\nI suspect locals() is not writable because there are some \noptimizations done to speed lookups of the local namespace. I'm guessing local \nlookups don't always look at a dictionary to find values. Can someone \"in the \nknow\" confirm or correct this? Another thing I'd like to know is whether there \nis a way to write to the local namespace of another stack frame from C/C++. If \nso, it would be possible to have some clean up code in compiled functions that \nwrote final values of variables in C++ back to the correct Python stack frame. \nI think this goes a long way toward making inline truely live up \nto its name. I don't think we'll get to the point of creating variables in \nPython for variables created in C -- although I suppose with a C/C++ parser you \ncould do that also.\n\n

        \n\n\n

        A quick look at the code

        \n\nweave generates a C++ file holding an extension function for \neach inline code snippet. These file names are generated using \nfrom the md5 signature of the code snippet and saved to a location specified by \nthe PYTHONCOMPILED environment variable (discussed later). The cpp files are \ngenerally about 200-400 lines long and include quite a few functions to support \ntype conversions, etc. However, the actual compiled function is pretty simple. \nBelow is the familiar printf example:\n\n 
        \n    >>> import weave    \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
        \n\nAnd here is the extension function generated by inline:\n\n 
        \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        // The Py_None needs an incref before returning\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n        \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try                              \n        {                                \n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n            /* Here is the inline code */            \n            printf(\"%d\\n\",a);\n            /* I would like to fill in changed locals and globals here... */\n        }                                       \n        catch( Py::Exception& e)           \n        {                                \n            return_val =  Py::Null();    \n            exception_occured = 1;       \n        }                                 \n        if(!return_val && !exception_occured)\n        {\n                                      \n            Py_INCREF(Py_None);              \n            return_val = Py_None;            \n        }\n        /* clean up code */\n        \n        /* return */                              \n        return return_val;           \n    }                                \n
        \n\nEvery inline function takes exactly two arguments -- the local and global\ndictionaries for the current scope. All variable values are looked up out\nof these dictionaries. The lookups, along with all inline code \nexecution, are done within a C++ try block. If the variables\naren't found, or there is an error converting a Python variable to the \nappropriate type in C++, an exception is raised. The C++ exception\nis automatically converted to a Python exception by CXX and returned to Python.\n\nThe py_to_int() function illustrates how the conversions and\nexception handling works. py_to_int first checks that the given PyObject*\npointer is not NULL and is a Python integer. If all is well, it calls the\nPython API to convert the value to an int. Otherwise, it calls\nhandle_bad_type() which gathers information about what went wrong\nand then raises a CXX TypeError which returns to Python as a TypeError.\n\n 
        \n    int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
        \n\n 
        \n    void handle_bad_type(PyObject* py_obj, char* good_type, char*  var_name)\n    {\n        char msg[500];\n        sprintf(msg,\"received '%s' type instead of '%s' for variable '%s'\",\n                find_type(py_obj),good_type,var_name);\n        throw Py::TypeError(msg);\n    }\n    \n    char* find_type(PyObject* py_obj)\n    {\n        if(py_obj == NULL) return \"C NULL value\";\n        if(PyCallable_Check(py_obj)) return \"callable\";\n        if(PyString_Check(py_obj)) return \"string\";\n        if(PyInt_Check(py_obj)) return \"int\";\n        if(PyFloat_Check(py_obj)) return \"float\";\n        if(PyDict_Check(py_obj)) return \"dict\";\n        if(PyList_Check(py_obj)) return \"list\";\n        if(PyTuple_Check(py_obj)) return \"tuple\";\n        if(PyFile_Check(py_obj)) return \"file\";\n        if(PyModule_Check(py_obj)) return \"module\";\n        \n        //should probably do more interagation (and thinking) on these.\n        if(PyCallable_Check(py_obj) && PyInstance_Check(py_obj)) return \"callable\";\n        if(PyInstance_Check(py_obj)) return \"instance\"; \n        if(PyCallable_Check(py_obj)) return \"callable\";\n        return \"unkown type\";\n    }\n
        \n\nSince the inline is also executed within the try/catch\nblock, you can use CXX exceptions within your code. It is usually a bad idea\nto directly return from your code, even if an error occurs. This\nskips the clean up section of the extension function. In this simple example,\nthere isn't any clean up code, but in more complicated examples, there may\nbe some reference counting that needs to be taken care of here on converted\nvariables. To avoid this, either uses exceptions or set \nreturn_val to NULL and use if/then's to skip code\nafter errors.\n\n\n

        Technical Details

        \n

        \nThere are \n

          \n
        1. Type conversion \n
        2. Generating C/C++ code \n
        3. Compile the code to an extension module \n
        4. Catalog (and cache) the function for future use
          5. \n
        \n

        \nItems 1 and 2 above are related, but most easily discussed separately. Type \nconversions are customizable by the user if needed. Understanding them is \npretty important for anything beyond trivial uses of inline. \nGenerating the C/C++ code is handled by ext_function and \next_module classes and . For the most part, compiling the code is \nhandled by distutils. Some customizations were needed, but they were \nrelatively minor and do not require changes to distutils itself (although a few \nchanges would be nice...). Cataloging is pretty simple in concept, but surprisingly\nrequired the most code to implement (and still likely needs some work). So,\nthis section covers items 1 and 4 from the list. Item 2 is covered later in\nthe chapter covering the ext_tools module, and distutils is covered\nby a completely separate document xxx.\n \n

        Passing Variables in/out of the C/C++ code

        \n\nNote: Passing variables into the C code is pretty straight forward, but there \nare subtlties to how variable modifications in C are returned to Python. see \nxxx for a more thorough discussion of this issue.\n \n\n\n

        Type Conversions

        \n\n\nNote: Maybe xxx_converter instead of xxx_specification is a more descriptive \nname.\n\n\n

        \nBy default, inline() makes the following type conversions between\nPython and C++ types.\n

        \n\n

        \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
        \n

        Default Data Type Conversions

        \n

        Python

        		\n

        C++

           int   int
           float   double
           complex   std::complex
           string   Py::String
           list   Py::List
           dict   Py::Dict
           tuple   Py::Tuple
           file   FILE*
           callable   PyObject*
           instance   PyObject*
           Numeric.array   PyArrayObject*
           wxXXX   wxXXX*
        \n
        \n

        \nThe Py:: namespace is defined by the \nCXX library which has C++ class\nequivalents for many Python types. std:: is the namespace of the\nstandard library in C++.\n

        \n\nNote: \n

          \n
        • I haven't figured out how to handle long int yet (I think they are currenlty converted \n to int - - check this). \n \n
        • \nHopefully VTK will be added to the list soon
          • \n
        \n
          \n          \n

          \n\nPython to C++ conversions fill in code in several locations in the generated\ninline extension function. Below is the basic template for the\nfunction. This is actually the exact code that is generated by calling\nweave.inline(\"\").\n\n 

          \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n    \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try\n        {\n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            /* argument conversion code */\n            /* inline code */\n            /*I would like to fill in changed locals and globals here...*/\n    \n        }\n        catch( Py::Exception& e)\n        {\n            return_val =  Py::Null();\n            exception_occured = 1;\n        }\n        /* cleanup code */\n        if(!return_val && !exception_occured)\n        {\n    \n            Py_INCREF(Py_None);\n            return_val = Py_None;\n        }\n    \n        return return_val;\n    }\n
          \n\nThe /* inline code */ section is filled with the code passed to\nthe inline() function call. The \n/*argument convserion code*/ and /* cleanup code */\nsections are filled with code that handles conversion from Python to C++\ntypes and code that deallocates memory or manipulates reference counts before\nthe function returns. The following sections demostrate how these two areas\nare filled in by the default conversion methods.\n\n \nNote: I'm not sure I have reference counting correct on a few of these. The \nonly thing I increase/decrease the ref count on is Numeric arrays. If you\nsee an issue, please let me know.\n\n\n\n

          Numeric Argument Conversion

          \n\nInteger, floating point, and complex arguments are handled in a very similar\nfashion. Consider the following inline function that has a single integer \nvariable passed in:\n\n 
          \n    >>> a = 1\n    >>> inline(\"\",['a'])\n
          \n\nThe argument conversion code inserted for a is:\n\n 
          \n    /* argument conversion code */\n    int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
          \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_int() has the following\nform:\n\n 
          \n    static int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
          \n\nSimilarly, the float and complex conversion routines look like:\n\n 
              \n    static double py_to_float(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyFloat_Check(py_obj))\n            handle_bad_type(py_obj,\"float\", name);\n        return PyFloat_AsDouble(py_obj);\n    }\n    \n    static std::complex py_to_complex(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyComplex_Check(py_obj))\n            handle_bad_type(py_obj,\"complex\", name);\n        return std::complex(PyComplex_RealAsDouble(py_obj),\n                                    PyComplex_ImagAsDouble(py_obj));    \n    }\n
          \n\nNumeric conversions do not require any clean up code.\n\n\n

          String, List, Tuple, and Dictionary Conversion

          \n\nStrings, Lists, Tuples and Dictionary conversions are all converted to \nCXX types by default.\n\nFor the following code, \n\n 
          \n    >>> a = [1]\n    >>> inline(\"\",['a'])\n
          \n\nThe argument conversion code inserted for a is:\n\n 
          \n    /* argument conversion code */\n    Py::List a = py_to_list (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
          \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_list() and its\nfriends has the following form:\n\n 
              \n    static Py::List py_to_list(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyList_Check(py_obj))\n            handle_bad_type(py_obj,\"list\", name);\n        return Py::List(py_obj);\n    }\n    \n    static Py::String py_to_string(PyObject* py_obj,char* name)\n    {\n        if (!PyString_Check(py_obj))\n            handle_bad_type(py_obj,\"string\", name);\n        return Py::String(py_obj);\n    }\n\n    static Py::Dict py_to_dict(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyDict_Check(py_obj))\n            handle_bad_type(py_obj,\"dict\", name);\n        return Py::Dict(py_obj);\n    }\n    \n    static Py::Tuple py_to_tuple(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyTuple_Check(py_obj))\n            handle_bad_type(py_obj,\"tuple\", name);\n        return Py::Tuple(py_obj);\n    }\n
          \n\nCXX handles reference counts on for strings, lists, tuples, and dictionaries,\nso clean up code isn't necessary.\n\n\n

          File Conversion

          \n\nFor the following code, \n\n 
          \n    >>> a = open(\"bob\",'w')  \n    >>> inline(\"\",['a'])\n
          \n\nThe argument conversion code is:\n\n 
          \n    /* argument conversion code */\n    PyObject* py_a = get_variable(\"a\",raw_locals,raw_globals);\n    FILE* a = py_to_file(py_a,\"a\");\n
          \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_file() converts\nPyObject* to a FILE* and increments the reference count of the PyObject*:\n\n 
          \n    FILE* py_to_file(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"file\", name);\n    \n        Py_INCREF(py_obj);\n        return PyFile_AsFile(py_obj);\n    }\n
          \n\nBecause the PyObject* was incremented, the clean up code needs to decrement\nthe counter\n\n 
          \n    /* cleanup code */\n    Py_XDECREF(py_a);\n
          \n\nIts important to understand that file conversion only works on actual files --\ni.e. ones created using the open() command in Python. It does\nnot support converting arbitrary objects that support the file interface into\nC FILE* pointers. This can affect many things. For example, in\ninitial printf() examples, one might be tempted to solve the \nproblem of C and Python IDE's (PythonWin, PyCrust, etc.) writing to different\nstdout and stderr by using fprintf() and passing in \nsys.stdout and sys.stderr. For example, instead of\n\n 
          \n    >>> weave.inline('printf(\"hello\\\\n\");')\n
          \n \nYou might try:\n\n 
          \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n
          \n\nThis will work as expected from a standard python interpreter, but in PythonWin,\nthe following occurs:\n\n 
          \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n    Traceback (most recent call last):\n        File \"\", line 1, in ?\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 315, in inline\n            auto_downcast = auto_downcast,\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 386, in compile_function\n            type_factories = type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 197, in __init__\n            auto_downcast, type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 390, in assign_variable_types\n            raise TypeError, format_error_msg(errors)\n        TypeError: {'buf': \"Unable to convert variable 'buf' to a C++ type.\"}\n
          \n\nThe traceback tells us that inline() was unable to convert 'buf' to a\nC++ type (If instance conversion was implemented, the error would have occurred at \nruntime instead). Why is this? Let's look at what the buf object \nreally is:\n\n 
          \n    >>> buf\n    pywin.framework.interact.InteractiveView instance at 00EAD014\n
          \n\nPythonWin has reassigned sys.stdout to a special object that \nimplements the Python file interface. This works great in Python, but since \nthe special object doesn't have a FILE* pointer underlying it, fprintf doesn't \nknow what to do with it (well this will be the problem when instance conversion \nis implemented...).\n\n\n

          Callable, Instance, and Module Conversion

          \n\nNote: Need to look into how ref counts should be handled. Also,\nInstance and Module conversion are not currently implemented.\n\n\n 
          \n    >>> def a(): \n        pass\n    >>> inline(\"\",['a'])\n
          \n\nCallable and instance variables are converted to PyObject*. Nothing is done\nto there reference counts.\n\n 
          \n    /* argument conversion code */\n    PyObject* a = py_to_callable(get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
          \n\nget_variable() reads the variable a\nfrom the local and global namespaces. The py_to_callable() and\npy_to_instance() don't currently increment the ref count.\n\n 
              \n    PyObject* py_to_callable(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyCallable_Check(py_obj))\n            handle_bad_type(py_obj,\"callable\", name);    \n        return py_obj;\n    }\n\n    PyObject* py_to_instance(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"instance\", name);    \n        return py_obj;\n    }\n
          \n \nThere is no cleanup code for callables, modules, or instances.\n\n\n

          Customizing Conversions

          \n

          \nConverting from Python to C++ types is handled by xxx_specification classes. A \ntype specification class actually serve in two related but different \nroles. The first is in determining whether a Python variable that needs to be \nconverted should be represented by the given class. The second is as a code \ngenerator that generate C++ code needed to convert from Python to C++ types for \na specific variable.\n

          \nWhen \n\n 

          \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\",a);',['a'])\n
          \n \nis called for the first time, the code snippet has to be compiled. In this \nprocess, the variable 'a' is tested against a list of type specifications (the \ndefault list is stored in weave/ext_tools.py). The first \nspecification in the list is used to represent the variable. \n\n

          \nExamples of xxx_specification are scattered throughout numerous \n\"xxx_spec.py\" files in the weave package. Closely related to \nthe xxx_specification classes are yyy_info classes. \nThese classes contain compiler, header, and support code information necessary \nfor including a certain set of capabilities (such as blitz++ or CXX support)\nin a compiled module. xxx_specification classes have one or more\nyyy_info classes associated with them.\n\nIf you'd like to define your own set of type specifications, the current best route\nis to examine some of the existing spec and info files. Maybe looking over\nsequence_spec.py and cxx_info.py are a good place to start. After defining \nspecification classes, you'll need to pass them into inline using the \ntype_factories argument. \n\nA lot of times you may just want to change how a specific variable type is \nrepresented. Say you'd rather have Python strings converted to \nstd::string or maybe char* instead of using the CXX \nstring object, but would like all other type conversions to have default \nbehavior. This requires that a new specification class that handles strings\nis written and then prepended to a list of the default type specifications. Since\nit is closer to the front of the list, it effectively overrides the default\nstring specification.\n\nThe following code demonstrates how this is done:\n\n...\n\n\n

          The Catalog

          \n

          \ncatalog.py has a class called catalog that helps keep \ntrack of previously compiled functions. This prevents inline() \nand related functions from having to compile functions everytime they are \ncalled. Instead, catalog will check an in memory cache to see if the function \nhas already been loaded into python. If it hasn't, then it starts searching \nthrough persisent catalogs on disk to see if it finds an entry for the given \nfunction. By saving information about compiled functions to disk, it isn't\nnecessary to re-compile functions everytime you stop and restart the interpreter.\nFunctions are compiled once and stored for future use.\n\n

          \nWhen inline(cpp_code) is called the following things happen:\n

            \n
          1. \n A fast local cache of functions is checked for the last function called for \n cpp_code. If an entry for cpp_code doesn't exist in the \n cache or the cached function call fails (perhaps because the function doesn't \n have compatible types) then the next step is to check the catalog. \n
          2. \n The catalog class also keeps an in-memory cache with a list of all the \n functions compiled for cpp_code. If cpp_code has\n ever been called, then this cache will be present (loaded from disk). If\n the cache isn't present, then it is loaded from disk.\n

            \n If the cache is present, each function in the cache is \n called until one is found that was compiled for the correct argument types. If \n none of the functions work, a new function is compiled with the given argument \n types. This function is written to the on-disk catalog as well as into the \n in-memory cache.

            \n
          3. \n When a lookup for cpp_code fails, the catalog looks through \n the on-disk function catalogs for the entries. The PYTHONCOMPILED variable \n determines where to search for these catalogs and in what order. If \n PYTHONCOMPILED is not present several platform dependent locations are \n searched. All functions found for cpp_code in the path are \n loaded into the in-memory cache with functions found earlier in the search \n path closer to the front of the call list.\n

            \n If the function isn't found in the on-disk catalog, \n then the function is compiled, written to the first writable directory in the \n PYTHONCOMPILED path, and also loaded into the in-memory cache.

            \n
            4. \n
          \n\n\n

          Function Storage: How functions are stored in caches and on disk

          \n

          \nFunction caches are stored as dictionaries where the key is the entire C++\ncode string and the value is either a single function (as in the \"level 1\"\ncache) or a list of functions (as in the main catalog cache). On disk\ncatalogs are stored in the same manor using standard Python shelves.\n

          \nEarly on, there was a question as to whether md5 check sums of the C++\ncode strings should be used instead of the actual code strings. I think this\nis the route inline Perl took. Some (admittedly quick) tests of the md5 vs.\nthe entire string showed that using the entire string was at least a\nfactor of 3 or 4 faster for Python. I think this is because it is more\ntime consuming to compute the md5 value than it is to do look-ups of long\nstrings in the dictionary. Look at the examples/md5_speed.py file for the\ntest run. \n\n\n

          Catalog search paths and the PYTHONCOMPILED variable

          \n

          \nThe default location for catalog files on Unix is is ~/.pythonXX_compiled where \nXX is version of Python being used. If this directory doesn't exist, it is \ncreated the first time a catalog is used. The directory must be writable. If, \nfor any reason it isn't, then the catalog attempts to create a directory based \non your user id in the /tmp directory. The directory permissions are set so \nthat only you have access to the directory. If this fails, I think you're out of \nluck. I don't think either of these should ever fail though. On Windows, a \ndirectory called pythonXX_compiled is created in the user's temporary \ndirectory. \n

          \nThe actual catalog file that lives in this directory is a Python shelve with\na platform specific name such as \"nt21compiled_catalog\" so that multiple OSes\ncan share the same file systems without trampling on each other. Along with\nthe catalog file, the .cpp and .so or .pyd files created by inline will live\nin this directory. The catalog file simply contains keys which are the C++\ncode strings with values that are lists of functions. The function lists point\nat functions within these compiled modules. Each function in the lists \nexecutes the same C++ code string, but compiled for different input variables.\n

          \nYou can use the PYTHONCOMPILED environment variable to specify alternative\nlocations for compiled functions. On Unix this is a colon (':') separated\nlist of directories. On windows, it is a (';') separated list of directories.\nThese directories will be searched prior to the default directory for a\ncompiled function catalog. Also, the first writable directory in the list\nis where all new compiled function catalogs, .cpp and .so or .pyd files are\nwritten. Relative directory paths ('.' and '..') should work fine in the\nPYTHONCOMPILED variable as should environement variables.\n

          \nThere is a \"special\" path variable called MODULE that can be placed in the \nPYTHONCOMPILED variable. It specifies that the compiled catalog should\nreside in the same directory as the module that called it. This is useful\nif an admin wants to build a lot of compiled functions during the build\nof a package and then install them in site-packages along with the package.\nUser's who specify MODULE in their PYTHONCOMPILED variable will have access\nto these compiled functions. Note, however, that if they call the function\nwith a set of argument types that it hasn't previously been built for, the\nnew function will be stored in their default directory (or some other writable\ndirectory in the PYTHONCOMPILED path) because the user will not have write\naccess to the site-packages directory.\n

          \nAn example of using the PYTHONCOMPILED path on bash follows:\n\n 

          \n    PYTHONCOMPILED=MODULE:/some/path;export PYTHONCOMPILED;\n
          \n\nIf you are using python21 on linux, and the module bob.py in site-packages\nhas a compiled function in it, then the catalog search order when calling that\nfunction for the first time in a python session would be:\n\n 
          \n    /usr/lib/python21/site-packages/linuxpython_compiled\n    /some/path/linuxpython_compiled\n    ~/.python21_compiled/linuxpython_compiled\n
          \n\nThe default location is always included in the search path.\n

          \n \nNote: hmmm. see a possible problem here. I should probably make a sub-\ndirectory such as /usr/lib/python21/site-\npackages/python21_compiled/linuxpython_compiled so that library files compiled \nwith python21 are tried to link with python22 files in some strange scenarios. \nNeed to check this.\n\n\n

          \nThe in-module cache (in weave.inline_tools reduces the overhead \nof calling inline functions by about a factor of 2. It can be reduced a little \nmore for type loop calls where the same function is called over and over again \nif the cache was a single value instead of a dictionary, but the benefit is \nvery small (less than 5%) and the utility is quite a bit less. So, we'll stick \nwith a dictionary as the cache.\n

          \n\n\n

          Blitz

          \n Note: most of this section is lifted from old documentation. It should be\npretty accurate, but there may be a few discrepancies.\n

          \nweave.blitz() compiles Numeric Python expressions for fast \nexecution. For most applications, compiled expressions should provide a \nfactor of 2-10 speed-up over Numeric arrays. Using compiled \nexpressions is meant to be as unobtrusive as possible and works much like \npythons exec statement. As an example, the following code fragment takes a 5 \npoint average of the 512x512 2d image, b, and stores it in array, a:\n\n 

          \n    from scipy import *  # or from Numeric import *\n    a = ones((512,512), Float64) \n    b = ones((512,512), Float64) \n    # ...do some stuff to fill in b...\n    # now average\n    a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] \\\n                   + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n
          \n \nTo compile the expression, convert the expression to a string by putting\nquotes around it and then use weave.blitz:\n\n 
          \n    import weave\n    expr = \"a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n                          \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n    weave.blitz(expr)\n
          \n\nThe first time weave.blitz is run for a given expression and \nset of arguements, C++ code that accomplishes the exact same task as the Python \nexpression is generated and compiled to an extension module. This can take up \nto a couple of minutes depending on the complexity of the function. Subsequent \ncalls to the function are very fast. Futher, the generated module is saved \nbetween program executions so that the compilation is only done once for a \ngiven expression and associated set of array types. If the given expression\nis executed with a new set of array types, the code most be compiled again. This\ndoes not overwrite the previously compiled function -- both of them are saved and\navailable for exectution. \n

          \nThe following table compares the run times for standard Numeric code and \ncompiled code for the 5 point averaging.\n

          \n

          \n\n\n\n\n\n
          Method Run Time (seconds)
          Standard Numeric 0.46349
          blitz (1st time compiling) 78.95526
          blitz (subsequent calls) 0.05843 (factor of 8 speedup)
          \n
          \n

          \nThese numbers are for a 512x512 double precision image run on a 400 MHz Celeron \nprocessor under RedHat Linux 6.2.\n

          \nBecause of the slow compile times, its probably most effective to develop \nalgorithms as you usually do using the capabilities of scipy or the Numeric \nmodule. Once the algorithm is perfected, put quotes around it and execute it \nusing weave.blitz. This provides the standard rapid \nprototyping strengths of Python and results in algorithms that run close to \nthat of hand coded C or Fortran.\n\n\n

          Requirements

          \n\nCurrently, the weave.blitz has only been tested under Linux \nwith gcc-2.95-3 and on Windows with Mingw32 (2.95.2). Its compiler \nrequirements are pretty heavy duty (see the \nblitz++ home page), so it won't \nwork with just any compiler. Particularly MSVC++ isn't up to snuff. A number \nof other compilers such as KAI++ will also work, but my suspicions are that gcc \nwill get the most use.\n\n\n

          Limitations

          \n
            \n
          1. \nCurrently, weave.blitz handles all standard mathematic \noperators except for the ** power operator. The built-in trigonmetric, log, \nfloor/ceil, and fabs functions might work (but haven't been tested). It also \nhandles all types of array indexing supported by the Numeric module. \n

            \nweave.blitz does not currently support operations that use \narray broadcasting, nor have any of the special purpose functions in Numeric \nsuch as take, compress, etc. been implemented. Note that there are no obvious \nreasons why most of this functionality cannot be added to scipy.weave, so it \nwill likely trickle into future versions. Using slice() objects \ndirectly instead of start:stop:step is also not supported.\n

            2. \n
          2. \nCurrently Python only works on expressions that include assignment such as\n \n 
            \n    >>> result = b + c + d\n
            \n\nThis means that the result array must exist before calling \nweave.blitz. Future versions will allow the following:\n\n 
            \n    >>> result = weave.blitz_eval(\"b + c + d\")\n
            \n
            3. \n
          3. \nweave.blitz works best when algorithms can be expressed in a \n\"vectorized\" form. Algorithms that have a large number of if/thens and other \nconditions are better hand written in C or Fortran. Further, the restrictions \nimposed by requiring vectorized expressions sometimes preclude the use of more \nefficient data structures or algorithms. For maximum speed in these cases, \nhand-coded C or Fortran code is the only way to go.\n
            4. \n
          4. \nOne other point deserves mention lest people be confused. \nweave.blitz is not a general purpose Python->C compiler. It \nonly works for expressions that contain Numeric arrays and/or \nPython scalar values. This focused scope concentrates effort on the \ncompuationally intensive regions of the program and sidesteps the difficult \nissues associated with a general purpose Python->C compiler.\n
            5. \n
          \n\n\n

          Numeric efficiency issues: What compilation buys you

          \n\nSome might wonder why compiling Numeric expressions to C++ is beneficial since \noperations on Numeric array operations are already executed within C loops. \nThe problem is that anything other than the simplest expression are executed in \nless than optimal fashion. Consider the following Numeric expression:\n\n 
          \n    a = 1.2 * b + c * d\n
          \n \nWhen Numeric calculates the value for the 2d array, a, it does \nthe following steps:\n\n 
          \n    temp1 = 1.2 * b\n    temp2 = c * d\n    a = temp1 + temp2\n
          \n \nTwo things to note. Since c is an (perhaps large) array, a large \ntemporary array must be created to store the results of 1.2 * b. \nThe same is true for temp2. Allocation is slow. The second thing \nis that we have 3 loops executing, one to calculate temp1, one for \ntemp2 and one for adding them up. A C loop for the same problem \nmight look like:\n\n 
          \n    for(int i = 0; i < M; i++)\n        for(int j = 0; j < N; j++)\n            a[i,j] = 1.2 * b[i,j] + c[i,j] * d[i,j]\n
          \n \nHere, the 3 loops have been fused into a single loop and there is no longer\na need for a temporary array. This provides a significant speed improvement\nover the above example (write me and tell me what you get). \n

          \nSo, converting Numeric expressions into C/C++ loops that fuse the loops and \neliminate temporary arrays can provide big gains. The goal then,is to convert \nNumeric expression to C/C++ loops, compile them in an extension module, and \nthen call the compiled extension function. The good news is that there is an \nobvious correspondence between the Numeric expression above and the C loop. The \nbad news is that Numeric is generally much more powerful than this simple \nexample illustrates and handling all possible indexing possibilities results in \nloops that are less than straight forward to write. (take a peak in Numeric for \nconfirmation). Luckily, there are several available tools that simplify the \nprocess.\n\n\n

          The Tools

          \n\nweave.blitz relies heavily on several remarkable tools. On the \nPython side, the main facilitators are Jermey Hylton's parser module and Jim \nHuginin's Numeric module. On the compiled language side, Todd Veldhuizen's \nblitz++ array library, written in C++ (shhhh. don't tell David Beazley), does \nthe heavy lifting. Don't assume that, because it's C++, it's much slower than C \nor Fortran. Blitz++ uses a jaw dropping array of template techniques \n(metaprogramming, template expression, etc) to convert innocent looking and \nreadable C++ expressions into to code that usually executes within a few \npercentage points of Fortran code for the same problem. This is good. \nUnfortunately all the template raz-ma-taz is very expensive to compile, so the \n200 line extension modules often take 2 or more minutes to compile. This isn't so \ngood. weave.blitz works to minimize this issue by remembering \nwhere compiled modules live and reusing them instead of re-compiling every time \na program is re-run.\n\n\n

          Parser

          \nTearing Numeric expressions apart, examining the pieces, and then rebuilding \nthem as C++ (blitz) expressions requires a parser of some sort. I can imagine \nsomeone attacking this problem with regular expressions, but it'd likely be \nugly and fragile. Amazingly, Python solves this problem for us. It actually \nexposes its parsing engine to the world through the parser module. \nThe following fragment creates an Abstract Syntax Tree (AST) object for the \nexpression and then converts to a (rather unpleasant looking) deeply nested list \nrepresentation of the tree. \n \n 
          \n    >>> import parser\n    >>> import scipy.weave.misc\n    >>> ast = parser.suite(\"a = b * c + d\")\n    >>> ast_list = ast.tolist()\n    >>> sym_list = scipy.weave.misc.translate_symbols(ast_list)\n    >>> pprint.pprint(sym_list)\n    ['file_input',\n     ['stmt',\n      ['simple_stmt',\n       ['small_stmt',\n        ['expr_stmt',\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'a']]]]]]]]]]]]]]],\n         ['EQUAL', '='],\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'b']]]],\n                    ['STAR', '*'],\n                    ['factor', ['power', ['atom', ['NAME', 'c']]]]],\n                   ['PLUS', '+'],\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'd']]]]]]]]]]]]]]]]],\n       ['NEWLINE', '']]],\n     ['ENDMARKER', '']]\n
          \n\nDespite its looks, with some tools developed by Jermey H., its possible\nto search these trees for specific patterns (sub-trees), extract the \nsub-tree, manipulate them converting python specific code fragments\nto blitz code fragments, and then re-insert it in the parse tree. The parser\nmodule documentation has some details on how to do this. Traversing the \nnew blitzified tree, writing out the terminal symbols as you go, creates\nour new blitz++ expression string.\n\n \n

          Blitz and Numeric

          \nThe other nice discovery in the project is that the data structure used\nfor Numeric arrays and blitz arrays is nearly identical. Numeric stores\n\"strides\" as byte offsets and blitz stores them as element offsets, but\nother than that, they are the same. Further, most of the concept and\ncapabilities of the two libraries are remarkably similar. It is satisfying \nthat two completely different implementations solved the problem with \nsimilar basic architectures. It is also fortitous. The work involved in \nconverting Numeric expressions to blitz expressions was greatly diminished.\nAs an example, consider the code for slicing an array in Python with a\nstride:\n\n 
          \n    >>> a = b[0:4:2] + c\n    >>> a\n    [0,2,4]\n
          \n\n\nIn Blitz it is as follows:\n\n 
          \n    Array<2,int> b(10);\n    Array<2,int> c(3);\n    // ...\n    Array<2,int> a = b(Range(0,3,2)) + c;\n
          \n\n\nHere the range object works exactly like Python slice objects with the exception\nthat the top index (3) is inclusive where as Python's (4) is exclusive. Other \ndifferences include the type declaraions in C++ and parentheses instead of \nbrackets for indexing arrays. Currently, weave.blitz handles the \ninclusive/exclusive issue by subtracting one from upper indices during the\ntranslation. An alternative that is likely more robust/maintainable in the \nlong run, is to write a PyRange class that behaves like Python's range. \nThis is likely very easy.\n

          \nThe stock blitz also doesn't handle negative indices in ranges. The current \nimplementation of the blitz() has a partial solution to this \nproblem. It calculates and index that starts with a '-' sign by subtracting it \nfrom the maximum index in the array so that:\n\n 

          \n                    upper index limit\n                        /-----\\\n    b[:-1] -> b(Range(0,Nb[0]-1-1))\n
          \n\nThis approach fails, however, when the top index is calculated from other \nvalues. In the following scenario, if i+j evaluates to a negative \nvalue, the compiled code will produce incorrect results and could even core-\ndump. Right now, all calculated indices are assumed to be positive.\n \n 
          \n    b[:i-j] -> b(Range(0,i+j))\n
          \n\nA solution is to calculate all indices up front using if/then to handle the\n+/- cases. This is a little work and results in more code, so it hasn't been\ndone. I'm holding out to see if blitz++ can be modified to handle negative\nindexing, but haven't looked into how much effort is involved yet. While it \nneeds fixin', I don't think there is a ton of code where this is an issue.\n

          \nThe actual translation of the Python expressions to blitz expressions is \ncurrently a two part process. First, all x:y:z slicing expression are removed\nfrom the AST, converted to slice(x,y,z) and re-inserted into the tree. Any\nmath needed on these expressions (subtracting from the \nmaximum index, etc.) are also preformed here. _beg and _end are used as special\nvariables that are defined as blitz::fromBegin and blitz::toEnd.\n\n 

          \n    a[i+j:i+j+1,:] = b[2:3,:] \n
          \n\nbecomes a more verbose:\n \n 
          \n    a[slice(i+j,i+j+1),slice(_beg,_end)] = b[slice(2,3),slice(_beg,_end)]\n
          \n \nThe second part does a simple string search/replace to convert to a blitz \nexpression with the following translations:\n\n 
          \n    slice(_beg,_end) -> _all  # not strictly needed, but cuts down on code.\n    slice            -> blitz::Range\n    [                -> (\n    ]                -> )\n    _stp             -> 1\n
          \n\n_all is defined in the compiled function as \nblitz::Range.all(). These translations could of course happen \ndirectly in the syntax tree. But the string replacement is slightly easier. \nNote that name spaces are maintained in the C++ code to lessen the likelyhood \nof name clashes. Currently no effort is made to detect name clashes. A good \nrule of thumb is don't use values that start with '_' or 'py_' in compiled \nexpressions and you'll be fine.\n\n \n

          Type definitions and coersion

          \n\nSo far we've glossed over the dynamic vs. static typing issue between Python \nand C++. In Python, the type of value that a variable holds can change\nthrough the course of program execution. C/C++, on the other hand, forces you\nto declare the type of value a variables will hold prior at compile time.\nweave.blitz handles this issue by examining the types of the\nvariables in the expression being executed, and compiling a function for those\nexplicit types. For example:\n\n 
          \n    a = ones((5,5),Float32)\n    b = ones((5,5),Float32)\n    weave.blitz(\"a = a + b\")\n
          \n\nWhen compiling this expression to C++, weave.blitz sees that the\nvalues for a and b in the local scope have type Float32, or 'float'\non a 32 bit architecture. As a result, it compiles the function using \nthe float type (no attempt has been made to deal with 64 bit issues).\nIt also goes one step further. If all arrays have the same type, a templated\nversion of the function is made and instantiated for float, double, \ncomplex, and complex arrays. Note: This feature has been \nremoved from the current version of the code. Each version will be compiled\nseparately \n

          \nWhat happens if you call a compiled function with array types that are \ndifferent than the ones for which it was originally compiled? No biggie, you'll \njust have to wait on it to compile a new version for your new types. This \ndoesn't overwrite the old functions, as they are still accessible. See the \ncatalog section in the inline() documentation to see how this is handled. \nSuffice to say, the mechanism is transparent to the user and behaves \nlike dynamic typing with the occasional wait for compiling newly typed \nfunctions.\n

          \nWhen working with combined scalar/array operations, the type of the array is \nalways used. This is similar to the savespace flag that was recently \nadded to Numeric. This prevents issues with the following expression perhaps \nunexpectedly being calculated at a higher (more expensive) precision that can \noccur in Python:\n\n 

          \n    >>> a = array((1,2,3),typecode = Float32)\n    >>> b = a * 2.1 # results in b being a Float64 array.\n
          \n \nIn this example, \n\n 
          \n    >>> a = ones((5,5),Float32)\n    >>> b = ones((5,5),Float32)\n    >>> weave.blitz(\"b = a * 2.1\")\n
          \n \nthe 2.1 is cast down to a float before carrying out \nthe operation. If you really want to force the calculation to be a \ndouble, define a and b as \ndouble arrays.\n

          \nOne other point of note. Currently, you must include both the right hand side \nand left hand side (assignment side) of your equation in the compiled \nexpression. Also, the array being assigned to must be created prior to calling \nweave.blitz. I'm pretty sure this is easily changed so that a \ncompiled_eval expression can be defined, but no effort has been made to \nallocate new arrays (and decern their type) on the fly.\n\n \n

          Cataloging Compiled Functions

          \n\nSee the Cataloging functions section in the \nweave.inline() documentation.\n\n \n

          Checking Array Sizes

          \n\nSurprisingly, one of the big initial problems with compiled code was making\nsure all the arrays in an operation were of compatible type. The following\ncase, is of course, trivially easy:\n\n 
          \n    a = b + c\n
          \n \nIt only requires that arrays a, b, and c \nhave the same shape. However, expressions like:\n\n 
          \n    a[i+j:i+j+1,:] = b[2:3,:] + c\n
          \n\nare not so trivial. Since slicing is involved, the size of the slices, not the \ninput arrays must be checked. Broadcasting complicates things further because \narrays and slices with different dimensions and shapes may be compatible for \nmath operations (broadcasting isn't yet supported by \nweave.blitz). Reductions have a similar effect as their \nresults are different shapes than their input operand. The binary operators in \nNumeric compare the shapes of their two operands just before they operate on \nthem. This is possible because Numeric treats each operation independently. \nThe intermediate (temporary) arrays created during sub-operations in an \nexpression are tested for the correct shape before they are combined by another \noperation. Because weave.blitz fuses all operations into a \nsingle loop, this isn't possible. The shape comparisons must be done and \nguaranteed compatible before evaluating the expression.\n

          \nThe solution chosen converts input arrays to \"dummy arrays\" that only represent \nthe dimensions of the arrays, not the data. Binary operations on dummy arrays \ncheck that input array sizes are comptible and return a dummy array with the \nsize correct size. Evaluating an expression of dummy arrays traces the \nchanging array sizes through all operations and fails if incompatible array \nsizes are ever found. \n

          \nThe machinery for this is housed in weave.size_check. It \nbasically involves writing a new class (dummy array) and overloading it math \noperators to calculate the new sizes correctly. All the code is in Python and \nthere is a fair amount of logic (mainly to handle indexing and slicing) so the \noperation does impose some overhead. For large arrays (ie. 50x50x50), the \noverhead is negligible compared to evaluating the actual expression. For small \narrays (ie. 16x16), the overhead imposed for checking the shapes with this \nmethod can cause the weave.blitz to be slower than evaluating \nthe expression in Python. \n

          \nWhat can be done to reduce the overhead? (1) The size checking code could be \nmoved into C. This would likely remove most of the overhead penalty compared \nto Numeric (although there is also some calling overhead), but no effort has \nbeen made to do this. (2) You can also call weave.blitz with\ncheck_size=0 and the size checking isn't done. However, if the \nsizes aren't compatible, it can cause a core-dump. So, foregoing size_checking\nisn't advisable until your code is well debugged.\n\n \n

          Creating the Extension Module

          \n\nweave.blitz uses the same machinery as \nweave.inline to build the extension module. The only difference\nis the code included in the function is automatically generated from the\nNumeric array expression instead of supplied by the user.\n\n\n

          Extension Modules

          \nweave.inline and weave.blitz are high level tools\nthat generate extension modules automatically. Under the covers, they use several\nclasses from weave.ext_tools to help generate the extension module.\nThe main two classes are ext_module and ext_function (I'd\nlike to add ext_class and ext_method also). These classes\nsimplify the process of generating extension modules by handling most of the \"boiler\nplate\" code automatically.\n\n\nNote: inline actually sub-classes weave.ext_tools.ext_function \nto generate slightly different code than the standard ext_function.\nThe main difference is that the standard class converts function arguments to\nC types, while inline always has two arguments, the local and global dicts, and\nthe grabs the variables that need to be convereted to C from these.\n\n\n\n

          A Simple Example

          \nThe following simple example demonstrates how to build an extension module within\na Python function:\n\n 
          \n    # examples/increment_example.py\n    from weave import ext_tools\n    \n    def build_increment_ext():\n        \"\"\" Build a simple extension with functions that increment numbers.\n            The extension will be built in the local directory.\n        \"\"\"        \n        mod = ext_tools.ext_module('increment_ext')\n    \n        a = 1 # effectively a type declaration for 'a' in the \n              # following functions.\n    \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n        mod.add_function(func)\n        \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+2));\"    \n        func = ext_tools.ext_function('increment_by_2',ext_code,['a'])\n        mod.add_function(func)\n                \n        mod.compile()\n
          \n\n\nThe function build_increment_ext() creates an extension module \nnamed increment_ext and compiles it to a shared library (.so or \n.pyd) that can be loaded into Python.. increment_ext contains two \nfunctions, increment and increment_by_2. \n\nThe first line of build_increment_ext(),\n\n 
          \n        mod = ext_tools.ext_module('increment_ext') \n
          \n\ncreates an ext_module instance that is ready to have \next_function instances added to it. ext_function \ninstances are created much with a calling convention similar to \nweave.inline(). The most common call includes a C/C++ code \nsnippet and a list of the arguments for the function. The following\n\n 
          \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n
          \n \ncreates a C/C++ extension function that is equivalent to the following Python\nfunction:\n\n 
          \n        def increment(a):\n            return a + 1\n
          \n\nA second method is also added to the module and then,\n\n 
          \n        mod.compile()\n
          \n\nis called to build the extension module. By default, the module is created\nin the current working directory.\n\nThis example is available in the examples/increment_example.py file\nfound in the weave directory. At the bottom of the file in the\nmodule's \"main\" program, an attempt to import increment_ext without\nbuilding it is made. If this fails (the module doesn't exist in the PYTHONPATH), \nthe module is built by calling build_increment_ext(). This approach\nonly takes the time consuming ( a few seconds for this example) process of building\nthe module if it hasn't been built before.\n\n 
          \n    if __name__ == \"__main__\":\n        try:\n            import increment_ext\n        except ImportError:\n            build_increment_ext()\n            import increment_ext\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
          \n\n\nNote: If we were willing to always pay the penalty of building the C++ code for \na module, we could store the md5 checksum of the C++ code along with some \ninformation about the compiler, platform, etc. Then, \next_module.compile() could try importing the module before it actually\ncompiles it, check the md5 checksum and other meta-data in the imported module\nwith the meta-data of the code it just produced and only compile the code if\nthe module didn't exist or the meta-data didn't match. This would reduce the\nabove code to:\n\n 
          \n    if __name__ == \"__main__\":\n        build_increment_ext()\n\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
          \n\nNote: There would always be the overhead of building the C++ code, but it would only actually compile the code once. You pay a little in overhead and get cleaner\n\"import\" code. Needs some thought.\n\n

          \n\nIf you run increment_example.py from the command line, you get\nthe following:\n\n 

          \n    [eric@n0]$ python increment_example.py\n    a, a+1: 1 2\n    a, a+2: 1 3\n
          \n\nIf the module didn't exist before it was run, the module is created. If it did\nexist, it is just imported and used.\n\n\n

          Fibonacci Example

          \nexamples/fibonacci.py provides a little more complex example of \nhow to use ext_tools. Fibonacci numbers are a series of numbers \nwhere each number in the series is the sum of the previous two: 1, 1, 2, 3, 5, \n8, etc. Here, the first two numbers in the series are taken to be 1. One \napproach to calculating Fibonacci numbers uses recursive function calls. In \nPython, it might be written as:\n\n 
          \n    def fib(a):\n        if a <= 2:\n            return 1\n        else:\n            return fib(a-2) + fib(a-1)\n
          \n\nIn C, the same function would look something like this:\n\n 
          \n     int fib(int a)\n     {                   \n         if(a <= 2)\n             return 1;\n         else\n             return fib(a-2) + fib(a-1);  \n     }                      \n
          \n\nRecursion is much faster in C than in Python, so it would be beneficial\nto use the C version for fibonacci number calculations instead of the\nPython version. We need an extension function that calls this C function\nto do this. This is possible by including the above code snippet as \n\"support code\" and then calling it from the extension function. Support \ncode snippets (usually structure definitions, helper functions and the like)\nare inserted into the extension module C/C++ file before the extension\nfunction code. Here is how to build the C version of the fibonacci number\ngenerator:\n\n 
          \ndef build_fibonacci():\n    \"\"\" Builds an extension module with fibonacci calculators.\n    \"\"\"\n    mod = ext_tools.ext_module('fibonacci_ext')\n    a = 1 # this is effectively a type declaration\n    \n    # recursive fibonacci in C \n    fib_code = \"\"\"\n                   int fib1(int a)\n                   {                   \n                       if(a <= 2)\n                           return 1;\n                       else\n                           return fib1(a-2) + fib1(a-1);  \n                   }                         \n               \"\"\"\n    ext_code = \"\"\"\n                   int val = fib1(a);\n                   return_val = Py::new_reference_to(Py::Int(val));\n               \"\"\"    \n    fib = ext_tools.ext_function('fib',ext_code,['a'])\n    fib.customize.add_support_code(fib_code)\n    mod.add_function(fib)\n\n    mod.compile()\n\n
          \n\nXXX More about custom_info, and what xxx_info instances are good for.\n\n

          \n\nNote: recursion is not the fastest way to calculate fibonacci numbers, but this \napproach serves nicely for this example.\n\n

          \n\n

          Customizing Type Conversions -- Type Factories

          \nnot written\n\n

          Things I wish weave did

          \n\nIt is possible to get name clashes if you uses a variable name that is already defined\nin a header automatically included (such as stdio.h) For instance, if you\ntry to pass in a variable named stdout, you'll get a cryptic error report\ndue to the fact that stdio.h also defines the name. weave\nshould probably try and handle this in some way.\n\nOther things...", "methods": [], "methods_before": [], "changed_methods": [], "nloc": null, "complexity": null, "token_count": null, "diff_parsed": { "added": [ "should run about 180 tests and spew some speed results along the way. If you", "pass (about 100 and they should complete in several minutes).", "Windows Note: I've had some test fail on windows machines where I have msvc,", "gcc-2.95.2 (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My", "environment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the path.", "The test process runs very smoothly until the end where several test using gcc", "fail with cpp0 not found by g++. If I check os.system('gcc -v') before running", "tests, I get gcc-2.95.3-6. If I check after running tests (and after failure),", "I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\\gcc first in it", "and is not corrupted (msvc/distutils messes with the environment variables, so", "we have to undo its work in some places). If anyone else sees this, let me", "know - - it may just be an quirk on my machine (unlikely). Testing with the", "gcc- 2.95.2 installation always works.", "", "

          ", "", "wxPython Note: wxPython tests are not enabled by default because importing", "wxPython on a Unix machine without access to a X-term will cause the", "program to exit. Anyone know of a safe way to detect whether wxPython", "can be imported and whether a display exists on a machine?", "", "Note: CXX uses templates and therefore may be a little less portable than", "another alternative by Gordan McMillan called SCXX which was inspired by", "CXX. It doesn't use templates so it should compile faster and be more portable.", "SCXX has a few less features, but it appears to me that it would mesh with", "the needs of weave quite well. Hopefully xxx_spec files will be written", "for SCXX in the future, and we'll be able to compare on a more empirical", "basis. Both sets of spec files will probably stick around, it just a question", "of which becomes the default.", "", "

          ", "relatively minor and do not require changes to distutils itself. Cataloging is", "pretty simple in concept, but surprisingly required the most code to implement", "(and still likely needs some work). So, this section covers items 1 and 4 from", "the list. Item 2 is covered later in the chapter covering the", "ext_tools module, and distutils is covered by a completely", "separate document xxx.", "", "are subtlties to how variable modifications in C are returned to Python. see Returning Values for a more thorough discussion of", "this issue.", "", "Note: Maybe xxx_converter instead of", "xxx_specification is a more descriptive name. Might change in", "future version?" ], "deleted": [ "should run about 150 tests and spew some speed results along the way. If you", "pass (about 60 and the run time should be quite a bit less).", "Note: I've had some test fail on windows machines where I have msvc, gcc-2.95.2", "(in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My environment", "has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the path. The test", "process runs very smoothly until the end where several test using gcc fail with", "cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I", "get gcc-2.95.3-6. If I check after running tests (and after failure), I get", "gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\\gcc first in it and", "is not corrupted (msvc/distutils messes with the environment variables, so we", "have to undo its work in some places). If anyone else sees this, let me know -", "- it may just be an quirk on my machine (unlikely). Testing with the gcc-", "2.95.2 installation always works.", "relatively minor and do not require changes to distutils itself (although a few", "changes would be nice...). Cataloging is pretty simple in concept, but surprisingly", "required the most code to implement (and still likely needs some work). So,", "this section covers items 1 and 4 from the list. Item 2 is covered later in", "the chapter covering the ext_tools module, and distutils is covered", "by a completely separate document xxx.", "", "are subtlties to how variable modifications in C are returned to Python. see", "xxx for a more thorough discussion of this issue.", "", "Note: Maybe xxx_converter instead of xxx_specification is a more descriptive", "name.", "

            " ] } }, { "old_path": "weave/wx_spec.py", "new_path": "weave/wx_spec.py", "filename": "wx_spec.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -64,8 +64,8 @@ def __cmp__(self,other):\n cmp(self.type_name,other.type_name)\n \n \"\"\"\n-# this should only be inabled on machines with wx installed\n-# It'll cause major problems otherwise.\n+# this should only be enabled on machines with access to a display device\n+# It'll cause problems otherwise.\n def test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n", "added_lines": 2, "deleted_lines": 2, "source_code": "import wx_info\nimport base_info\nfrom base_spec import base_specification\nfrom types import *\nimport os\n\nwx_support_template = \\\n\"\"\"\nstatic %(wx_class)s* py_to_%(wx_class)s(PyObject* py_obj,char* name)\n{\n %(wx_class)s *wx_ptr;\n \n // work on this error reporting...\n if (SWIG_GetPtrObj(py_obj,(void **) &wx_ptr,\"_%(wx_class)s_p\"))\n handle_bad_type(py_obj,\"%(wx_class)s\", name);\n return wx_ptr;\n} \n\"\"\" \n\nclass wx_specification(base_specification):\n _build_information = [wx_info.wx_info()]\n def __init__(self,class_name=None):\n self.type_name = 'unkown wx_object'\n if class_name:\n # customize support_code for whatever type I was handed.\n vals = {'wx_class': class_name}\n specialized_support = wx_support_template % vals\n custom = base_info.base_info()\n custom._support_code = [specialized_support]\n self._build_information = self._build_information + [custom]\n self.type_name = class_name\n\n def type_match(self,value):\n try:\n class_name = value.this.split('_')[-2]\n if class_name[:2] == 'wx':\n return 1\n except AttributeError:\n pass\n return 0\n \n def type_spec(self,name,value):\n # factory\n class_name = value.this.split('_')[-2]\n new_spec = self.__class__(class_name)\n new_spec.name = name \n return new_spec\n def declaration_code(self,inline=0):\n type = self.type_name\n name = self.name\n var_name = self.retrieve_py_variable(inline)\n template = '%(type)s *%(name)s = '\\\n 'py_to_%(type)s(%(var_name)s,\"%(name)s\");\\n'\n code = template % locals()\n return code\n \n def __repr__(self):\n msg = \"(%s:: name: %s)\" % (self.type_name,self.name)\n return msg\n def __cmp__(self,other):\n #only works for equal\n return cmp(self.name,other.name) or \\\n cmp(self.__class__, other.__class__) or \\\n cmp(self.type_name,other.type_name)\n\n\"\"\"\n# this should only be enabled on machines with access to a display device\n# It'll cause problems otherwise.\ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n\"\"\" ", "source_code_before": "import wx_info\nimport base_info\nfrom base_spec import base_specification\nfrom types import *\nimport os\n\nwx_support_template = \\\n\"\"\"\nstatic %(wx_class)s* py_to_%(wx_class)s(PyObject* py_obj,char* name)\n{\n %(wx_class)s *wx_ptr;\n \n // work on this error reporting...\n if (SWIG_GetPtrObj(py_obj,(void **) &wx_ptr,\"_%(wx_class)s_p\"))\n handle_bad_type(py_obj,\"%(wx_class)s\", name);\n return wx_ptr;\n} \n\"\"\" \n\nclass wx_specification(base_specification):\n _build_information = [wx_info.wx_info()]\n def __init__(self,class_name=None):\n self.type_name = 'unkown wx_object'\n if class_name:\n # customize support_code for whatever type I was handed.\n vals = {'wx_class': class_name}\n specialized_support = wx_support_template % vals\n custom = base_info.base_info()\n custom._support_code = [specialized_support]\n self._build_information = self._build_information + [custom]\n self.type_name = class_name\n\n def type_match(self,value):\n try:\n class_name = value.this.split('_')[-2]\n if class_name[:2] == 'wx':\n return 1\n except AttributeError:\n pass\n return 0\n \n def type_spec(self,name,value):\n # factory\n class_name = value.this.split('_')[-2]\n new_spec = self.__class__(class_name)\n new_spec.name = name \n return new_spec\n def declaration_code(self,inline=0):\n type = self.type_name\n name = self.name\n var_name = self.retrieve_py_variable(inline)\n template = '%(type)s *%(name)s = '\\\n 'py_to_%(type)s(%(var_name)s,\"%(name)s\");\\n'\n code = template % locals()\n return code\n \n def __repr__(self):\n msg = \"(%s:: name: %s)\" % (self.type_name,self.name)\n return msg\n def __cmp__(self,other):\n #only works for equal\n return cmp(self.name,other.name) or \\\n cmp(self.__class__, other.__class__) or \\\n cmp(self.type_name,other.type_name)\n\n\"\"\"\n# this should only be inabled on machines with wx installed\n# It'll cause major problems otherwise.\ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n\"\"\" ", "methods": [ { "name": "__init__", "long_name": "__init__( self , class_name = None )", "filename": "wx_spec.py", "nloc": 9, "complexity": 2, "token_count": 59, "parameters": [ "self", "class_name" ], "start_line": 22, "end_line": 31, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "type_match", "long_name": "type_match( self , value )", "filename": "wx_spec.py", "nloc": 8, "complexity": 3, "token_count": 40, "parameters": [ "self", "value" ], "start_line": 33, "end_line": 40, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "type_spec", "long_name": "type_spec( self , name , value )", "filename": "wx_spec.py", "nloc": 5, "complexity": 1, "token_count": 38, "parameters": [ "self", "name", "value" ], "start_line": 42, "end_line": 47, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "declaration_code", "long_name": "declaration_code( self , inline = 0 )", "filename": "wx_spec.py", "nloc": 8, "complexity": 1, "token_count": 41, "parameters": [ "self", "inline" ], "start_line": 48, "end_line": 55, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "__repr__", "long_name": "__repr__( self )", "filename": "wx_spec.py", "nloc": 3, "complexity": 1, "token_count": 20, "parameters": [ "self" ], "start_line": 57, "end_line": 59, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "__cmp__", "long_name": "__cmp__( self , other )", "filename": "wx_spec.py", "nloc": 4, "complexity": 3, "token_count": 42, "parameters": [ "self", "other" ], "start_line": 60, "end_line": 64, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 } ], "methods_before": [ { "name": "__init__", "long_name": "__init__( self , class_name = None )", "filename": "wx_spec.py", "nloc": 9, "complexity": 2, "token_count": 59, "parameters": [ "self", "class_name" ], "start_line": 22, "end_line": 31, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "type_match", "long_name": "type_match( self , value )", "filename": "wx_spec.py", "nloc": 8, "complexity": 3, "token_count": 40, "parameters": [ "self", "value" ], "start_line": 33, "end_line": 40, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "type_spec", "long_name": "type_spec( self , name , value )", "filename": "wx_spec.py", "nloc": 5, "complexity": 1, "token_count": 38, "parameters": [ "self", "name", "value" ], "start_line": 42, "end_line": 47, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "declaration_code", "long_name": "declaration_code( self , inline = 0 )", "filename": "wx_spec.py", "nloc": 8, "complexity": 1, "token_count": 41, "parameters": [ "self", "inline" ], "start_line": 48, "end_line": 55, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "__repr__", "long_name": "__repr__( self )", "filename": "wx_spec.py", "nloc": 3, "complexity": 1, "token_count": 20, "parameters": [ "self" ], "start_line": 57, "end_line": 59, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "__cmp__", "long_name": "__cmp__( self , other )", "filename": "wx_spec.py", "nloc": 4, "complexity": 3, "token_count": 42, "parameters": [ "self", "other" ], "start_line": 60, "end_line": 64, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 } ], "changed_methods": [], "nloc": 67, "complexity": 11, "token_count": 280, "diff_parsed": { "added": [ "# this should only be enabled on machines with access to a display device", "# It'll cause problems otherwise." ], "deleted": [ "# this should only be inabled on machines with wx installed", "# It'll cause major problems otherwise." ] } } ] }, { "hash": "85b061626931d6aff7e589299bfae9509c8ec320", "msg": "added MANIFEST.in so that I could specify that all .txt files are included in the distribution", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-04T17:24:17+00:00", "author_timezone": 0, "committer_date": "2002-01-04T17:24:17+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "4b8ca90a8260c3718c5b1a7460bc24e22c083b23" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 0, "insertions": 1, "lines": 1, "files": 1, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": null, "new_path": "weave/MANIFEST.in", "filename": "MANIFEST.in", "extension": "in", "change_type": "ADD", "diff": "@@ -0,0 +1 @@\n+include *.txt\n", "added_lines": 1, "deleted_lines": 0, "source_code": "include *.txt\n", "source_code_before": null, "methods": [], "methods_before": [], "changed_methods": [], "nloc": null, "complexity": null, "token_count": null, "diff_parsed": { "added": [ "include *.txt" ], "deleted": [] } } ] }, { "hash": "c6ca53cd5ff3671d088cb1728b40e7ff8c0c5bb6", "msg": "one final pass through before posting to python-dev", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-04T19:19:36+00:00", "author_timezone": 0, "committer_date": "2002-01-04T19:19:36+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "85b061626931d6aff7e589299bfae9509c8ec320" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 40, "insertions": 88, "lines": 128, "files": 1, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": "weave/doc/tutorial.html", "new_path": "weave/doc/tutorial.html", "filename": "tutorial.html", "extension": "html", "change_type": "MODIFY", "diff": "@@ -7,7 +7,8 @@

            Outline

            \n
            \n
            Introduction\n
            Requirements\n-
            Installation and Testing\n+
            Installation\n+
            Testing\n
            Inline\n
            \n
            More with printf\n@@ -162,13 +163,13 @@

            Requirements

            \n build Python. weave itself requires a C++ compiler. If \n you used a C++ compiler to build Python, your probably fine.\n

            \n- On Unix gcc is the preferred choice, because I've done a little \n+ On Unix gcc is the preferred choice because I've done a little \n testing with it. All testing has been done with gcc, but I expect the \n majority of compilers should work for inline and \n ext_tools. The one issue I'm not sure about is that I've \n hard coded things so that compilations are linked with the \n- stdc++ library. Is this standard across \n- Unix compilers, or is this a gcc-ism?\n+ stdc++ library. Is this standard across \n+ Unix compilers, or is this a gcc-ism?\n

            \n For blitz(), you'll need a reasonably recent version of \n gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n@@ -190,7 +191,8 @@

            Requirements

            \n The python Numeric module from here. is required for \n blitz() to work. Be sure and get NumPy, not NumArray\n- which is the \"next generation\" implementation.\n+ which is the \"next generation\" implementation. This is not\n+ required for using inline() or ext_tools.\n

            \n \n

          • scipy_distutils and scipy_test (packaged with weave)\n@@ -205,7 +207,7 @@

            Requirements

            \n

            \n \n \n-

            Installation and Testing

            \n+

            Installation

            \n

            \n There are currently two ways to get weave. Fist, \n weave is part of SciPy and installed automatically (as a sub-\n@@ -216,7 +218,7 @@

            Installation and Testing

            \n \n

            \n The stand-alone version can be downloaded from here. Unix users should grab the \n+href=\"http://www.scipy.org/weave\">here. Unix users should grab the \n tar ball (.tgz file) and install it using the following commands.\n \n 

            \n@@ -227,31 +229,54 @@ 
            Installation and Testing
            \n \n This will also install two other packages, scipy_distutils and \n scipy_test.  The first is needed by the setup process itself and \n-both are used in the unit-testing process. For Windows users, it's even easier. \n-They can download the click-install .exe file and run it for automatic \n-installation.  Numeric is required if you want to use blitz(), but\n-isn't necessary for inline() or ext_tools\n+both are used in the unit-testing process.  Numeric is required if you want to \n+use blitz(), but isn't necessary for inline() or \n+ext_tools\n 
            \n-If you're using the CVS version, you'll need to install scipy_distutils and \n-scipy_test modules (also available from CVS) on your own.\n+For Windows users, it's even easier. You can download the click-install .exe \n+file and run it for automatic installation.  There is also a .zip file of the\n+source for those interested.  It also includes a setup.py file to simplify\n+installation.  \n 
            \n- Note: The dependency issue here is a little sticky.  I hate to make people \n+If you're using the CVS version, you'll need to install \n+scipy_distutils and scipy_test packages (also \n+available from CVS) on your own.\n+
            \n+ \n+Note: The dependency issue here is a little sticky.  I hate to make people \n download more than one file (and so I haven't), but distutils doesn't have a \n way to do conditional installation -- at least that I know about.  This can \n-lead to undesired clobbering of modules.  What to do, what to do...\n+lead to undesired clobbering of the scipy_test and scipy_distutils modules. \n+What to do, what to do...  Right now it is a very minor issue.\n+\n 
            \n+\n+
            Testing
            \n Once weave is installed, fire up python and run its unit tests.\n \n     
            \n     >>> import weave\n     >>> weave.test()\n-    runs long time... spews tons of output\n+    runs long time... spews tons of output and a few warnings\n+    .\n+    .\n+    .\n+    ..............................................................\n+    ................................................................\n+    ..................................................\n+    ----------------------------------------------------------------------\n+    Ran 184 tests in 158.418s\n+\n+    OK\n+    \n+    >>> \n     
                    \n \n This takes a loooong time.  On windows, it is usually several minutes.  On Unix \n with remote file systems, I've had it take 15 or so minutes.  In the end, it \n should run about 180 tests and spew some speed results along the way.  If you \n-get errors, please let me know.\n+get errors, they'll be reported at the end of the output.  Please let me know\n+what if this occurs.\n \n If you don't have Numeric installed, you'll get some module import errors \n during the test setup phase for modules that are Numeric specific (blitz_spec, \n@@ -269,25 +294,46 @@ 
            Installation and Testing
            \n     Ran 7 tests in 23.284s\n
            \n \n-Windows Note: I've had some test fail on windows machines where I have msvc, \n-gcc-2.95.2 (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My \n-environment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the path. \n-The test process runs very smoothly until the end where several test using gcc \n-fail with cpp0 not found by g++. If I check os.system('gcc -v') before running \n-tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), \n-I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\\gcc first in it \n-and is not corrupted (msvc/distutils messes with the environment variables, so \n-we have to undo its work in some places). If anyone else sees this, let me \n-know - - it may just be an quirk on my machine (unlikely). Testing with the \n-gcc- 2.95.2 installation always works.\n+Testing Notes:\n+
              \n+
            • \n+ Windows 1\n+

              \n+ I've had some test fail on windows machines where I have msvc, gcc-2.95.2 \n+ (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My \n+ environment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the \n+ path. The test process runs very smoothly until the end where several test \n+ using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') \n+ before running tests, I get gcc-2.95.3-6. If I check after running tests \n+ (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] \n+ still has c:\\gcc first in it and is not corrupted (msvc/distutils messes \n+ with the environment variables, so we have to undo its work in some \n+ places). If anyone else sees this, let me know - - it may just be an quirk \n+ on my machine (unlikely). Testing with the gcc- 2.95.2 installation always \n+ works.\n+

              \n+

              • \n+
            • \n+ Windows 2\n+

              \n+ If you run the tests from PythonWin or some other GUI tool, you'll get a\n+ ton of DOS windows popping up periodically as weave spawns\n+ the compiler multiple times. Very annoying. Anyone know how to fix this?\n+

              \n+

              • \n+
            • \n+ wxPython\n+

              \n+ wxPython tests are not enabled by default because importing wxPython on a \n+ Unix machine without access to a X-term will cause the program to exit. \n+ Anyone know of a safe way to detect whether wxPython can be imported and \n+ whether a display exists on a machine? \n+

              \n+

              • \n               \n+\n

              \n-\n-wxPython Note: wxPython tests are not enabled by default because importing\n-wxPython on a Unix machine without access to a X-term will cause the \n-program to exit. Anyone know of a safe way to detect whether wxPython\n-can be imported and whether a display exists on a machine?\n-\n+

            \n \n \n

            Inline

            \n@@ -366,7 +412,7 @@

            More with printf

            \n 1\n             \n

            \n-Nothing bead is happening, its just a bit annoying. Anyone know how to \n+Nothing bad is happening, its just a bit annoying. Anyone know how to \n turn this off? \n

            \n This example also demonstrates using 'raw strings'. The r \n@@ -1031,7 +1077,9 @@

            Keyword Option Examples

            \n \n When inline is first run, you'll notice that pause and some \n trash printed to the screen. The \"trash\" is acutually part of the compilers\n-output that distutils does not supress. On Unix or windows machines with only\n+output that distutils does not supress. The name of the extension file, \n+sc_bighonkingnumber.cpp, is generated from the md5 check sum\n+of the C/C++ code fragment. On Unix or windows machines with only\n gcc installed, the trash will not appear. On the second call, the code \n fragment is not compiled since it already exists, and only the answer is \n returned. Now kill the interpreter and restart, and run the same code with\n@@ -1140,7 +1188,7 @@

            Keyword Option Examples

            \n \n \n

            \n- Note: I've only used the weave option for switching between 'msvc'\n+ Note: I've only used the compiler option for switching between 'msvc'\n and 'gcc' on windows. It may have use on Unix also, but I don't know yet.\n \n \n@@ -1439,7 +1487,7 @@

            A quick look at the code

            \n \n

            Technical Details

            \n

            \n-There are \n+There are several main steps to using C/C++ code withing Python:\n

              \n
            1. Type conversion \n
            2. Generating C/C++ code \n@@ -2454,7 +2502,7 @@

              Checking Array Sizes

              \n \n Surprisingly, one of the big initial problems with compiled code was making\n sure all the arrays in an operation were of compatible type. The following\n-case, is of course, trivially easy:\n+case is trivially easy:\n \n 
              \n     a = b + c\n@@ -2658,7 +2706,7 @@ 
               A Simple Example 
              \n exist, it is just imported and used.\n \n \n-
               Fibonacci Example 
              \n+
               Fibonacci Example 
              \n examples/fibonacci.py provides a little more complex example of \n how to use ext_tools.  Fibonacci numbers are a series of numbers \n where each number in the series is the sum of the previous two: 1, 1, 2, 3, 5, \n",
                "added_lines": 88,
                "deleted_lines": 40,
                "source_code": "\n
              Weave Documentation
              \n
              \nBy Eric Jones eric@enthought.com\n
              \n
              Outline
              \n
               \n
               Introduction\n
               Requirements\n
               Installation\n
               Testing\n
               Inline\n    
              \n        
              More with printf\n        
              \n        More examples\n        
              \n            
              Binary search\n            
              Dictionary sort\n            
              Numeric -- cast/copy/transpose\n            
              wxPython
              \n        
              \n        
              Keyword options\n        
              Returning values\n        
              \n            
              \n                        The issue with locals()
              \n        
              \n        
              A quick look at the code\n        
              \n        Technical Details\n        
              \n            
              Converting Types\n                
              \n                    
              \n                        Numeric Argument Conversion\n                    
              \n                        String, List, Tuple, and Dictionary Conversion\n                    
              File Conversion \n                        
              \n                        Callable, Instance, and Module Conversion                \n                    
              Customizing Conversions\n                
                  \n            
              Compiling Code\n            
              \"Cataloging\" functions\n            
              \n                
              Function Storage\n                
              The PYTHONCOMPILED evnironment variable
              \n            
              \n            
                  \n        
              \n        
                      \n    
              \n
              Blitz\n    
              \n        
              Requirements\n        
              Limitations\n        
              Numeric Efficiency Issues\n        
              The Tools        \n        
              \n            
              Parser\n            
              Blitz and Numeric\n        
              \n        
              Type defintions and coersion\n        
              Cataloging Compiled Functions\n        
              Checking Array Sizes\n         
              Creating the Extension Module\n    
              \n
                Extension Modules\n    
              \n        
              A Simple Example\n        
              Fibonacci Example\n   
              \n
                Customizing Type Conversions -- Type Factories (not written)\n    
              \n        
              Type Specifications\n        
              Type Information\n        
              The Conversion Process    \n    
                  \n
              \n\n
              Introduction
              \n\n
              \nThe weave package provides tools for including C/C++ code within\nin Python code.  This offers both another level of optimization to those who need \nit, and an easy way to modify and extend any supported extension libraries such \nas wxPython and hopefully VTK soon. Inlining C/C++ code within Python generally\nresults in speed ups of 1.5x to 30x speed-up over algorithms written in pure\nPython (However, it is also possible to slow things down...).  Generally \nalgorithms that require a large number of calls to the Python API don't benefit\nas much from the conversion to C/C++ as algorithms that have inner loops \ncompletely convertable to C.\n
               \nThere are three basic ways to use weave. The \nweave.inline() function executes C code directly within Python, \nand weave.blitz() translates Python Numeric expressions to C++ \nfor fast execution.  blitz() was the original reason \nweave was built.  For those interested in building extension\nlibraries, the ext_tools module provides classes for building \nextension modules within Python. \n
              \nMost of weave's functionality should work on Windows and Unix, \nalthough some of its functionality requires gcc or a similarly \nmodern C++ compiler that handles templates well.  Up to now, most testing has \nbeen done on Windows 2000 with Microsoft's C++ compiler (MSVC) and with gcc \n(mingw32 2.95.2 and 2.95.3-6). All tests also pass on Linux (RH 7.1 \nwith gcc 2.96), and I've had reports that it works on Debian also (thanks \nPearu).\n
              \nThe inline and blitz provide new functionality to \nPython (although I've recently learned about the PyInline project which may offer \nsimilar functionality to inline).  On the other hand, tools for \nbuilding Python extension modules already exists (SWIG, SIP, pycpp, CXX, and \nothers). As of yet, I'm not sure where weave fits in this \nspectrum. It is closest in flavor to CXX in that it makes creating new C/C++ \nextension modules pretty easy. However, if you're wrapping a gaggle of legacy \nfunctions or classes, SWIG and friends are definitely the better choice. \nweave is set up so that you can customize how Python types are \nconverted to C types in weave. This is great for \ninline(), but, for wrapping legacy code, it is more flexible to \nspecify things the other way around -- that is how C types map to Python types. \nThis weave does not do.  I guess it would be possible to build \nsuch a tool on top of weave, but with good tools like SWIG around, \nI'm not sure the effort produces any new capabilities. Things like function \noverloading are probably easily implemented in weave and it might \nbe easier to mix Python/C code in function calls, but nothing beyond this comes \nto mind. So, if you're developing new extension modules or optimizing Python \nfunctions in C, weave.ext_tools() might be the tool \nfor you. If you're wrapping legacy code, stick with SWIG.\n
              \nThe next several sections give the basics of how to use weave.\nWe'll discuss what's happening under the covers in more detail later \non.  Serious users will need to at least look at the type conversion section to \nunderstand how Python variables map to C/C++ types and how to customize this \nbehavior.  One other note.  If you don't know C or C++ then these docs are \nprobably of very little help to you. Further, it'd be helpful if you know \nsomething about writing Python extensions. weave does quite a \nbit for you, but for anything complex, you'll need to do some conversions, \nreference counting, etc.\n
              \n\nNote: weave is actually part of the SciPy package.  However, it works fine as a \nstandalone package.  The examples here are given as if it is used as a stand \nalone package.  If you are using from within scipy, you can use  from \nscipy import weave and the examples will work identically.\n\n\n
              Requirements
              \n
                \n    
              •  Python\n         
                \n         I use 2.1.1.  Probably 2.0 or higher should work.\n         
                \n    
                • \n    \n    
              •  C++ compiler\n         
                \n         weave uses distutils to actually build \n         extension modules, so it uses whatever compiler was originally used to \n         build Python.  weave itself requires a C++ compiler.  If \n         you used a C++ compiler to build Python, your probably fine.\n         
                \n         On Unix gcc is the preferred choice because I've done a little \n         testing with it.  All testing has been done with gcc, but I expect the \n         majority of compilers should work for inline and \n         ext_tools.  The one issue I'm not sure about is that I've \n         hard coded things so that compilations are linked with the \n         stdc++ library.  Is this standard across \n         Unix compilers, or is this a gcc-ism?\n         
                \n         For blitz(), you'll need a reasonably recent version of \n         gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n         versions are likely to work.  Its likely that KAI's C++ compiler and \n         maybe some others will work, but I haven't tried. My advise is to use \n         gcc for now unless your willing to tinker with the code some.\n         
                \n         On Windows, either MSVC or gcc (www.mingw.org\" > mingw32) should work.  Again, \n         you'll need gcc for blitz() as the\n         MSVC compiler doesn't handle templates well.\n         
                \n         I have not tried Cygwin, so please report success if it works for you.\n         
                \n    
                • \n\n    
              •  Numeric (optional)\n         
                \n         The python Numeric module from here. is required for \n         blitz() to work. Be sure and get NumPy, not NumArray\n         which is the \"next generation\" implementation.  This is not\n         required for using inline() or ext_tools.\n         
                \n    
                • \n    
              •  scipy_distutils and scipy_test (packaged with weave)\n         
                \n         These two modules are packaged with weave in both\n         the windows installer and the source distributions.  If you are using\n         CVS, however, you'll need to download these separately (also available\n         through CVS at SciPy).\n         
                \n    
                • \n
              \n
              \n\n\n
              Installation
              \n
              \nThere are currently two ways to get weave. Fist, \nweave is part of SciPy and installed automatically (as a sub-\npackage) whenever SciPy is installed (although the latest version isn't in \nSciPy yet, so use this one for now).  Second, since weave is \nuseful outside of the scientific community, it has been setup so that it can be\nused as a stand-alone module. \n\n
              \nThe stand-alone version can be downloaded from here.  Unix users should grab the \ntar ball (.tgz file) and install it using the following commands.\n\n    
              \n    tar -xzvf weave-0.2.tar.gz\n    cd weave-0.2\n    python setup.py install\n    
                      \n\nThis will also install two other packages, scipy_distutils and \nscipy_test.  The first is needed by the setup process itself and \nboth are used in the unit-testing process.  Numeric is required if you want to \nuse blitz(), but isn't necessary for inline() or \next_tools\n
              \nFor Windows users, it's even easier. You can download the click-install .exe \nfile and run it for automatic installation.  There is also a .zip file of the\nsource for those interested.  It also includes a setup.py file to simplify\ninstallation.  \n
              \nIf you're using the CVS version, you'll need to install \nscipy_distutils and scipy_test packages (also \navailable from CVS) on your own.\n
              \n \nNote: The dependency issue here is a little sticky.  I hate to make people \ndownload more than one file (and so I haven't), but distutils doesn't have a \nway to do conditional installation -- at least that I know about.  This can \nlead to undesired clobbering of the scipy_test and scipy_distutils modules. \nWhat to do, what to do...  Right now it is a very minor issue.\n\n
              \n\n
              Testing
              \nOnce weave is installed, fire up python and run its unit tests.\n\n    
              \n    >>> import weave\n    >>> weave.test()\n    runs long time... spews tons of output and a few warnings\n    .\n    .\n    .\n    ..............................................................\n    ................................................................\n    ..................................................\n    ----------------------------------------------------------------------\n    Ran 184 tests in 158.418s\n\n    OK\n    \n    >>> \n    
                      \n\nThis takes a loooong time.  On windows, it is usually several minutes.  On Unix \nwith remote file systems, I've had it take 15 or so minutes.  In the end, it \nshould run about 180 tests and spew some speed results along the way.  If you \nget errors, they'll be reported at the end of the output.  Please let me know\nwhat if this occurs.\n\nIf you don't have Numeric installed, you'll get some module import errors \nduring the test setup phase for modules that are Numeric specific (blitz_spec, \nblitz_tools, size_check, standard_array_spec, ast_tools), but all test should\npass (about 100 and they should complete in several minutes).\n
              \nIf you only want to test a single module of the package, you can do this by\nrunning test() for that specific module.\n\n    
              \n    >>> import weave.scalar_spec\n    >>> weave.scalar_spec.test()\n    .......\n    ----------------------------------------------------------------------\n    Ran 7 tests in 23.284s\n    
                      \n\nTesting Notes:\n
                \n    
              • \n    Windows 1\n    
                \n    I've had some test fail on windows machines where I have msvc, gcc-2.95.2 \n    (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My \n    environment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the \n    path. The test process runs very smoothly until the end where several test \n    using gcc fail with cpp0 not found by g++.  If I check os.system('gcc -v') \n    before running tests, I get gcc-2.95.3-6.  If I check after running tests \n    (and after failure), I get gcc-2.95.2. ??huh??.  The os.environ['PATH'] \n    still has c:\\gcc first in it and is not corrupted (msvc/distutils messes \n    with the environment variables, so we have to undo its work in some \n    places).  If anyone else sees this, let me know - - it may just be an quirk \n    on my machine (unlikely).  Testing with the gcc- 2.95.2 installation always \n    works.\n    
                \n    
                • \n    
              • \n    Windows 2\n    
                \n    If you run the tests from PythonWin or some other GUI tool, you'll get a\n    ton of DOS windows popping up periodically as weave spawns\n    the compiler multiple times.  Very annoying.  Anyone know how to fix this?\n    
                \n    
                • \n    
              • \n    wxPython\n    
                \n    wxPython tests are not enabled by default because importing wxPython on a \n    Unix machine without access to a X-term will cause the program to exit. \n    Anyone know of a safe way to detect whether wxPython can be imported and \n    whether a display exists on a machine?    \n    
                \n    
                • \n                \n\n
                \n
              \n\n\n
              Inline
              \n
              \ninline() compiles and executes C/C++ code on the fly.  Variables \nin the local and global Python scope are also available in the C/C++ code. \nValues are passed to the C/C++ code by assignment much like variables \nare passed into a standard Python function.  Values are returned from the C/C++ \ncode through a special argument called return_val.  Also, the contents of \nmutable objects can be changed within the C/C++ code and the changes remain \nafter the C code exits and returns to Python. (more on this later)\n
                      \nHere's a trivial printf example using inline():\n\n    
              \n    >>> import weave    \n    >>> a  = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n    
                      \n
              \nIn this, its most basic form, inline(c_code, var_list) requires two \narguments.  c_code is a string of valid C/C++ code. \nvar_list is a list of variable names that are passed from \nPython into C/C++.  Here we have a simple printf statement that \nwrites the Python variable a to the screen. The first time you run \nthis, there will be a pause while the code is written to a .cpp file, compiled \ninto an extension module, loaded into Python, cataloged for future use, and \nexecuted.  On windows (850 MHz PIII), this takes about 1.5 seconds when using \nMicrosoft's C++ compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). \nAll subsequent executions of the code will happen very quickly because the code \nonly needs to be compiled once.  If you kill and restart the interpreter and then \nexecute the same code fragment again, there will be a much shorter delay in the \nfractions of seconds range. This is because weave stores a \ncatalog of all previously compiled functions in an on disk cache. When it sees \na string that has been compiled, it loads the already compiled module and \nexecutes the appropriate function.  \n
              \n\nNote: If you try the printf example in a GUI shell such as IDLE, \nPythonWin, PyShell, etc., you're unlikely to see the output.  This is because the \nC code is writing to stdout, instead of to the GUI window.  This doesn't mean \nthat inline doesn't work in these environments -- it only means that standard \nout in C is not the same as the standard out for Python in these cases.  Non \ninput/output functions will work as expected.\n\n
              \nAlthough effort has been made to reduce the overhead associated with calling \ninline, it is still less efficient for simple code snippets than using \nequivalent Python code.  The simple printf example is actually \nslower by 30% or so than using Python print statement. And, it is \nnot difficult to create code fragments that are 8-10 times slower using inline \nthan equivalent Python.  However, for more complicated algorithms, \nthe speed up can be worth while -- anywhwere from 1.5- 30 times faster. \nAlgorithms that have to manipulate Python objects (sorting a list) usually only \nsee a factor of 2 or so improvement.  Algorithms that are highly computational \nor manipulate Numeric arrays can see much larger improvements.  The \nexamples/vq.py file shows a factor of 30 or more improvement on the vector \nquantization algorithm that is used heavily in information theory and \nclassification problems.\n
              \n\n\n
              More with printf
              \n
              \nMSVC users will actually see a bit of compiler output that distutils does not\nsupress the first time the code executes:\n\n    
                  \n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    sc_e013937dbc8c647ac62438874e5795131.cpp\n       Creating library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\n       \\Release\\sc_e013937dbc8c647ac62438874e5795131.lib and object C:\\DOCUME\n       ~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_e013937dbc8c64\n       7ac62438874e5795131.exp\n    1\n    
              \n
              \nNothing bad is happening, its just a bit annoying.  Anyone know how to \nturn this off?    \n
              \nThis example also demonstrates using 'raw strings'. The r \npreceeding the code string in the last example denotes that this is a 'raw \nstring'.  In raw strings, the backslash character is not interpreted as an \nescape character, and so it isn't necessary to use a double backslash to \nindicate that the '\\n' is meant to be interpreted in the C printf \nstatement instead of by Python.  If your C code contains a lot\nof strings and control characters, raw strings might make things easier.\nMost of the time, however, standard strings work just as well.\n\n
              \nThe printf statement in these examples is formatted to print \nout integers.  What happens if a is a string?  inline\nwill happily, compile a new version of the code to accept strings as input,\nand execute the code.  The result?\n\n    
                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    32956972\n    
                    \n
              \nIn this case, the result is non-sensical, but also non-fatal.  In other \nsituations, it might produce a compile time error because a is \nrequired to be an integer at some point in the code, or it could produce a \nsegmentation fault.  Its possible to protect against passing \ninline arguments of the wrong data type by using asserts in \nPython.\n\n    
                  \n    >>> a = 'string'\n    >>> def protected_printf(a):    \n    ...     assert(type(a) == type(1))\n    ...     weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    >>> protected_printf(1)\n     1\n    >>> protected_printf('string')\n    AssertError...\n    
                    \n\n
              \nFor printing strings, the format statement needs to be changed.\n\n    
                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%s\\n\",a);',['a'])\n    string\n    
                    \n\n
              \nAs in this case, C/C++ code fragments often have to change to accept different \ntypes. For the given printing task, however, C++ streams provide a way of a \nsingle statement that works for integers and strings.  By default, the stream \nobjects live in the std (standard) namespace and thus require the use of \nstd::.\n\n    
                  \n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    1    \n    >>> a = 'string'\n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    string\n    
               \n         \n
              \nExamples using printf and cout are included in \nexamples/print_example.py.\n\n\n
               More examples 
              \n\nThis section shows several more advanced uses of inline.  It \nincludes a few algorithms from the Python Cookbook \nthat have been re-written in inline C to improve speed as well as a couple \nexamples using Numeric and wxPython.\n\n\n
               Binary search
              \nLets look at the example of searching a sorted list of integers for a value. \nFor inspiration, we'll use Kalle Svensson's  \nbinary_search() algorithm from the Python Cookbook.  His recipe follows:\n\n    
              \n    def binary_search(seq, t):\n        min = 0; max = len(seq) - 1\n        while 1:\n            if max < min:\n                return -1\n            m = (min  + max)  / 2\n            if seq[m] < t: \n                min = m  + 1 \n            elif seq[m] > t: \n                max = m  - 1 \n            else:\n                return m    \n
              \n\nThis Python version works for arbitrary Python data types. The C version below is \nspecialized to handle integer values. There is a little type checking done in \nPython to assure that we're working with the correct data types before heading \ninto C. The variables seq and t don't need to be \ndeclared beacuse weave handles converting and declaring them in \nthe C code. All other temporary variables such as min, max, etc. \nmust be declared -- it is C after all. Here's the new mixed Python/C function:\n\n 
                  \n    def c_int_binary_search(seq,t):\n        # do a little type checking in Python\n        assert(type(t) == type(1))\n        assert(type(seq) == type([]))\n        \n        # now the C code\n        code = \"\"\"\n               #line 29 \"binary_search.py\"\n               int val, m, min = 0;  \n               int max = seq.length() - 1;\n               PyObject *py_val; \n               for(;;)\n               {\n                   if (max < min  ) \n                   { \n                       return_val =  Py::new_reference_to(Py::Int(-1)); \n                       break;\n                   } \n                   m =  (min + max) /2;\n                   val =    py_to_int(PyList_GetItem(seq.ptr(),m),\"val\"); \n                   if (val  < t) \n                       min = m  + 1;\n                   else if (val >  t)\n                       max = m - 1;\n                   else\n                   {\n                       return_val = Py::new_reference_to(Py::Int(m));\n                       break;\n                   }\n               }\n               \"\"\"\n        return inline(code,['seq','t'])\n
              \n

              \nWe have two variables seq and t passed in. \nt is guaranteed (by the assert) to be an integer. \nPython integers are converted to C int types in the transition from Python to \nC. seq is a Python list. By default, it is translated to a CXX \nlist object. Full documentation for the CXX library can be found at its website. The basics are that the CXX \nprovides C++ class equivalents for Python objects that simplify, or at \nleast object orientify, working with Python objects in C/C++. For example, \nseq.length() returns the length of the list. A little more about\nCXX and its class methods, etc. is in the ** type conversions ** section.\n

              \n\nNote: CXX uses templates and therefore may be a little less portable than \nanother alternative by Gordan McMillan called SCXX which was inspired by\nCXX. It doesn't use templates so it should compile faster and be more portable.\nSCXX has a few less features, but it appears to me that it would mesh with\nthe needs of weave quite well. Hopefully xxx_spec files will be written\nfor SCXX in the future, and we'll be able to compare on a more empirical\nbasis. Both sets of spec files will probably stick around, it just a question\nof which becomes the default.\n\n

              \nMost of the algorithm above looks similar in C to the original Python code. \nThere are two main differences. The first is the setting of \nreturn_val instead of directly returning from the C code with a \nreturn statement. return_val is an automatically \ndefined variable of type PyObject* that is returned from the C \ncode back to Python. You'll have to handle reference counting issues when \nsetting this variable. In this example, CXX classes and functions handle the \ndirty work. All CXX functions and classes live in the namespace \nPy::. The following code converts the integer m to a \nCXX Int() object and then to a PyObject* with an \nincremented reference count using Py::new_reference_to().\n\n 

                 \n    return_val = Py::new_reference_to(Py::Int(m));\n
              \n

              \nThe second big differences shows up in the retrieval of integer values from the \nPython list. The simple Python seq[i] call balloons into a C \nPython API call to grab the value out of the list and then a separate call to \npy_to_int() that converts the PyObject* to an integer. \npy_to_int() includes both a NULL cheack and a \nPyInt_Check() call as well as the conversion call. If either of \nthe checks fail, an exception is raised. The entire C++ code block is executed \nwith in a try/catch block that handles exceptions much like Python \ndoes. This removes the need for most error checking code.\n

              \nIt is worth note that CXX lists do have indexing operators that result \nin code that looks much like Python. However, the overhead in using them \nappears to be relatively high, so the standard Python API was used on the \nseq.ptr() which is the underlying PyObject* of the \nList object.\n

              \nThe #line directive that is the first line of the C code \nblock isn't necessary, but it's nice for debugging. If the compilation fails \nbecause of the syntax error in the code, the error will be reported as an error \nin the Python file \"binary_search.py\" with an offset from the given line number \n(29 here).\n

              \nSo what was all our effort worth in terms of efficiency? Well not a lot in \nthis case. The examples/binary_search.py file runs both Python and C versions \nof the functions As well as using the standard bisect module. If \nwe run it on a 1 million element list and run the search 3000 times (for 0-\n2999), here are the results we get:\n\n 

                 \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python binary_search.py\n    Binary search for 3000 items in 1000000 length list of integers:\n     speed in python: 0.159999966621\n     speed of bisect: 0.121000051498\n     speed up: 1.32\n     speed in c: 0.110000014305\n     speed up: 1.45\n     speed in c(no asserts): 0.0900000333786\n     speed up: 1.78\n
              \n

              \nSo, we get roughly a 50-75% improvement depending on whether we use the Python \nasserts in our C version. If we move down to searching a 10000 element list, \nthe advantage evaporates. Even smaller lists might result in the Python \nversion being faster. I'd like to say that moving to Numeric lists (and \ngetting rid of the GetItem() call) offers a substantial speed up, but my \npreliminary efforts didn't produce one. I think the log(N) algorithm is to \nblame. Because the algorithm is nice, there just isn't much time spent \ncomputing things, so moving to C isn't that big of a win. If there are ways to \nreduce conversion overhead of values, this may improve the C/Python speed \nup. Anyone have other explanations or faster code, please let me know.\n\n\n

              Dictionary Sort

              \n

              \nThe demo in examples/dict_sort.py is another example from the Python CookBook. \nThis \nsubmission, by Alex Martelli, demonstrates how to return the values from a \ndictionary sorted by their keys:\n\n 

                     \n    def sortedDictValues3(adict):\n        keys = adict.keys()\n        keys.sort()\n        return map(adict.get, keys)\n
              \n

              \nAlex provides 3 algorithms and this is the 3rd and fastest of the set. The C \nversion of this same algorithm follows:\n\n 

                     \n    def c_sort(adict):\n        assert(type(adict) == type({}))\n        code = \"\"\"     \n        #line 21 \"dict_sort.py\"  \n        Py::List keys = adict.keys();\n        Py::List items(keys.length()); keys.sort();     \n        PyObject* item = NULL; \n        for(int i = 0;  i < keys.length();i++)\n        {\n            item = PyList_GET_ITEM(keys.ptr(),i);\n            item = PyDict_GetItem(adict.ptr(),item);\n            Py_XINCREF(item);\n            PyList_SetItem(items.ptr(),i,item);              \n        }           \n        return_val = Py::new_reference_to(items);\n        \"\"\"   \n        return inline_tools.inline(code,['adict'],verbose=1)\n
              \n

              \nLike the original Python function, the C++ version can handle any Python \ndictionary regardless of the key/value pair types. It uses CXX objects for the \nmost part to declare python types in C++, but uses Python API calls to manipulate \ntheir contents. Again, this choice is made for speed. The C++ version, while\nmore complicated, is about a factor of 2 faster than Python.\n\n 

                     \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python dict_sort.py\n    Dict sort of 1000 items for 300 iterations:\n     speed in python: 0.319999933243\n    [0, 1, 2, 3, 4]\n     speed in c: 0.151000022888\n     speed up: 2.12\n    [0, 1, 2, 3, 4]\n
              \n

              \n\n

              Numeric -- cast/copy/transpose

              \n\nCastCopyTranspose is a function called quite heavily by Linear Algebra routines\nin the Numeric library. Its needed in part because of the row-major memory layout\nof multi-demensional Python (and C) arrays vs. the col-major order of the underlying\nFortran algorithms. For small matrices (say 100x100 or less), a significant\nportion of the common routines such as LU decompisition or singular value decompostion\nare spent in this setup routine. This shouldn't happen. Here is the Python\nversion of the function using standard Numeric operations.\n\n 
                     \n    def _castCopyAndTranspose(type, array):\n        if a.typecode() == type:\n            cast_array = copy.copy(Numeric.transpose(a))\n        else:\n            cast_array = copy.copy(Numeric.transpose(a).astype(type))\n        return cast_array\n
              \n\nAnd the following is a inline C version of the same function:\n\n 
              \n    from weave.blitz_tools import blitz_type_factories\n    from weave import scalar_spec\n    from weave import inline\n    def _cast_copy_transpose(type,a_2d):\n        assert(len(shape(a_2d)) == 2)\n        new_array = zeros(shape(a_2d),type)\n        numeric_type = scalar_spec.numeric_to_blitz_type_mapping[type]\n        code = \\\n        \"\"\"  \n        for(int i = 0;i < _Na_2d[0]; i++)  \n            for(int j = 0;  j < _Na_2d[1]; j++)\n                new_array(i,j) = (%s) a_2d(j,i);\n        \"\"\" % numeric_type\n        inline(code,['new_array','a_2d'],\n               type_factories = blitz_type_factories,compiler='gcc')\n        return new_array\n
              \n\nThis example uses blitz++ arrays instead of the standard representation of \nNumeric arrays so that indexing is simplier to write. This is accomplished by \npassing in the blitz++ \"type factories\" to override the standard Python to C++ \ntype conversions. Blitz++ arrays allow you to write clean, fast code, but they \nalso are sloooow to compile (20 seconds or more for this snippet). This is why \nthey aren't the default type used for Numeric arrays (and also because most \ncompilers can't compile blitz arrays...). inline() is also forced \nto use 'gcc' as the compiler because the default compiler on Windows (MSVC) \nwill not compile blitz code. 'gcc' I think will use the standard compiler \non Unix machine instead of explicitly forcing gcc (check this) \n\nComparisons of the Python vs inline C++ code show a factor of 3 speed up. Also \nshown are the results of an \"inplace\" transpose routine that can be used if the \noutput of the linear algebra routine can overwrite the original matrix (this is \noften appropriate). This provides another factor of 2 improvement.\n\n 
              \n     #C:\\home\\ej\\wrk\\scipy\\weave\\examples> python cast_copy_transpose.py\n    # Cast/Copy/Transposing (150,150)array 1 times\n    #  speed in python: 0.870999932289\n    #  speed in c: 0.25\n    #  speed up: 3.48\n    #  inplace transpose c: 0.129999995232\n    #  speed up: 6.70\n
              \n\n\n

              wxPython

              \n\ninline knows how to handle wxPython objects. Thats nice in and of\nitself, but it also demonstrates that the type conversion mechanism is reasonably \nflexible. Chances are, it won't take a ton of effort to support special types\nyou might have. The examples/wx_example.py borrows the scrolled window\nexample from the wxPython demo, accept that it mixes inline C code in the middle\nof the drawing function.\n\n 
              \n    def DoDrawing(self, dc):\n        \n        red = wxNamedColour(\"RED\");\n        blue = wxNamedColour(\"BLUE\");\n        grey_brush = wxLIGHT_GREY_BRUSH;\n        code = \\\n        \"\"\"\n        #line 108 \"wx_example.py\" \n        dc->BeginDrawing();\n        dc->SetPen(wxPen(*red,4,wxSOLID));\n        dc->DrawRectangle(5,5,50,50);\n        dc->SetBrush(*grey_brush);\n        dc->SetPen(wxPen(*blue,4,wxSOLID));\n        dc->DrawRectangle(15, 15, 50, 50);\n        \"\"\"\n        inline(code,['dc','red','blue','grey_brush'])\n        \n        dc.SetFont(wxFont(14, wxSWISS, wxNORMAL, wxNORMAL))\n        dc.SetTextForeground(wxColour(0xFF, 0x20, 0xFF))\n        te = dc.GetTextExtent(\"Hello World\")\n        dc.DrawText(\"Hello World\", 60, 65)\n\n        dc.SetPen(wxPen(wxNamedColour('VIOLET'), 4))\n        dc.DrawLine(5, 65+te[1], 60+te[0], 65+te[1])\n        ...\n
              \n\nHere, some of the Python calls to wx objects were just converted to C++ calls. There\nisn't any benefit, it just demonstrates the capabilities. You might want to use this\nif you have a computationally intensive loop in your drawing code that you want to \nspeed up.\n\nOn windows, you'll have to use the MSVC compiler if you use the standard wxPython\nDLLs distributed by Robin Dunn. Thats because MSVC and gcc, while binary\ncompatible in C, are not binary compatible for C++. In fact, its probably best, no \nmatter what platform you're on, to specify that inline use the same\ncompiler that was used to build wxPython to be on the safe side. There isn't currently\na way to learn this info from the library -- you just have to know. Also, at least\non the windows platform, you'll need to install the wxWindows libraries and link to \nthem. I think there is a way around this, but I haven't found it yet -- I get some\nlinking errors dealing with wxString. One final note. You'll probably have to\ntweak weave/wx_spec.py or weave/wx_info.py for your machine's configuration to\npoint at the correct directories etc. There. That should sufficiently scare people\ninto not even looking at this... :)\n\n              \n

              Keyword Options

              \n

              \nThe basic definition of the inline() function has a slew of \noptional variables. It also takes keyword arguments that are passed to \ndistutils as compiler options. The following is a formatted \ncut/paste of the argument section of inline's doc-string. It \nexplains all of the variables. Some examples using various options will \nfollow.\n\n 

                     \n    def inline(code,arg_names,local_dict = None, global_dict = None, \n               force = 0, \n               compiler='',\n               verbose = 0, \n               support_code = None,\n               customize=None, \n               type_factories = None, \n               auto_downcast=1,\n               **kw):\n
              \n\n \ninline has quite \na few options as listed below. Also, the keyword arguments for distutils \nextension modules are accepted to specify extra information needed for \ncompiling. \n
              \n

              inline Arguments:

              \n
              \n
              \n
              code
              \n \n
              \nstring. A string of valid C++ code. It should not \n specify a return statement. Instead it should assign results that need to be \n returned to Python in the return_val. \n
              \n\n
              arg_names
              \n \n
              \nlist of strings. A list of Python variable names \n that should be transferred from Python into the C/C++ code. \n
              \n\n
              local_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the local scope for the C/C++ \n code. If local_dict is not specified the local dictionary of the calling \n function is used. \n
              \n\n
              global_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the global scope for the C/C++ \n code. If global_dict is not specified the global dictionary of the calling \n function is used. \n
              \n\n
              force
              \n \n
              \noptional. 0 or 1. default 0. If 1, the C++ code is \n compiled every time inline is called. This is really only useful for \n debugging, and probably only useful if you're editing support_code a lot. \n
              \n\n
              compiler
              \n \n
              \noptional. string. The name of compiler to use when compiling. On windows, it \nunderstands 'msvc' and 'gcc' as well as all the compiler names understood by \ndistutils. On Unix, it'll only understand the values understoof by distutils. \n(I should add 'gcc' though to this).\n

              \nOn windows, the compiler defaults to the Microsoft C++ compiler. If this isn't \navailable, it looks for mingw32 (the gcc compiler).\n

              \nOn Unix, it'll probably use the same compiler that was used when compiling \nPython. Cygwin's behavior should be similar.

              \n
              \n\n
              verbose
              \n \n
              \noptional. 0,1, or 2. defualt 0. Speficies how much \n much information is printed during the compile phase of inlining code. 0 is \n silent (except on windows with msvc where it still prints some garbage). 1 \n informs you when compiling starts, finishes, and how long it took. 2 prints \n out the command lines for the compilation process and can be useful if you're \n having problems getting code to work. Its handy for finding the name of the \n .cpp file if you need to examine it. verbose has no affect if the \n compilation isn't necessary. \n
              \n\n
              support_code
              \n \n
              \noptional. string. A string of valid C++ code \n declaring extra code that might be needed by your compiled function. This \n could be declarations of functions, classes, or structures. \n
              \n\n
              customize
              \n \n
              \noptional. base_info.custom_info object. An \n alternative way to specifiy support_code, headers, etc. needed by the \n function see the weave.base_info module for more details. (not sure \n this'll be used much). \n \n
              \n
              type_factories
              \n \n
              \noptional. list of type specification factories. These guys are what convert \nPython data types to C/C++ data types. If you'd like to use a different set of \ntype conversions than the default, specify them here. Look in the type \nconversions section of the main documentation for examples.\n
              \n
              auto_downcast
              \n \n
              \noptional. 0 or 1. default 1. This only affects functions that have Numeric \narrays as input variables. Setting this to 1 will cause all floating point \nvalues to be cast as float instead of double if all the Numeric arrays are of \ntype float. If even one of the arrays has type double or double complex, all \nvariables maintain there standard types.\n
              \n
              \n
              \n\n

              Distutils keywords:

              \n
              \ninline() also accepts a number of distutils keywords \nfor controlling how the code is compiled. The following descriptions have been \ncopied from Greg Ward's distutils.extension.Extension class doc-\nstrings for convenience:\n\n
              \n
              sources
              \n \n
              \n[string] list of source filenames, relative to the \n distribution root (where the setup script lives), in Unix form \n (slash-separated) for portability. Source files may be C, C++, SWIG (.i), \n platform-specific resource files, or whatever else is recognized by the \n \"build_ext\" command as source for a Python extension. Note: The module_path \n file is always appended to the front of this list \n
              \n\n
              include_dirs
              \n \n
              \n[string] list of directories to search for C/C++ \n header files (in Unix form for portability) \n
              \n\n
              define_macros
              \n \n
              \n[(name : string, value : string|None)] list of \n macros to define; each macro is defined using a 2-tuple, where 'value' is \n either the string to define it to or None to define it without a particular \n value (equivalent of \"#define FOO\" in source or -DFOO on Unix C compiler \n command line) \n
              \n
              undef_macros
              \n \n
              \n[string] list of macros to undefine explicitly \n
              \n
              library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at link time \n
              \n
              libraries
              \n
              \n[string] list of library names (not filenames or paths) to link against \n
              \n
              runtime_library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at run time (for \nshared extensions, this is when the extension is loaded) \n
              \n\n
              extra_objects
              \n \n
              \n[string] list of extra files to link with (eg. \n object files not implied by 'sources', static library that must be \n explicitly specified, binary resource files, etc.) \n
              \n\n
              extra_compile_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when compiling the source files in 'sources'. For \n platforms and compilers where \"command line\" makes sense, this is typically \n a list of command-line arguments, but for other platforms it could be \n anything. \n
              \n
              extra_link_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when linking object files together to create the \n extension (or to create a new static Python interpreter). Similar \n interpretation as for 'extra_compile_args'. \n
              \n
              export_symbols
              \n \n
              \n[string] list of symbols to be exported from a shared extension. Not used on \nall platforms, and not generally necessary for Python extensions, which \ntypically export exactly one symbol: \"init\" + extension_name. \n
              \n
              \n
              \n\n\n

              Keyword Option Examples

              \nWe'll walk through several examples here to demonstrate the behavior of \ninline and also how the various arguments are used.\n\nIn the simplest (most) cases, code and arg_names\nare the only arguments that need to be specified. Here's a simple example\nrun on Windows machine that has Microsoft VC++ installed.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'string'\n    >>> code = \"\"\"\n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));\n    ...        \"\"\"\n    >>> inline(code,['a'])\n     sc_86e98826b65b047ffd2cd5f479c627f12.cpp\n    Creating\n       library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f12.lib\n    and object C:\\DOCUME~ 1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ff\n    d2cd5f479c627f12.exp\n    6\n    >>> inline(code,['a'])\n    6\n
              \n \nWhen inline is first run, you'll notice that pause and some \ntrash printed to the screen. The \"trash\" is acutually part of the compilers\noutput that distutils does not supress. The name of the extension file, \nsc_bighonkingnumber.cpp, is generated from the md5 check sum\nof the C/C++ code fragment. On Unix or windows machines with only\ngcc installed, the trash will not appear. On the second call, the code \nfragment is not compiled since it already exists, and only the answer is \nreturned. Now kill the interpreter and restart, and run the same code with\na different string.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'a longer string' \n    >>> code = \"\"\" \n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));  \n    ...        \"\"\"\n    >>> inline(code,['a'])\n    15\n
              \n

              \nNotice this time, inline() did not recompile the code because it\nfound the compiled function in the persistent catalog of functions. There is\na short pause as it looks up and loads the function, but it is much shorter \nthan compiling would require.\n

              \nYou can specify the local and global dictionaries if you'd like (much like \nexec or eval() in Python), but if they aren't \nspecified, the \"expected\" ones are used -- i.e. the ones from the function that \ncalled inline() . This is accomplished through a little call \nframe trickery. Here is an example where the local_dict is specified using\nthe same code example from above:\n\n 

              \n    >>> a = 'a longer string'\n    >>> b = 'an even  longer string' \n    >>> my_dict = {'a':b}\n    >>> inline(code,['a'])\n    15\n    >>> inline(code,['a'],my_dict)\n    21\n
              \n \n

              \nEverytime, the code is changed, inline does a \nrecompile. However, changing any of the other options in inline does not\nforce a recompile. The force option was added so that one\ncould force a recompile when tinkering with other variables. In practice,\nit is just as easy to change the code by a single character\n(like adding a space some place) to force the recompile. Note: It also \nmight be nice to add some methods for purging the cache and on disk \ncatalogs.\n

              \nI use verbose sometimes for debugging. When set to 2, it'll \noutput all the information (including the name of the .cpp file) that you'd\nexpect from running a make file. This is nice if you need to examine the\ngenerated code to see where things are going haywire. Note that error\nmessages from failed compiles are printed to the screen even if verbose\n is set to 0.\n

              \nThe following example demonstrates using gcc instead of the standard msvc \ncompiler on windows using same code fragment as above. Because the example has \nalready been compiled, the force=1 flag is needed to make \ninline() ignore the previously compiled version and recompile \nusing gcc. The verbose flag is added to show what is printed out:\n\n 

              \n    >>>inline(code,['a'],compiler='gcc',verbose=2,force=1)\n    running build_ext    \n    building 'sc_86e98826b65b047ffd2cd5f479c627f13' extension \n    c:\\gcc-2.95.2\\bin\\g++.exe -mno-cygwin -mdll -O2 -w -Wstrict-prototypes -IC:\n    \\home\\ej\\wrk\\scipy\\weave -IC:\\Python21\\Include -c C:\\DOCUME~1\\eric\\LOCAL\n    S~1\\Temp\\python21_compiled\\sc_86e98826b65b047ffd2cd5f479c627f13.cpp -o C:\\D\n    OCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b04\n    7ffd2cd5f479c627f13.o    \n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxextensions.c (C:\\DOCUME~1\\eri\n    c\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxextensions.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxsupport.cxx (C:\\DOCUME~1\\eric\n    \\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxsupport.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\IndirectPythonInterface.cxx (C:\\\n    DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\indirectpythonin\n    terface.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxx_extensions.cxx (C:\\DOCUME~1\\\n    eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxx_extensions.o up-to-da\n    te)\n    writing C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86\n    e98826b65b047ffd2cd5f479c627f13.def\n    c:\\gcc-2.95.2\\bin\\dllwrap.exe --driver-name g++ -mno-cygwin -mdll -static -\n    -output-lib C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\l\n    ibsc_86e98826b65b047ffd2cd5f479c627f13.a --def C:\\DOCUME~1\\eric\\LOCALS~1\\Te\n    mp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f13.def \n    -s C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e9882\n    6b65b047ffd2cd5f479c627f13.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compil\n    ed\\temp\\Release\\cxxextensions.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\cxxsupport.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\indirectpythoninterface.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\n    \\python21_compiled\\temp\\Release\\cxx_extensions.o -LC:\\Python21\\libs -lpytho\n    n21 -o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\sc_86e98826b65b047f\n    fd2cd5f479c627f13.pyd\n    15\n
              \n\nThat's quite a bit of output. verbose=1 just prints the compile\ntime.\n\n 
              \n    >>>inline(code,['a'],compiler='gcc',verbose=1,force=1)\n    Compiling code...\n    finished compiling (sec):  6.00800001621\n    15\n
              \n\n

              \n Note: I've only used the compiler option for switching between 'msvc'\nand 'gcc' on windows. It may have use on Unix also, but I don't know yet.\n\n\n

              \nThe support_code argument is likely to be used a lot. It allows \nyou to specify extra code fragments such as function, structure or class \ndefinitions that you want to use in the code string. Note that \nchanges to support_code do not force a recompile. The \ncatalog only relies on code (for performance reasons) to determine \nwhether recompiling is necessary. So, if you make a change to support_code, \nyou'll need to alter code in some way or use the \nforce argument to get the code to recompile. I usually just add \nsome inocuous whitespace to the end of one of the lines in code \nsomewhere. Here's an example of defining a separate method for calculating\nthe string length:\n\n 

              \n    >>> from weave import inline\n    >>> a = 'a longer string'\n    >>> support_code = \"\"\"\n    ...                PyObject* length(Py::String a)\n    ...                {\n    ...                    int l = a.length();  \n    ...                    return Py::new_reference_to(Py::Int(l)); \n    ...                }\n    ...                \"\"\"        \n    >>> inline(\"return_val = length(a);\",['a'],\n    ...        support_code = support_code)\n    15\n
              \n

              \ncustomize is a left over from a previous way of specifying \ncompiler options. It is a custom_info object that can specify \nquite a bit of information about how a file is compiled. These \ninfo objects are the standard way of defining compile information \nfor type conversion classes. However, I don't think they are as handy here, \nespecially since we've exposed all the keyword arguments that distutils can \nhandle. Between these keywords, and the support_code option, I \nthink customize may be obsolete. We'll see if anyone cares to use \nit. If not, it'll get axed in the next version.\n

              \nThe type_factories variable is important to people who want to\ncustomize the way arguments are converted from Python to C. We'll talk about\nthis in the next chapter **xx** of this document when we discuss type\nconversions.\n

              \nauto_downcast handles one of the big type conversion issues that\nis common when using Numeric arrays in conjunction with Python scalar values.\nIf you have an array of single precision values and multiply that array by a \nPython scalar, the result is upcast to a double precision array because the\nscalar value is double precision. This is not usually the desired behavior\nbecause it can double your memory usage. auto_downcast goes\nsome distance towards changing the casting precedence of arrays and scalars.\nIf your only using single precision arrays, it will automatically downcast all\nscalar values from double to single precision when they are passed into the\nC++ code. This is the default behavior. If you want all values to keep there\ndefault type, set auto_downcast to 0.\n

              \n\n\n\n

              Returning Values

              \n\nPython variables in the local and global scope transfer seemlessly from Python \ninto the C++ snippets. And, if inline were to completely live up\nto its name, any modifications to variables in the C++ code would be reflected\nin the Python variables when control was passed back to Python. For example,\nthe desired behavior would be something like:\n\n 
              \n    # THIS DOES NOT WORK\n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    2\n
              \n\nInstead you get:\n\n 
              \n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    1\n
              \n \nVariables are passed into C++ as if you are calling a Python function. Python's \ncalling convention is sometimes called \"pass by assignment\". This means its as \nif a c_a = a assignment is made right before inline \ncall is made and the c_a variable is used within the C++ code. \nThus, any changes made to c_a are not reflected in Python's \na variable. Things do get a little more confusing, however, when \nlooking at variables with mutable types. Changes made in C++ to the contents \nof mutable types are reflected in the Python variables.\n\n 
              \n    >>> a= [1,2]\n    >>> weave.inline(\"PyList_SetItem(a.ptr(),0,PyInt_FromLong(3));\",['a'])\n    >>> print a\n    [3, 2]\n
              \n\nSo modifications to the contents of mutable types in C++ are seen when control\nis returned to Python. Modifications to immutable types such as tuples,\nstrings, and numbers do not alter the Python variables.\n\nIf you need to make changes to an immutable variable, you'll need to assign\nthe new value to the \"magic\" variable return_val in C++. This\nvalue is returned by the inline() function:\n\n 
              \n    >>> a = 1\n    >>> a = weave.inline(\"return_val = Py::new_reference_to(Py::Int(a+1));\",['a'])  \n    >>> a\n    2\n
              \n\nThe return_val variable can also be used to return newly created \nvalues. This is possible by returning a tuple. The following trivial example \nillustrates how this can be done:\n\n 
                     \n    # python version\n    def multi_return():\n        return 1, '2nd'\n    \n    # C version.\n    def c_multi_return():    \n        code =  \"\"\"\n     \t        Py::Tuple results(2);\n     \t        results[0] = Py::Int(1);\n     \t        results[1] = Py::String(\"2nd\");\n     \t        return_val = Py::new_reference_to(results); \t        \n                \"\"\"\n        return inline_tools.inline(code)\n
              \n

              \nThe example is available in examples/tuple_return.py. It also\nhas the dubious honor of demonstrating how much inline() can \nslow things down. The C version here is about 10 times slower than the Python\nversion. Of course, something so trivial has no reason to be written in\nC anyway.\n\n\n

              The issue with locals()

              \n

              \ninline passes the locals() and globals() \ndictionaries from Python into the C++ function from the calling function. It \nextracts the variables that are used in the C++ code from these dictionaries, \nconverts then to C++ variables, and then calculates using them. It seems like \nit would be trivial, then, after the calculations were finished to then insert \nthe new values back into the locals() and globals() \ndictionaries so that the modified values were reflected in Python. \nUnfortunately, as pointed out by the Python manual, the locals() dictionary is \nnot writable. \n

              \n\nI suspect locals() is not writable because there are some \noptimizations done to speed lookups of the local namespace. I'm guessing local \nlookups don't always look at a dictionary to find values. Can someone \"in the \nknow\" confirm or correct this? Another thing I'd like to know is whether there \nis a way to write to the local namespace of another stack frame from C/C++. If \nso, it would be possible to have some clean up code in compiled functions that \nwrote final values of variables in C++ back to the correct Python stack frame. \nI think this goes a long way toward making inline truely live up \nto its name. I don't think we'll get to the point of creating variables in \nPython for variables created in C -- although I suppose with a C/C++ parser you \ncould do that also.\n\n

              \n\n\n

              A quick look at the code

              \n\nweave generates a C++ file holding an extension function for \neach inline code snippet. These file names are generated using \nfrom the md5 signature of the code snippet and saved to a location specified by \nthe PYTHONCOMPILED environment variable (discussed later). The cpp files are \ngenerally about 200-400 lines long and include quite a few functions to support \ntype conversions, etc. However, the actual compiled function is pretty simple. \nBelow is the familiar printf example:\n\n 
              \n    >>> import weave    \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n\nAnd here is the extension function generated by inline:\n\n 
              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        // The Py_None needs an incref before returning\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n        \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try                              \n        {                                \n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n            /* Here is the inline code */            \n            printf(\"%d\\n\",a);\n            /* I would like to fill in changed locals and globals here... */\n        }                                       \n        catch( Py::Exception& e)           \n        {                                \n            return_val =  Py::Null();    \n            exception_occured = 1;       \n        }                                 \n        if(!return_val && !exception_occured)\n        {\n                                      \n            Py_INCREF(Py_None);              \n            return_val = Py_None;            \n        }\n        /* clean up code */\n        \n        /* return */                              \n        return return_val;           \n    }                                \n
              \n\nEvery inline function takes exactly two arguments -- the local and global\ndictionaries for the current scope. All variable values are looked up out\nof these dictionaries. The lookups, along with all inline code \nexecution, are done within a C++ try block. If the variables\naren't found, or there is an error converting a Python variable to the \nappropriate type in C++, an exception is raised. The C++ exception\nis automatically converted to a Python exception by CXX and returned to Python.\n\nThe py_to_int() function illustrates how the conversions and\nexception handling works. py_to_int first checks that the given PyObject*\npointer is not NULL and is a Python integer. If all is well, it calls the\nPython API to convert the value to an int. Otherwise, it calls\nhandle_bad_type() which gathers information about what went wrong\nand then raises a CXX TypeError which returns to Python as a TypeError.\n\n 
              \n    int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\n 
              \n    void handle_bad_type(PyObject* py_obj, char* good_type, char*  var_name)\n    {\n        char msg[500];\n        sprintf(msg,\"received '%s' type instead of '%s' for variable '%s'\",\n                find_type(py_obj),good_type,var_name);\n        throw Py::TypeError(msg);\n    }\n    \n    char* find_type(PyObject* py_obj)\n    {\n        if(py_obj == NULL) return \"C NULL value\";\n        if(PyCallable_Check(py_obj)) return \"callable\";\n        if(PyString_Check(py_obj)) return \"string\";\n        if(PyInt_Check(py_obj)) return \"int\";\n        if(PyFloat_Check(py_obj)) return \"float\";\n        if(PyDict_Check(py_obj)) return \"dict\";\n        if(PyList_Check(py_obj)) return \"list\";\n        if(PyTuple_Check(py_obj)) return \"tuple\";\n        if(PyFile_Check(py_obj)) return \"file\";\n        if(PyModule_Check(py_obj)) return \"module\";\n        \n        //should probably do more interagation (and thinking) on these.\n        if(PyCallable_Check(py_obj) && PyInstance_Check(py_obj)) return \"callable\";\n        if(PyInstance_Check(py_obj)) return \"instance\"; \n        if(PyCallable_Check(py_obj)) return \"callable\";\n        return \"unkown type\";\n    }\n
              \n\nSince the inline is also executed within the try/catch\nblock, you can use CXX exceptions within your code. It is usually a bad idea\nto directly return from your code, even if an error occurs. This\nskips the clean up section of the extension function. In this simple example,\nthere isn't any clean up code, but in more complicated examples, there may\nbe some reference counting that needs to be taken care of here on converted\nvariables. To avoid this, either uses exceptions or set \nreturn_val to NULL and use if/then's to skip code\nafter errors.\n\n\n

              Technical Details

              \n

              \nThere are several main steps to using C/C++ code withing Python:\n

                \n
              1. Type conversion \n
              2. Generating C/C++ code \n
              3. Compile the code to an extension module \n
              4. Catalog (and cache) the function for future use
                5. \n
              \n

              \nItems 1 and 2 above are related, but most easily discussed separately. Type \nconversions are customizable by the user if needed. Understanding them is \npretty important for anything beyond trivial uses of inline. \nGenerating the C/C++ code is handled by ext_function and \next_module classes and . For the most part, compiling the code is \nhandled by distutils. Some customizations were needed, but they were \nrelatively minor and do not require changes to distutils itself. Cataloging is \npretty simple in concept, but surprisingly required the most code to implement \n(and still likely needs some work). So, this section covers items 1 and 4 from \nthe list. Item 2 is covered later in the chapter covering the \next_tools module, and distutils is covered by a completely \nseparate document xxx.\n\n

              Passing Variables in/out of the C/C++ code

              \n\nNote: Passing variables into the C code is pretty straight forward, but there \nare subtlties to how variable modifications in C are returned to Python. see Returning Values for a more thorough discussion of \nthis issue.\n \n \n\n

              Type Conversions

              \n\n\nNote: Maybe xxx_converter instead of \nxxx_specification is a more descriptive name. Might change in \nfuture version?\n\n\n

              \nBy default, inline() makes the following type conversions between\nPython and C++ types.\n

              \n\n

              \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
              \n

              Default Data Type Conversions

              \n

              Python

              		\n

              C++

                 int   int
                 float   double
                 complex   std::complex
                 string   Py::String
                 list   Py::List
                 dict   Py::Dict
                 tuple   Py::Tuple
                 file   FILE*
                 callable   PyObject*
                 instance   PyObject*
                 Numeric.array   PyArrayObject*
                 wxXXX   wxXXX*
              \n
              \n

              \nThe Py:: namespace is defined by the \nCXX library which has C++ class\nequivalents for many Python types. std:: is the namespace of the\nstandard library in C++.\n

              \n\nNote: \n

                \n
              • I haven't figured out how to handle long int yet (I think they are currenlty converted \n to int - - check this). \n \n
              • \nHopefully VTK will be added to the list soon
                • \n
              \n\n

              \n\nPython to C++ conversions fill in code in several locations in the generated\ninline extension function. Below is the basic template for the\nfunction. This is actually the exact code that is generated by calling\nweave.inline(\"\").\n\n 

              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n    \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try\n        {\n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            /* argument conversion code */\n            /* inline code */\n            /*I would like to fill in changed locals and globals here...*/\n    \n        }\n        catch( Py::Exception& e)\n        {\n            return_val =  Py::Null();\n            exception_occured = 1;\n        }\n        /* cleanup code */\n        if(!return_val && !exception_occured)\n        {\n    \n            Py_INCREF(Py_None);\n            return_val = Py_None;\n        }\n    \n        return return_val;\n    }\n
              \n\nThe /* inline code */ section is filled with the code passed to\nthe inline() function call. The \n/*argument convserion code*/ and /* cleanup code */\nsections are filled with code that handles conversion from Python to C++\ntypes and code that deallocates memory or manipulates reference counts before\nthe function returns. The following sections demostrate how these two areas\nare filled in by the default conversion methods.\n\n \nNote: I'm not sure I have reference counting correct on a few of these. The \nonly thing I increase/decrease the ref count on is Numeric arrays. If you\nsee an issue, please let me know.\n\n\n\n

              Numeric Argument Conversion

              \n\nInteger, floating point, and complex arguments are handled in a very similar\nfashion. Consider the following inline function that has a single integer \nvariable passed in:\n\n 
              \n    >>> a = 1\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_int() has the following\nform:\n\n 
              \n    static int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\nSimilarly, the float and complex conversion routines look like:\n\n 
                  \n    static double py_to_float(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyFloat_Check(py_obj))\n            handle_bad_type(py_obj,\"float\", name);\n        return PyFloat_AsDouble(py_obj);\n    }\n    \n    static std::complex py_to_complex(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyComplex_Check(py_obj))\n            handle_bad_type(py_obj,\"complex\", name);\n        return std::complex(PyComplex_RealAsDouble(py_obj),\n                                    PyComplex_ImagAsDouble(py_obj));    \n    }\n
              \n\nNumeric conversions do not require any clean up code.\n\n\n

              String, List, Tuple, and Dictionary Conversion

              \n\nStrings, Lists, Tuples and Dictionary conversions are all converted to \nCXX types by default.\n\nFor the following code, \n\n 
              \n    >>> a = [1]\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    Py::List a = py_to_list (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_list() and its\nfriends has the following form:\n\n 
                  \n    static Py::List py_to_list(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyList_Check(py_obj))\n            handle_bad_type(py_obj,\"list\", name);\n        return Py::List(py_obj);\n    }\n    \n    static Py::String py_to_string(PyObject* py_obj,char* name)\n    {\n        if (!PyString_Check(py_obj))\n            handle_bad_type(py_obj,\"string\", name);\n        return Py::String(py_obj);\n    }\n\n    static Py::Dict py_to_dict(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyDict_Check(py_obj))\n            handle_bad_type(py_obj,\"dict\", name);\n        return Py::Dict(py_obj);\n    }\n    \n    static Py::Tuple py_to_tuple(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyTuple_Check(py_obj))\n            handle_bad_type(py_obj,\"tuple\", name);\n        return Py::Tuple(py_obj);\n    }\n
              \n\nCXX handles reference counts on for strings, lists, tuples, and dictionaries,\nso clean up code isn't necessary.\n\n\n

              File Conversion

              \n\nFor the following code, \n\n 
              \n    >>> a = open(\"bob\",'w')  \n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code is:\n\n 
              \n    /* argument conversion code */\n    PyObject* py_a = get_variable(\"a\",raw_locals,raw_globals);\n    FILE* a = py_to_file(py_a,\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_file() converts\nPyObject* to a FILE* and increments the reference count of the PyObject*:\n\n 
              \n    FILE* py_to_file(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"file\", name);\n    \n        Py_INCREF(py_obj);\n        return PyFile_AsFile(py_obj);\n    }\n
              \n\nBecause the PyObject* was incremented, the clean up code needs to decrement\nthe counter\n\n 
              \n    /* cleanup code */\n    Py_XDECREF(py_a);\n
              \n\nIts important to understand that file conversion only works on actual files --\ni.e. ones created using the open() command in Python. It does\nnot support converting arbitrary objects that support the file interface into\nC FILE* pointers. This can affect many things. For example, in\ninitial printf() examples, one might be tempted to solve the \nproblem of C and Python IDE's (PythonWin, PyCrust, etc.) writing to different\nstdout and stderr by using fprintf() and passing in \nsys.stdout and sys.stderr. For example, instead of\n\n 
              \n    >>> weave.inline('printf(\"hello\\\\n\");')\n
              \n \nYou might try:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n
              \n\nThis will work as expected from a standard python interpreter, but in PythonWin,\nthe following occurs:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n    Traceback (most recent call last):\n        File \"\", line 1, in ?\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 315, in inline\n            auto_downcast = auto_downcast,\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 386, in compile_function\n            type_factories = type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 197, in __init__\n            auto_downcast, type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 390, in assign_variable_types\n            raise TypeError, format_error_msg(errors)\n        TypeError: {'buf': \"Unable to convert variable 'buf' to a C++ type.\"}\n
              \n\nThe traceback tells us that inline() was unable to convert 'buf' to a\nC++ type (If instance conversion was implemented, the error would have occurred at \nruntime instead). Why is this? Let's look at what the buf object \nreally is:\n\n 
              \n    >>> buf\n    pywin.framework.interact.InteractiveView instance at 00EAD014\n
              \n\nPythonWin has reassigned sys.stdout to a special object that \nimplements the Python file interface. This works great in Python, but since \nthe special object doesn't have a FILE* pointer underlying it, fprintf doesn't \nknow what to do with it (well this will be the problem when instance conversion \nis implemented...).\n\n\n

              Callable, Instance, and Module Conversion

              \n\nNote: Need to look into how ref counts should be handled. Also,\nInstance and Module conversion are not currently implemented.\n\n\n 
              \n    >>> def a(): \n        pass\n    >>> inline(\"\",['a'])\n
              \n\nCallable and instance variables are converted to PyObject*. Nothing is done\nto there reference counts.\n\n 
              \n    /* argument conversion code */\n    PyObject* a = py_to_callable(get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. The py_to_callable() and\npy_to_instance() don't currently increment the ref count.\n\n 
                  \n    PyObject* py_to_callable(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyCallable_Check(py_obj))\n            handle_bad_type(py_obj,\"callable\", name);    \n        return py_obj;\n    }\n\n    PyObject* py_to_instance(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"instance\", name);    \n        return py_obj;\n    }\n
              \n \nThere is no cleanup code for callables, modules, or instances.\n\n\n

              Customizing Conversions

              \n

              \nConverting from Python to C++ types is handled by xxx_specification classes. A \ntype specification class actually serve in two related but different \nroles. The first is in determining whether a Python variable that needs to be \nconverted should be represented by the given class. The second is as a code \ngenerator that generate C++ code needed to convert from Python to C++ types for \na specific variable.\n

              \nWhen \n\n 

              \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\",a);',['a'])\n
              \n \nis called for the first time, the code snippet has to be compiled. In this \nprocess, the variable 'a' is tested against a list of type specifications (the \ndefault list is stored in weave/ext_tools.py). The first \nspecification in the list is used to represent the variable. \n\n

              \nExamples of xxx_specification are scattered throughout numerous \n\"xxx_spec.py\" files in the weave package. Closely related to \nthe xxx_specification classes are yyy_info classes. \nThese classes contain compiler, header, and support code information necessary \nfor including a certain set of capabilities (such as blitz++ or CXX support)\nin a compiled module. xxx_specification classes have one or more\nyyy_info classes associated with them.\n\nIf you'd like to define your own set of type specifications, the current best route\nis to examine some of the existing spec and info files. Maybe looking over\nsequence_spec.py and cxx_info.py are a good place to start. After defining \nspecification classes, you'll need to pass them into inline using the \ntype_factories argument. \n\nA lot of times you may just want to change how a specific variable type is \nrepresented. Say you'd rather have Python strings converted to \nstd::string or maybe char* instead of using the CXX \nstring object, but would like all other type conversions to have default \nbehavior. This requires that a new specification class that handles strings\nis written and then prepended to a list of the default type specifications. Since\nit is closer to the front of the list, it effectively overrides the default\nstring specification.\n\nThe following code demonstrates how this is done:\n\n...\n\n\n

              The Catalog

              \n

              \ncatalog.py has a class called catalog that helps keep \ntrack of previously compiled functions. This prevents inline() \nand related functions from having to compile functions everytime they are \ncalled. Instead, catalog will check an in memory cache to see if the function \nhas already been loaded into python. If it hasn't, then it starts searching \nthrough persisent catalogs on disk to see if it finds an entry for the given \nfunction. By saving information about compiled functions to disk, it isn't\nnecessary to re-compile functions everytime you stop and restart the interpreter.\nFunctions are compiled once and stored for future use.\n\n

              \nWhen inline(cpp_code) is called the following things happen:\n

                \n
              1. \n A fast local cache of functions is checked for the last function called for \n cpp_code. If an entry for cpp_code doesn't exist in the \n cache or the cached function call fails (perhaps because the function doesn't \n have compatible types) then the next step is to check the catalog. \n
              2. \n The catalog class also keeps an in-memory cache with a list of all the \n functions compiled for cpp_code. If cpp_code has\n ever been called, then this cache will be present (loaded from disk). If\n the cache isn't present, then it is loaded from disk.\n

                \n If the cache is present, each function in the cache is \n called until one is found that was compiled for the correct argument types. If \n none of the functions work, a new function is compiled with the given argument \n types. This function is written to the on-disk catalog as well as into the \n in-memory cache.

                \n
              3. \n When a lookup for cpp_code fails, the catalog looks through \n the on-disk function catalogs for the entries. The PYTHONCOMPILED variable \n determines where to search for these catalogs and in what order. If \n PYTHONCOMPILED is not present several platform dependent locations are \n searched. All functions found for cpp_code in the path are \n loaded into the in-memory cache with functions found earlier in the search \n path closer to the front of the call list.\n

                \n If the function isn't found in the on-disk catalog, \n then the function is compiled, written to the first writable directory in the \n PYTHONCOMPILED path, and also loaded into the in-memory cache.

                \n
                4. \n
              \n\n\n

              Function Storage: How functions are stored in caches and on disk

              \n

              \nFunction caches are stored as dictionaries where the key is the entire C++\ncode string and the value is either a single function (as in the \"level 1\"\ncache) or a list of functions (as in the main catalog cache). On disk\ncatalogs are stored in the same manor using standard Python shelves.\n

              \nEarly on, there was a question as to whether md5 check sums of the C++\ncode strings should be used instead of the actual code strings. I think this\nis the route inline Perl took. Some (admittedly quick) tests of the md5 vs.\nthe entire string showed that using the entire string was at least a\nfactor of 3 or 4 faster for Python. I think this is because it is more\ntime consuming to compute the md5 value than it is to do look-ups of long\nstrings in the dictionary. Look at the examples/md5_speed.py file for the\ntest run. \n\n\n

              Catalog search paths and the PYTHONCOMPILED variable

              \n

              \nThe default location for catalog files on Unix is is ~/.pythonXX_compiled where \nXX is version of Python being used. If this directory doesn't exist, it is \ncreated the first time a catalog is used. The directory must be writable. If, \nfor any reason it isn't, then the catalog attempts to create a directory based \non your user id in the /tmp directory. The directory permissions are set so \nthat only you have access to the directory. If this fails, I think you're out of \nluck. I don't think either of these should ever fail though. On Windows, a \ndirectory called pythonXX_compiled is created in the user's temporary \ndirectory. \n

              \nThe actual catalog file that lives in this directory is a Python shelve with\na platform specific name such as \"nt21compiled_catalog\" so that multiple OSes\ncan share the same file systems without trampling on each other. Along with\nthe catalog file, the .cpp and .so or .pyd files created by inline will live\nin this directory. The catalog file simply contains keys which are the C++\ncode strings with values that are lists of functions. The function lists point\nat functions within these compiled modules. Each function in the lists \nexecutes the same C++ code string, but compiled for different input variables.\n

              \nYou can use the PYTHONCOMPILED environment variable to specify alternative\nlocations for compiled functions. On Unix this is a colon (':') separated\nlist of directories. On windows, it is a (';') separated list of directories.\nThese directories will be searched prior to the default directory for a\ncompiled function catalog. Also, the first writable directory in the list\nis where all new compiled function catalogs, .cpp and .so or .pyd files are\nwritten. Relative directory paths ('.' and '..') should work fine in the\nPYTHONCOMPILED variable as should environement variables.\n

              \nThere is a \"special\" path variable called MODULE that can be placed in the \nPYTHONCOMPILED variable. It specifies that the compiled catalog should\nreside in the same directory as the module that called it. This is useful\nif an admin wants to build a lot of compiled functions during the build\nof a package and then install them in site-packages along with the package.\nUser's who specify MODULE in their PYTHONCOMPILED variable will have access\nto these compiled functions. Note, however, that if they call the function\nwith a set of argument types that it hasn't previously been built for, the\nnew function will be stored in their default directory (or some other writable\ndirectory in the PYTHONCOMPILED path) because the user will not have write\naccess to the site-packages directory.\n

              \nAn example of using the PYTHONCOMPILED path on bash follows:\n\n 

              \n    PYTHONCOMPILED=MODULE:/some/path;export PYTHONCOMPILED;\n
              \n\nIf you are using python21 on linux, and the module bob.py in site-packages\nhas a compiled function in it, then the catalog search order when calling that\nfunction for the first time in a python session would be:\n\n 
              \n    /usr/lib/python21/site-packages/linuxpython_compiled\n    /some/path/linuxpython_compiled\n    ~/.python21_compiled/linuxpython_compiled\n
              \n\nThe default location is always included in the search path.\n

              \n \nNote: hmmm. see a possible problem here. I should probably make a sub-\ndirectory such as /usr/lib/python21/site-\npackages/python21_compiled/linuxpython_compiled so that library files compiled \nwith python21 are tried to link with python22 files in some strange scenarios. \nNeed to check this.\n\n\n

              \nThe in-module cache (in weave.inline_tools reduces the overhead \nof calling inline functions by about a factor of 2. It can be reduced a little \nmore for type loop calls where the same function is called over and over again \nif the cache was a single value instead of a dictionary, but the benefit is \nvery small (less than 5%) and the utility is quite a bit less. So, we'll stick \nwith a dictionary as the cache.\n

              \n\n\n

              Blitz

              \n Note: most of this section is lifted from old documentation. It should be\npretty accurate, but there may be a few discrepancies.\n

              \nweave.blitz() compiles Numeric Python expressions for fast \nexecution. For most applications, compiled expressions should provide a \nfactor of 2-10 speed-up over Numeric arrays. Using compiled \nexpressions is meant to be as unobtrusive as possible and works much like \npythons exec statement. As an example, the following code fragment takes a 5 \npoint average of the 512x512 2d image, b, and stores it in array, a:\n\n 

              \n    from scipy import *  # or from Numeric import *\n    a = ones((512,512), Float64) \n    b = ones((512,512), Float64) \n    # ...do some stuff to fill in b...\n    # now average\n    a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] \\\n                   + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n
              \n \nTo compile the expression, convert the expression to a string by putting\nquotes around it and then use weave.blitz:\n\n 
              \n    import weave\n    expr = \"a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n                          \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n    weave.blitz(expr)\n
              \n\nThe first time weave.blitz is run for a given expression and \nset of arguements, C++ code that accomplishes the exact same task as the Python \nexpression is generated and compiled to an extension module. This can take up \nto a couple of minutes depending on the complexity of the function. Subsequent \ncalls to the function are very fast. Futher, the generated module is saved \nbetween program executions so that the compilation is only done once for a \ngiven expression and associated set of array types. If the given expression\nis executed with a new set of array types, the code most be compiled again. This\ndoes not overwrite the previously compiled function -- both of them are saved and\navailable for exectution. \n

              \nThe following table compares the run times for standard Numeric code and \ncompiled code for the 5 point averaging.\n

              \n

              \n\n\n\n\n\n
              Method Run Time (seconds)
              Standard Numeric 0.46349
              blitz (1st time compiling) 78.95526
              blitz (subsequent calls) 0.05843 (factor of 8 speedup)
              \n
              \n

              \nThese numbers are for a 512x512 double precision image run on a 400 MHz Celeron \nprocessor under RedHat Linux 6.2.\n

              \nBecause of the slow compile times, its probably most effective to develop \nalgorithms as you usually do using the capabilities of scipy or the Numeric \nmodule. Once the algorithm is perfected, put quotes around it and execute it \nusing weave.blitz. This provides the standard rapid \nprototyping strengths of Python and results in algorithms that run close to \nthat of hand coded C or Fortran.\n\n\n

              Requirements

              \n\nCurrently, the weave.blitz has only been tested under Linux \nwith gcc-2.95-3 and on Windows with Mingw32 (2.95.2). Its compiler \nrequirements are pretty heavy duty (see the \nblitz++ home page), so it won't \nwork with just any compiler. Particularly MSVC++ isn't up to snuff. A number \nof other compilers such as KAI++ will also work, but my suspicions are that gcc \nwill get the most use.\n\n\n

              Limitations

              \n
                \n
              1. \nCurrently, weave.blitz handles all standard mathematic \noperators except for the ** power operator. The built-in trigonmetric, log, \nfloor/ceil, and fabs functions might work (but haven't been tested). It also \nhandles all types of array indexing supported by the Numeric module. \n

                \nweave.blitz does not currently support operations that use \narray broadcasting, nor have any of the special purpose functions in Numeric \nsuch as take, compress, etc. been implemented. Note that there are no obvious \nreasons why most of this functionality cannot be added to scipy.weave, so it \nwill likely trickle into future versions. Using slice() objects \ndirectly instead of start:stop:step is also not supported.\n

                2. \n
              2. \nCurrently Python only works on expressions that include assignment such as\n \n 
                \n    >>> result = b + c + d\n
                \n\nThis means that the result array must exist before calling \nweave.blitz. Future versions will allow the following:\n\n 
                \n    >>> result = weave.blitz_eval(\"b + c + d\")\n
                \n
                3. \n
              3. \nweave.blitz works best when algorithms can be expressed in a \n\"vectorized\" form. Algorithms that have a large number of if/thens and other \nconditions are better hand written in C or Fortran. Further, the restrictions \nimposed by requiring vectorized expressions sometimes preclude the use of more \nefficient data structures or algorithms. For maximum speed in these cases, \nhand-coded C or Fortran code is the only way to go.\n
                4. \n
              4. \nOne other point deserves mention lest people be confused. \nweave.blitz is not a general purpose Python->C compiler. It \nonly works for expressions that contain Numeric arrays and/or \nPython scalar values. This focused scope concentrates effort on the \ncompuationally intensive regions of the program and sidesteps the difficult \nissues associated with a general purpose Python->C compiler.\n
                5. \n
              \n\n\n

              Numeric efficiency issues: What compilation buys you

              \n\nSome might wonder why compiling Numeric expressions to C++ is beneficial since \noperations on Numeric array operations are already executed within C loops. \nThe problem is that anything other than the simplest expression are executed in \nless than optimal fashion. Consider the following Numeric expression:\n\n 
              \n    a = 1.2 * b + c * d\n
              \n \nWhen Numeric calculates the value for the 2d array, a, it does \nthe following steps:\n\n 
              \n    temp1 = 1.2 * b\n    temp2 = c * d\n    a = temp1 + temp2\n
              \n \nTwo things to note. Since c is an (perhaps large) array, a large \ntemporary array must be created to store the results of 1.2 * b. \nThe same is true for temp2. Allocation is slow. The second thing \nis that we have 3 loops executing, one to calculate temp1, one for \ntemp2 and one for adding them up. A C loop for the same problem \nmight look like:\n\n 
              \n    for(int i = 0; i < M; i++)\n        for(int j = 0; j < N; j++)\n            a[i,j] = 1.2 * b[i,j] + c[i,j] * d[i,j]\n
              \n \nHere, the 3 loops have been fused into a single loop and there is no longer\na need for a temporary array. This provides a significant speed improvement\nover the above example (write me and tell me what you get). \n

              \nSo, converting Numeric expressions into C/C++ loops that fuse the loops and \neliminate temporary arrays can provide big gains. The goal then,is to convert \nNumeric expression to C/C++ loops, compile them in an extension module, and \nthen call the compiled extension function. The good news is that there is an \nobvious correspondence between the Numeric expression above and the C loop. The \nbad news is that Numeric is generally much more powerful than this simple \nexample illustrates and handling all possible indexing possibilities results in \nloops that are less than straight forward to write. (take a peak in Numeric for \nconfirmation). Luckily, there are several available tools that simplify the \nprocess.\n\n\n

              The Tools

              \n\nweave.blitz relies heavily on several remarkable tools. On the \nPython side, the main facilitators are Jermey Hylton's parser module and Jim \nHuginin's Numeric module. On the compiled language side, Todd Veldhuizen's \nblitz++ array library, written in C++ (shhhh. don't tell David Beazley), does \nthe heavy lifting. Don't assume that, because it's C++, it's much slower than C \nor Fortran. Blitz++ uses a jaw dropping array of template techniques \n(metaprogramming, template expression, etc) to convert innocent looking and \nreadable C++ expressions into to code that usually executes within a few \npercentage points of Fortran code for the same problem. This is good. \nUnfortunately all the template raz-ma-taz is very expensive to compile, so the \n200 line extension modules often take 2 or more minutes to compile. This isn't so \ngood. weave.blitz works to minimize this issue by remembering \nwhere compiled modules live and reusing them instead of re-compiling every time \na program is re-run.\n\n\n

              Parser

              \nTearing Numeric expressions apart, examining the pieces, and then rebuilding \nthem as C++ (blitz) expressions requires a parser of some sort. I can imagine \nsomeone attacking this problem with regular expressions, but it'd likely be \nugly and fragile. Amazingly, Python solves this problem for us. It actually \nexposes its parsing engine to the world through the parser module. \nThe following fragment creates an Abstract Syntax Tree (AST) object for the \nexpression and then converts to a (rather unpleasant looking) deeply nested list \nrepresentation of the tree. \n \n 
              \n    >>> import parser\n    >>> import scipy.weave.misc\n    >>> ast = parser.suite(\"a = b * c + d\")\n    >>> ast_list = ast.tolist()\n    >>> sym_list = scipy.weave.misc.translate_symbols(ast_list)\n    >>> pprint.pprint(sym_list)\n    ['file_input',\n     ['stmt',\n      ['simple_stmt',\n       ['small_stmt',\n        ['expr_stmt',\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'a']]]]]]]]]]]]]]],\n         ['EQUAL', '='],\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'b']]]],\n                    ['STAR', '*'],\n                    ['factor', ['power', ['atom', ['NAME', 'c']]]]],\n                   ['PLUS', '+'],\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'd']]]]]]]]]]]]]]]]],\n       ['NEWLINE', '']]],\n     ['ENDMARKER', '']]\n
              \n\nDespite its looks, with some tools developed by Jermey H., its possible\nto search these trees for specific patterns (sub-trees), extract the \nsub-tree, manipulate them converting python specific code fragments\nto blitz code fragments, and then re-insert it in the parse tree. The parser\nmodule documentation has some details on how to do this. Traversing the \nnew blitzified tree, writing out the terminal symbols as you go, creates\nour new blitz++ expression string.\n\n \n

              Blitz and Numeric

              \nThe other nice discovery in the project is that the data structure used\nfor Numeric arrays and blitz arrays is nearly identical. Numeric stores\n\"strides\" as byte offsets and blitz stores them as element offsets, but\nother than that, they are the same. Further, most of the concept and\ncapabilities of the two libraries are remarkably similar. It is satisfying \nthat two completely different implementations solved the problem with \nsimilar basic architectures. It is also fortitous. The work involved in \nconverting Numeric expressions to blitz expressions was greatly diminished.\nAs an example, consider the code for slicing an array in Python with a\nstride:\n\n 
              \n    >>> a = b[0:4:2] + c\n    >>> a\n    [0,2,4]\n
              \n\n\nIn Blitz it is as follows:\n\n 
              \n    Array<2,int> b(10);\n    Array<2,int> c(3);\n    // ...\n    Array<2,int> a = b(Range(0,3,2)) + c;\n
              \n\n\nHere the range object works exactly like Python slice objects with the exception\nthat the top index (3) is inclusive where as Python's (4) is exclusive. Other \ndifferences include the type declaraions in C++ and parentheses instead of \nbrackets for indexing arrays. Currently, weave.blitz handles the \ninclusive/exclusive issue by subtracting one from upper indices during the\ntranslation. An alternative that is likely more robust/maintainable in the \nlong run, is to write a PyRange class that behaves like Python's range. \nThis is likely very easy.\n

              \nThe stock blitz also doesn't handle negative indices in ranges. The current \nimplementation of the blitz() has a partial solution to this \nproblem. It calculates and index that starts with a '-' sign by subtracting it \nfrom the maximum index in the array so that:\n\n 

              \n                    upper index limit\n                        /-----\\\n    b[:-1] -> b(Range(0,Nb[0]-1-1))\n
              \n\nThis approach fails, however, when the top index is calculated from other \nvalues. In the following scenario, if i+j evaluates to a negative \nvalue, the compiled code will produce incorrect results and could even core-\ndump. Right now, all calculated indices are assumed to be positive.\n \n 
              \n    b[:i-j] -> b(Range(0,i+j))\n
              \n\nA solution is to calculate all indices up front using if/then to handle the\n+/- cases. This is a little work and results in more code, so it hasn't been\ndone. I'm holding out to see if blitz++ can be modified to handle negative\nindexing, but haven't looked into how much effort is involved yet. While it \nneeds fixin', I don't think there is a ton of code where this is an issue.\n

              \nThe actual translation of the Python expressions to blitz expressions is \ncurrently a two part process. First, all x:y:z slicing expression are removed\nfrom the AST, converted to slice(x,y,z) and re-inserted into the tree. Any\nmath needed on these expressions (subtracting from the \nmaximum index, etc.) are also preformed here. _beg and _end are used as special\nvariables that are defined as blitz::fromBegin and blitz::toEnd.\n\n 

              \n    a[i+j:i+j+1,:] = b[2:3,:] \n
              \n\nbecomes a more verbose:\n \n 
              \n    a[slice(i+j,i+j+1),slice(_beg,_end)] = b[slice(2,3),slice(_beg,_end)]\n
              \n \nThe second part does a simple string search/replace to convert to a blitz \nexpression with the following translations:\n\n 
              \n    slice(_beg,_end) -> _all  # not strictly needed, but cuts down on code.\n    slice            -> blitz::Range\n    [                -> (\n    ]                -> )\n    _stp             -> 1\n
              \n\n_all is defined in the compiled function as \nblitz::Range.all(). These translations could of course happen \ndirectly in the syntax tree. But the string replacement is slightly easier. \nNote that name spaces are maintained in the C++ code to lessen the likelyhood \nof name clashes. Currently no effort is made to detect name clashes. A good \nrule of thumb is don't use values that start with '_' or 'py_' in compiled \nexpressions and you'll be fine.\n\n \n

              Type definitions and coersion

              \n\nSo far we've glossed over the dynamic vs. static typing issue between Python \nand C++. In Python, the type of value that a variable holds can change\nthrough the course of program execution. C/C++, on the other hand, forces you\nto declare the type of value a variables will hold prior at compile time.\nweave.blitz handles this issue by examining the types of the\nvariables in the expression being executed, and compiling a function for those\nexplicit types. For example:\n\n 
              \n    a = ones((5,5),Float32)\n    b = ones((5,5),Float32)\n    weave.blitz(\"a = a + b\")\n
              \n\nWhen compiling this expression to C++, weave.blitz sees that the\nvalues for a and b in the local scope have type Float32, or 'float'\non a 32 bit architecture. As a result, it compiles the function using \nthe float type (no attempt has been made to deal with 64 bit issues).\nIt also goes one step further. If all arrays have the same type, a templated\nversion of the function is made and instantiated for float, double, \ncomplex, and complex arrays. Note: This feature has been \nremoved from the current version of the code. Each version will be compiled\nseparately \n

              \nWhat happens if you call a compiled function with array types that are \ndifferent than the ones for which it was originally compiled? No biggie, you'll \njust have to wait on it to compile a new version for your new types. This \ndoesn't overwrite the old functions, as they are still accessible. See the \ncatalog section in the inline() documentation to see how this is handled. \nSuffice to say, the mechanism is transparent to the user and behaves \nlike dynamic typing with the occasional wait for compiling newly typed \nfunctions.\n

              \nWhen working with combined scalar/array operations, the type of the array is \nalways used. This is similar to the savespace flag that was recently \nadded to Numeric. This prevents issues with the following expression perhaps \nunexpectedly being calculated at a higher (more expensive) precision that can \noccur in Python:\n\n 

              \n    >>> a = array((1,2,3),typecode = Float32)\n    >>> b = a * 2.1 # results in b being a Float64 array.\n
              \n \nIn this example, \n\n 
              \n    >>> a = ones((5,5),Float32)\n    >>> b = ones((5,5),Float32)\n    >>> weave.blitz(\"b = a * 2.1\")\n
              \n \nthe 2.1 is cast down to a float before carrying out \nthe operation. If you really want to force the calculation to be a \ndouble, define a and b as \ndouble arrays.\n

              \nOne other point of note. Currently, you must include both the right hand side \nand left hand side (assignment side) of your equation in the compiled \nexpression. Also, the array being assigned to must be created prior to calling \nweave.blitz. I'm pretty sure this is easily changed so that a \ncompiled_eval expression can be defined, but no effort has been made to \nallocate new arrays (and decern their type) on the fly.\n\n \n

              Cataloging Compiled Functions

              \n\nSee the Cataloging functions section in the \nweave.inline() documentation.\n\n \n

              Checking Array Sizes

              \n\nSurprisingly, one of the big initial problems with compiled code was making\nsure all the arrays in an operation were of compatible type. The following\ncase is trivially easy:\n\n 
              \n    a = b + c\n
              \n \nIt only requires that arrays a, b, and c \nhave the same shape. However, expressions like:\n\n 
              \n    a[i+j:i+j+1,:] = b[2:3,:] + c\n
              \n\nare not so trivial. Since slicing is involved, the size of the slices, not the \ninput arrays must be checked. Broadcasting complicates things further because \narrays and slices with different dimensions and shapes may be compatible for \nmath operations (broadcasting isn't yet supported by \nweave.blitz). Reductions have a similar effect as their \nresults are different shapes than their input operand. The binary operators in \nNumeric compare the shapes of their two operands just before they operate on \nthem. This is possible because Numeric treats each operation independently. \nThe intermediate (temporary) arrays created during sub-operations in an \nexpression are tested for the correct shape before they are combined by another \noperation. Because weave.blitz fuses all operations into a \nsingle loop, this isn't possible. The shape comparisons must be done and \nguaranteed compatible before evaluating the expression.\n

              \nThe solution chosen converts input arrays to \"dummy arrays\" that only represent \nthe dimensions of the arrays, not the data. Binary operations on dummy arrays \ncheck that input array sizes are comptible and return a dummy array with the \nsize correct size. Evaluating an expression of dummy arrays traces the \nchanging array sizes through all operations and fails if incompatible array \nsizes are ever found. \n

              \nThe machinery for this is housed in weave.size_check. It \nbasically involves writing a new class (dummy array) and overloading it math \noperators to calculate the new sizes correctly. All the code is in Python and \nthere is a fair amount of logic (mainly to handle indexing and slicing) so the \noperation does impose some overhead. For large arrays (ie. 50x50x50), the \noverhead is negligible compared to evaluating the actual expression. For small \narrays (ie. 16x16), the overhead imposed for checking the shapes with this \nmethod can cause the weave.blitz to be slower than evaluating \nthe expression in Python. \n

              \nWhat can be done to reduce the overhead? (1) The size checking code could be \nmoved into C. This would likely remove most of the overhead penalty compared \nto Numeric (although there is also some calling overhead), but no effort has \nbeen made to do this. (2) You can also call weave.blitz with\ncheck_size=0 and the size checking isn't done. However, if the \nsizes aren't compatible, it can cause a core-dump. So, foregoing size_checking\nisn't advisable until your code is well debugged.\n\n \n

              Creating the Extension Module

              \n\nweave.blitz uses the same machinery as \nweave.inline to build the extension module. The only difference\nis the code included in the function is automatically generated from the\nNumeric array expression instead of supplied by the user.\n\n\n

              Extension Modules

              \nweave.inline and weave.blitz are high level tools\nthat generate extension modules automatically. Under the covers, they use several\nclasses from weave.ext_tools to help generate the extension module.\nThe main two classes are ext_module and ext_function (I'd\nlike to add ext_class and ext_method also). These classes\nsimplify the process of generating extension modules by handling most of the \"boiler\nplate\" code automatically.\n\n\nNote: inline actually sub-classes weave.ext_tools.ext_function \nto generate slightly different code than the standard ext_function.\nThe main difference is that the standard class converts function arguments to\nC types, while inline always has two arguments, the local and global dicts, and\nthe grabs the variables that need to be convereted to C from these.\n\n\n\n

              A Simple Example

              \nThe following simple example demonstrates how to build an extension module within\na Python function:\n\n 
              \n    # examples/increment_example.py\n    from weave import ext_tools\n    \n    def build_increment_ext():\n        \"\"\" Build a simple extension with functions that increment numbers.\n            The extension will be built in the local directory.\n        \"\"\"        \n        mod = ext_tools.ext_module('increment_ext')\n    \n        a = 1 # effectively a type declaration for 'a' in the \n              # following functions.\n    \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n        mod.add_function(func)\n        \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+2));\"    \n        func = ext_tools.ext_function('increment_by_2',ext_code,['a'])\n        mod.add_function(func)\n                \n        mod.compile()\n
              \n\n\nThe function build_increment_ext() creates an extension module \nnamed increment_ext and compiles it to a shared library (.so or \n.pyd) that can be loaded into Python.. increment_ext contains two \nfunctions, increment and increment_by_2. \n\nThe first line of build_increment_ext(),\n\n 
              \n        mod = ext_tools.ext_module('increment_ext') \n
              \n\ncreates an ext_module instance that is ready to have \next_function instances added to it. ext_function \ninstances are created much with a calling convention similar to \nweave.inline(). The most common call includes a C/C++ code \nsnippet and a list of the arguments for the function. The following\n\n 
              \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n
              \n \ncreates a C/C++ extension function that is equivalent to the following Python\nfunction:\n\n 
              \n        def increment(a):\n            return a + 1\n
              \n\nA second method is also added to the module and then,\n\n 
              \n        mod.compile()\n
              \n\nis called to build the extension module. By default, the module is created\nin the current working directory.\n\nThis example is available in the examples/increment_example.py file\nfound in the weave directory. At the bottom of the file in the\nmodule's \"main\" program, an attempt to import increment_ext without\nbuilding it is made. If this fails (the module doesn't exist in the PYTHONPATH), \nthe module is built by calling build_increment_ext(). This approach\nonly takes the time consuming ( a few seconds for this example) process of building\nthe module if it hasn't been built before.\n\n 
              \n    if __name__ == \"__main__\":\n        try:\n            import increment_ext\n        except ImportError:\n            build_increment_ext()\n            import increment_ext\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\n\nNote: If we were willing to always pay the penalty of building the C++ code for \na module, we could store the md5 checksum of the C++ code along with some \ninformation about the compiler, platform, etc. Then, \next_module.compile() could try importing the module before it actually\ncompiles it, check the md5 checksum and other meta-data in the imported module\nwith the meta-data of the code it just produced and only compile the code if\nthe module didn't exist or the meta-data didn't match. This would reduce the\nabove code to:\n\n 
              \n    if __name__ == \"__main__\":\n        build_increment_ext()\n\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\nNote: There would always be the overhead of building the C++ code, but it would only actually compile the code once. You pay a little in overhead and get cleaner\n\"import\" code. Needs some thought.\n\n

              \n\nIf you run increment_example.py from the command line, you get\nthe following:\n\n 

              \n    [eric@n0]$ python increment_example.py\n    a, a+1: 1 2\n    a, a+2: 1 3\n
              \n\nIf the module didn't exist before it was run, the module is created. If it did\nexist, it is just imported and used.\n\n\n

              Fibonacci Example

              \nexamples/fibonacci.py provides a little more complex example of \nhow to use ext_tools. Fibonacci numbers are a series of numbers \nwhere each number in the series is the sum of the previous two: 1, 1, 2, 3, 5, \n8, etc. Here, the first two numbers in the series are taken to be 1. One \napproach to calculating Fibonacci numbers uses recursive function calls. In \nPython, it might be written as:\n\n 
              \n    def fib(a):\n        if a <= 2:\n            return 1\n        else:\n            return fib(a-2) + fib(a-1)\n
              \n\nIn C, the same function would look something like this:\n\n 
              \n     int fib(int a)\n     {                   \n         if(a <= 2)\n             return 1;\n         else\n             return fib(a-2) + fib(a-1);  \n     }                      \n
              \n\nRecursion is much faster in C than in Python, so it would be beneficial\nto use the C version for fibonacci number calculations instead of the\nPython version. We need an extension function that calls this C function\nto do this. This is possible by including the above code snippet as \n\"support code\" and then calling it from the extension function. Support \ncode snippets (usually structure definitions, helper functions and the like)\nare inserted into the extension module C/C++ file before the extension\nfunction code. Here is how to build the C version of the fibonacci number\ngenerator:\n\n 
              \ndef build_fibonacci():\n    \"\"\" Builds an extension module with fibonacci calculators.\n    \"\"\"\n    mod = ext_tools.ext_module('fibonacci_ext')\n    a = 1 # this is effectively a type declaration\n    \n    # recursive fibonacci in C \n    fib_code = \"\"\"\n                   int fib1(int a)\n                   {                   \n                       if(a <= 2)\n                           return 1;\n                       else\n                           return fib1(a-2) + fib1(a-1);  \n                   }                         \n               \"\"\"\n    ext_code = \"\"\"\n                   int val = fib1(a);\n                   return_val = Py::new_reference_to(Py::Int(val));\n               \"\"\"    \n    fib = ext_tools.ext_function('fib',ext_code,['a'])\n    fib.customize.add_support_code(fib_code)\n    mod.add_function(fib)\n\n    mod.compile()\n\n
              \n\nXXX More about custom_info, and what xxx_info instances are good for.\n\n

              \n\nNote: recursion is not the fastest way to calculate fibonacci numbers, but this \napproach serves nicely for this example.\n\n

              \n\n

              Customizing Type Conversions -- Type Factories

              \nnot written\n\n

              Things I wish weave did

              \n\nIt is possible to get name clashes if you uses a variable name that is already defined\nin a header automatically included (such as stdio.h) For instance, if you\ntry to pass in a variable named stdout, you'll get a cryptic error report\ndue to the fact that stdio.h also defines the name. weave\nshould probably try and handle this in some way.\n\nOther things...", "source_code_before": "\n

              Weave Documentation

              \n

              \nBy Eric Jones eric@enthought.com\n

              \n

              Outline

              \n
              \n
              Introduction\n
              Requirements\n
              Installation and Testing\n
              Inline\n
              \n
              More with printf\n
              \n More examples\n
              \n
              Binary search\n
              Dictionary sort\n
              Numeric -- cast/copy/transpose\n
              wxPython
              \n
              \n
              Keyword options\n
              Returning values\n
              \n
              \n The issue with locals()
              \n
              \n
              A quick look at the code\n
              \n Technical Details\n
              \n
              Converting Types\n
              \n
              \n Numeric Argument Conversion\n
              \n String, List, Tuple, and Dictionary Conversion\n
              File Conversion \n
              \n Callable, Instance, and Module Conversion \n
              Customizing Conversions\n
              \n
              Compiling Code\n
              \"Cataloging\" functions\n
              \n
              Function Storage\n
              The PYTHONCOMPILED evnironment variable
              \n
              \n
              \n
              \n
              \n
              \n
              Blitz\n
              \n
              Requirements\n
              Limitations\n
              Numeric Efficiency Issues\n
              The Tools \n
              \n
              Parser\n
              Blitz and Numeric\n
              \n
              Type defintions and coersion\n
              Cataloging Compiled Functions\n
              Checking Array Sizes\n
              Creating the Extension Module\n
              \n
              Extension Modules\n
              \n
              A Simple Example\n
              Fibonacci Example\n
              \n
              Customizing Type Conversions -- Type Factories (not written)\n
              \n
              Type Specifications\n
              Type Information\n
              The Conversion Process \n
              \n
              \n\n

              Introduction

              \n\n

              \nThe weave package provides tools for including C/C++ code within\nin Python code. This offers both another level of optimization to those who need \nit, and an easy way to modify and extend any supported extension libraries such \nas wxPython and hopefully VTK soon. Inlining C/C++ code within Python generally\nresults in speed ups of 1.5x to 30x speed-up over algorithms written in pure\nPython (However, it is also possible to slow things down...). Generally \nalgorithms that require a large number of calls to the Python API don't benefit\nas much from the conversion to C/C++ as algorithms that have inner loops \ncompletely convertable to C.\n

              \nThere are three basic ways to use weave. The \nweave.inline() function executes C code directly within Python, \nand weave.blitz() translates Python Numeric expressions to C++ \nfor fast execution. blitz() was the original reason \nweave was built. For those interested in building extension\nlibraries, the ext_tools module provides classes for building \nextension modules within Python. \n

              \nMost of weave's functionality should work on Windows and Unix, \nalthough some of its functionality requires gcc or a similarly \nmodern C++ compiler that handles templates well. Up to now, most testing has \nbeen done on Windows 2000 with Microsoft's C++ compiler (MSVC) and with gcc \n(mingw32 2.95.2 and 2.95.3-6). All tests also pass on Linux (RH 7.1 \nwith gcc 2.96), and I've had reports that it works on Debian also (thanks \nPearu).\n

              \nThe inline and blitz provide new functionality to \nPython (although I've recently learned about the PyInline project which may offer \nsimilar functionality to inline). On the other hand, tools for \nbuilding Python extension modules already exists (SWIG, SIP, pycpp, CXX, and \nothers). As of yet, I'm not sure where weave fits in this \nspectrum. It is closest in flavor to CXX in that it makes creating new C/C++ \nextension modules pretty easy. However, if you're wrapping a gaggle of legacy \nfunctions or classes, SWIG and friends are definitely the better choice. \nweave is set up so that you can customize how Python types are \nconverted to C types in weave. This is great for \ninline(), but, for wrapping legacy code, it is more flexible to \nspecify things the other way around -- that is how C types map to Python types. \nThis weave does not do. I guess it would be possible to build \nsuch a tool on top of weave, but with good tools like SWIG around, \nI'm not sure the effort produces any new capabilities. Things like function \noverloading are probably easily implemented in weave and it might \nbe easier to mix Python/C code in function calls, but nothing beyond this comes \nto mind. So, if you're developing new extension modules or optimizing Python \nfunctions in C, weave.ext_tools() might be the tool \nfor you. If you're wrapping legacy code, stick with SWIG.\n

              \nThe next several sections give the basics of how to use weave.\nWe'll discuss what's happening under the covers in more detail later \non. Serious users will need to at least look at the type conversion section to \nunderstand how Python variables map to C/C++ types and how to customize this \nbehavior. One other note. If you don't know C or C++ then these docs are \nprobably of very little help to you. Further, it'd be helpful if you know \nsomething about writing Python extensions. weave does quite a \nbit for you, but for anything complex, you'll need to do some conversions, \nreference counting, etc.\n

              \n\nNote: weave is actually part of the SciPy package. However, it works fine as a \nstandalone package. The examples here are given as if it is used as a stand \nalone package. If you are using from within scipy, you can use from \nscipy import weave and the examples will work identically.\n\n\n

              Requirements

              \n
                \n
              • Python\n

                \n I use 2.1.1. Probably 2.0 or higher should work.\n

                \n

                • \n \n
              • C++ compiler\n

                \n weave uses distutils to actually build \n extension modules, so it uses whatever compiler was originally used to \n build Python. weave itself requires a C++ compiler. If \n you used a C++ compiler to build Python, your probably fine.\n

                \n On Unix gcc is the preferred choice, because I've done a little \n testing with it. All testing has been done with gcc, but I expect the \n majority of compilers should work for inline and \n ext_tools. The one issue I'm not sure about is that I've \n hard coded things so that compilations are linked with the \n stdc++ library. Is this standard across \n Unix compilers, or is this a gcc-ism?\n

                \n For blitz(), you'll need a reasonably recent version of \n gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n versions are likely to work. Its likely that KAI's C++ compiler and \n maybe some others will work, but I haven't tried. My advise is to use \n gcc for now unless your willing to tinker with the code some.\n

                \n On Windows, either MSVC or gcc (www.mingw.org\" > mingw32) should work. Again, \n you'll need gcc for blitz() as the\n MSVC compiler doesn't handle templates well.\n

                \n I have not tried Cygwin, so please report success if it works for you.\n

                \n

                • \n\n
              • Numeric (optional)\n

                \n The python Numeric module from here. is required for \n blitz() to work. Be sure and get NumPy, not NumArray\n which is the \"next generation\" implementation.\n

                \n

                • \n
              • scipy_distutils and scipy_test (packaged with weave)\n

                \n These two modules are packaged with weave in both\n the windows installer and the source distributions. If you are using\n CVS, however, you'll need to download these separately (also available\n through CVS at SciPy).\n

                \n

                • \n
              \n

              \n\n\n

              Installation and Testing

              \n

              \nThere are currently two ways to get weave. Fist, \nweave is part of SciPy and installed automatically (as a sub-\npackage) whenever SciPy is installed (although the latest version isn't in \nSciPy yet, so use this one for now). Second, since weave is \nuseful outside of the scientific community, it has been setup so that it can be\nused as a stand-alone module. \n\n

              \nThe stand-alone version can be downloaded from here. Unix users should grab the \ntar ball (.tgz file) and install it using the following commands.\n\n 

              \n    tar -xzvf weave-0.2.tar.gz\n    cd weave-0.2\n    python setup.py install\n
              \n\nThis will also install two other packages, scipy_distutils and \nscipy_test. The first is needed by the setup process itself and \nboth are used in the unit-testing process. For Windows users, it's even easier. \nThey can download the click-install .exe file and run it for automatic \ninstallation. Numeric is required if you want to use blitz(), but\nisn't necessary for inline() or ext_tools\n

              \nIf you're using the CVS version, you'll need to install scipy_distutils and \nscipy_test modules (also available from CVS) on your own.\n

              \n Note: The dependency issue here is a little sticky. I hate to make people \ndownload more than one file (and so I haven't), but distutils doesn't have a \nway to do conditional installation -- at least that I know about. This can \nlead to undesired clobbering of modules. What to do, what to do...\n

              \nOnce weave is installed, fire up python and run its unit tests.\n\n 

              \n    >>> import weave\n    >>> weave.test()\n    runs long time... spews tons of output\n
              \n\nThis takes a loooong time. On windows, it is usually several minutes. On Unix \nwith remote file systems, I've had it take 15 or so minutes. In the end, it \nshould run about 180 tests and spew some speed results along the way. If you \nget errors, please let me know.\n\nIf you don't have Numeric installed, you'll get some module import errors \nduring the test setup phase for modules that are Numeric specific (blitz_spec, \nblitz_tools, size_check, standard_array_spec, ast_tools), but all test should\npass (about 100 and they should complete in several minutes).\n

              \nIf you only want to test a single module of the package, you can do this by\nrunning test() for that specific module.\n\n 

              \n    >>> import weave.scalar_spec\n    >>> weave.scalar_spec.test()\n    .......\n    ----------------------------------------------------------------------\n    Ran 7 tests in 23.284s\n
              \n\nWindows Note: I've had some test fail on windows machines where I have msvc, \ngcc-2.95.2 (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My \nenvironment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the path. \nThe test process runs very smoothly until the end where several test using gcc \nfail with cpp0 not found by g++. If I check os.system('gcc -v') before running \ntests, I get gcc-2.95.3-6. If I check after running tests (and after failure), \nI get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\\gcc first in it \nand is not corrupted (msvc/distutils messes with the environment variables, so \nwe have to undo its work in some places). If anyone else sees this, let me \nknow - - it may just be an quirk on my machine (unlikely). Testing with the \ngcc- 2.95.2 installation always works.\n\n

              \n\nwxPython Note: wxPython tests are not enabled by default because importing\nwxPython on a Unix machine without access to a X-term will cause the \nprogram to exit. Anyone know of a safe way to detect whether wxPython\ncan be imported and whether a display exists on a machine?\n\n\n\n

              Inline

              \n

              \ninline() compiles and executes C/C++ code on the fly. Variables \nin the local and global Python scope are also available in the C/C++ code. \nValues are passed to the C/C++ code by assignment much like variables \nare passed into a standard Python function. Values are returned from the C/C++ \ncode through a special argument called return_val. Also, the contents of \nmutable objects can be changed within the C/C++ code and the changes remain \nafter the C code exits and returns to Python. (more on this later)\n

              \nHere's a trivial printf example using inline():\n\n 

              \n    >>> import weave    \n    >>> a  = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n

              \nIn this, its most basic form, inline(c_code, var_list) requires two \narguments. c_code is a string of valid C/C++ code. \nvar_list is a list of variable names that are passed from \nPython into C/C++. Here we have a simple printf statement that \nwrites the Python variable a to the screen. The first time you run \nthis, there will be a pause while the code is written to a .cpp file, compiled \ninto an extension module, loaded into Python, cataloged for future use, and \nexecuted. On windows (850 MHz PIII), this takes about 1.5 seconds when using \nMicrosoft's C++ compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). \nAll subsequent executions of the code will happen very quickly because the code \nonly needs to be compiled once. If you kill and restart the interpreter and then \nexecute the same code fragment again, there will be a much shorter delay in the \nfractions of seconds range. This is because weave stores a \ncatalog of all previously compiled functions in an on disk cache. When it sees \na string that has been compiled, it loads the already compiled module and \nexecutes the appropriate function. \n

              \n\nNote: If you try the printf example in a GUI shell such as IDLE, \nPythonWin, PyShell, etc., you're unlikely to see the output. This is because the \nC code is writing to stdout, instead of to the GUI window. This doesn't mean \nthat inline doesn't work in these environments -- it only means that standard \nout in C is not the same as the standard out for Python in these cases. Non \ninput/output functions will work as expected.\n\n

              \nAlthough effort has been made to reduce the overhead associated with calling \ninline, it is still less efficient for simple code snippets than using \nequivalent Python code. The simple printf example is actually \nslower by 30% or so than using Python print statement. And, it is \nnot difficult to create code fragments that are 8-10 times slower using inline \nthan equivalent Python. However, for more complicated algorithms, \nthe speed up can be worth while -- anywhwere from 1.5- 30 times faster. \nAlgorithms that have to manipulate Python objects (sorting a list) usually only \nsee a factor of 2 or so improvement. Algorithms that are highly computational \nor manipulate Numeric arrays can see much larger improvements. The \nexamples/vq.py file shows a factor of 30 or more improvement on the vector \nquantization algorithm that is used heavily in information theory and \nclassification problems.\n

              \n\n\n

              More with printf

              \n

              \nMSVC users will actually see a bit of compiler output that distutils does not\nsupress the first time the code executes:\n\n 

                  \n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    sc_e013937dbc8c647ac62438874e5795131.cpp\n       Creating library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\n       \\Release\\sc_e013937dbc8c647ac62438874e5795131.lib and object C:\\DOCUME\n       ~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_e013937dbc8c64\n       7ac62438874e5795131.exp\n    1\n
              \n

              \nNothing bead is happening, its just a bit annoying. Anyone know how to \nturn this off? \n

              \nThis example also demonstrates using 'raw strings'. The r \npreceeding the code string in the last example denotes that this is a 'raw \nstring'. In raw strings, the backslash character is not interpreted as an \nescape character, and so it isn't necessary to use a double backslash to \nindicate that the '\\n' is meant to be interpreted in the C printf \nstatement instead of by Python. If your C code contains a lot\nof strings and control characters, raw strings might make things easier.\nMost of the time, however, standard strings work just as well.\n\n

              \nThe printf statement in these examples is formatted to print \nout integers. What happens if a is a string? inline\nwill happily, compile a new version of the code to accept strings as input,\nand execute the code. The result?\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    32956972\n
              \n

              \nIn this case, the result is non-sensical, but also non-fatal. In other \nsituations, it might produce a compile time error because a is \nrequired to be an integer at some point in the code, or it could produce a \nsegmentation fault. Its possible to protect against passing \ninline arguments of the wrong data type by using asserts in \nPython.\n\n 

                  \n    >>> a = 'string'\n    >>> def protected_printf(a):    \n    ...     assert(type(a) == type(1))\n    ...     weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    >>> protected_printf(1)\n     1\n    >>> protected_printf('string')\n    AssertError...\n
              \n\n

              \nFor printing strings, the format statement needs to be changed.\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%s\\n\",a);',['a'])\n    string\n
              \n\n

              \nAs in this case, C/C++ code fragments often have to change to accept different \ntypes. For the given printing task, however, C++ streams provide a way of a \nsingle statement that works for integers and strings. By default, the stream \nobjects live in the std (standard) namespace and thus require the use of \nstd::.\n\n 

                  \n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    1    \n    >>> a = 'string'\n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    string\n
              \n \n

              \nExamples using printf and cout are included in \nexamples/print_example.py.\n\n\n

              More examples

              \n\nThis section shows several more advanced uses of inline. It \nincludes a few algorithms from the Python Cookbook \nthat have been re-written in inline C to improve speed as well as a couple \nexamples using Numeric and wxPython.\n\n\n

              Binary search

              \nLets look at the example of searching a sorted list of integers for a value. \nFor inspiration, we'll use Kalle Svensson's \nbinary_search() algorithm from the Python Cookbook. His recipe follows:\n\n 
              \n    def binary_search(seq, t):\n        min = 0; max = len(seq) - 1\n        while 1:\n            if max < min:\n                return -1\n            m = (min  + max)  / 2\n            if seq[m] < t: \n                min = m  + 1 \n            elif seq[m] > t: \n                max = m  - 1 \n            else:\n                return m    \n
              \n\nThis Python version works for arbitrary Python data types. The C version below is \nspecialized to handle integer values. There is a little type checking done in \nPython to assure that we're working with the correct data types before heading \ninto C. The variables seq and t don't need to be \ndeclared beacuse weave handles converting and declaring them in \nthe C code. All other temporary variables such as min, max, etc. \nmust be declared -- it is C after all. Here's the new mixed Python/C function:\n\n 
                  \n    def c_int_binary_search(seq,t):\n        # do a little type checking in Python\n        assert(type(t) == type(1))\n        assert(type(seq) == type([]))\n        \n        # now the C code\n        code = \"\"\"\n               #line 29 \"binary_search.py\"\n               int val, m, min = 0;  \n               int max = seq.length() - 1;\n               PyObject *py_val; \n               for(;;)\n               {\n                   if (max < min  ) \n                   { \n                       return_val =  Py::new_reference_to(Py::Int(-1)); \n                       break;\n                   } \n                   m =  (min + max) /2;\n                   val =    py_to_int(PyList_GetItem(seq.ptr(),m),\"val\"); \n                   if (val  < t) \n                       min = m  + 1;\n                   else if (val >  t)\n                       max = m - 1;\n                   else\n                   {\n                       return_val = Py::new_reference_to(Py::Int(m));\n                       break;\n                   }\n               }\n               \"\"\"\n        return inline(code,['seq','t'])\n
              \n

              \nWe have two variables seq and t passed in. \nt is guaranteed (by the assert) to be an integer. \nPython integers are converted to C int types in the transition from Python to \nC. seq is a Python list. By default, it is translated to a CXX \nlist object. Full documentation for the CXX library can be found at its website. The basics are that the CXX \nprovides C++ class equivalents for Python objects that simplify, or at \nleast object orientify, working with Python objects in C/C++. For example, \nseq.length() returns the length of the list. A little more about\nCXX and its class methods, etc. is in the ** type conversions ** section.\n

              \n\nNote: CXX uses templates and therefore may be a little less portable than \nanother alternative by Gordan McMillan called SCXX which was inspired by\nCXX. It doesn't use templates so it should compile faster and be more portable.\nSCXX has a few less features, but it appears to me that it would mesh with\nthe needs of weave quite well. Hopefully xxx_spec files will be written\nfor SCXX in the future, and we'll be able to compare on a more empirical\nbasis. Both sets of spec files will probably stick around, it just a question\nof which becomes the default.\n\n

              \nMost of the algorithm above looks similar in C to the original Python code. \nThere are two main differences. The first is the setting of \nreturn_val instead of directly returning from the C code with a \nreturn statement. return_val is an automatically \ndefined variable of type PyObject* that is returned from the C \ncode back to Python. You'll have to handle reference counting issues when \nsetting this variable. In this example, CXX classes and functions handle the \ndirty work. All CXX functions and classes live in the namespace \nPy::. The following code converts the integer m to a \nCXX Int() object and then to a PyObject* with an \nincremented reference count using Py::new_reference_to().\n\n 

                 \n    return_val = Py::new_reference_to(Py::Int(m));\n
              \n

              \nThe second big differences shows up in the retrieval of integer values from the \nPython list. The simple Python seq[i] call balloons into a C \nPython API call to grab the value out of the list and then a separate call to \npy_to_int() that converts the PyObject* to an integer. \npy_to_int() includes both a NULL cheack and a \nPyInt_Check() call as well as the conversion call. If either of \nthe checks fail, an exception is raised. The entire C++ code block is executed \nwith in a try/catch block that handles exceptions much like Python \ndoes. This removes the need for most error checking code.\n

              \nIt is worth note that CXX lists do have indexing operators that result \nin code that looks much like Python. However, the overhead in using them \nappears to be relatively high, so the standard Python API was used on the \nseq.ptr() which is the underlying PyObject* of the \nList object.\n

              \nThe #line directive that is the first line of the C code \nblock isn't necessary, but it's nice for debugging. If the compilation fails \nbecause of the syntax error in the code, the error will be reported as an error \nin the Python file \"binary_search.py\" with an offset from the given line number \n(29 here).\n

              \nSo what was all our effort worth in terms of efficiency? Well not a lot in \nthis case. The examples/binary_search.py file runs both Python and C versions \nof the functions As well as using the standard bisect module. If \nwe run it on a 1 million element list and run the search 3000 times (for 0-\n2999), here are the results we get:\n\n 

                 \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python binary_search.py\n    Binary search for 3000 items in 1000000 length list of integers:\n     speed in python: 0.159999966621\n     speed of bisect: 0.121000051498\n     speed up: 1.32\n     speed in c: 0.110000014305\n     speed up: 1.45\n     speed in c(no asserts): 0.0900000333786\n     speed up: 1.78\n
              \n

              \nSo, we get roughly a 50-75% improvement depending on whether we use the Python \nasserts in our C version. If we move down to searching a 10000 element list, \nthe advantage evaporates. Even smaller lists might result in the Python \nversion being faster. I'd like to say that moving to Numeric lists (and \ngetting rid of the GetItem() call) offers a substantial speed up, but my \npreliminary efforts didn't produce one. I think the log(N) algorithm is to \nblame. Because the algorithm is nice, there just isn't much time spent \ncomputing things, so moving to C isn't that big of a win. If there are ways to \nreduce conversion overhead of values, this may improve the C/Python speed \nup. Anyone have other explanations or faster code, please let me know.\n\n\n

              Dictionary Sort

              \n

              \nThe demo in examples/dict_sort.py is another example from the Python CookBook. \nThis \nsubmission, by Alex Martelli, demonstrates how to return the values from a \ndictionary sorted by their keys:\n\n 

                     \n    def sortedDictValues3(adict):\n        keys = adict.keys()\n        keys.sort()\n        return map(adict.get, keys)\n
              \n

              \nAlex provides 3 algorithms and this is the 3rd and fastest of the set. The C \nversion of this same algorithm follows:\n\n 

                     \n    def c_sort(adict):\n        assert(type(adict) == type({}))\n        code = \"\"\"     \n        #line 21 \"dict_sort.py\"  \n        Py::List keys = adict.keys();\n        Py::List items(keys.length()); keys.sort();     \n        PyObject* item = NULL; \n        for(int i = 0;  i < keys.length();i++)\n        {\n            item = PyList_GET_ITEM(keys.ptr(),i);\n            item = PyDict_GetItem(adict.ptr(),item);\n            Py_XINCREF(item);\n            PyList_SetItem(items.ptr(),i,item);              \n        }           \n        return_val = Py::new_reference_to(items);\n        \"\"\"   \n        return inline_tools.inline(code,['adict'],verbose=1)\n
              \n

              \nLike the original Python function, the C++ version can handle any Python \ndictionary regardless of the key/value pair types. It uses CXX objects for the \nmost part to declare python types in C++, but uses Python API calls to manipulate \ntheir contents. Again, this choice is made for speed. The C++ version, while\nmore complicated, is about a factor of 2 faster than Python.\n\n 

                     \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python dict_sort.py\n    Dict sort of 1000 items for 300 iterations:\n     speed in python: 0.319999933243\n    [0, 1, 2, 3, 4]\n     speed in c: 0.151000022888\n     speed up: 2.12\n    [0, 1, 2, 3, 4]\n
              \n

              \n\n

              Numeric -- cast/copy/transpose

              \n\nCastCopyTranspose is a function called quite heavily by Linear Algebra routines\nin the Numeric library. Its needed in part because of the row-major memory layout\nof multi-demensional Python (and C) arrays vs. the col-major order of the underlying\nFortran algorithms. For small matrices (say 100x100 or less), a significant\nportion of the common routines such as LU decompisition or singular value decompostion\nare spent in this setup routine. This shouldn't happen. Here is the Python\nversion of the function using standard Numeric operations.\n\n 
                     \n    def _castCopyAndTranspose(type, array):\n        if a.typecode() == type:\n            cast_array = copy.copy(Numeric.transpose(a))\n        else:\n            cast_array = copy.copy(Numeric.transpose(a).astype(type))\n        return cast_array\n
              \n\nAnd the following is a inline C version of the same function:\n\n 
              \n    from weave.blitz_tools import blitz_type_factories\n    from weave import scalar_spec\n    from weave import inline\n    def _cast_copy_transpose(type,a_2d):\n        assert(len(shape(a_2d)) == 2)\n        new_array = zeros(shape(a_2d),type)\n        numeric_type = scalar_spec.numeric_to_blitz_type_mapping[type]\n        code = \\\n        \"\"\"  \n        for(int i = 0;i < _Na_2d[0]; i++)  \n            for(int j = 0;  j < _Na_2d[1]; j++)\n                new_array(i,j) = (%s) a_2d(j,i);\n        \"\"\" % numeric_type\n        inline(code,['new_array','a_2d'],\n               type_factories = blitz_type_factories,compiler='gcc')\n        return new_array\n
              \n\nThis example uses blitz++ arrays instead of the standard representation of \nNumeric arrays so that indexing is simplier to write. This is accomplished by \npassing in the blitz++ \"type factories\" to override the standard Python to C++ \ntype conversions. Blitz++ arrays allow you to write clean, fast code, but they \nalso are sloooow to compile (20 seconds or more for this snippet). This is why \nthey aren't the default type used for Numeric arrays (and also because most \ncompilers can't compile blitz arrays...). inline() is also forced \nto use 'gcc' as the compiler because the default compiler on Windows (MSVC) \nwill not compile blitz code. 'gcc' I think will use the standard compiler \non Unix machine instead of explicitly forcing gcc (check this) \n\nComparisons of the Python vs inline C++ code show a factor of 3 speed up. Also \nshown are the results of an \"inplace\" transpose routine that can be used if the \noutput of the linear algebra routine can overwrite the original matrix (this is \noften appropriate). This provides another factor of 2 improvement.\n\n 
              \n     #C:\\home\\ej\\wrk\\scipy\\weave\\examples> python cast_copy_transpose.py\n    # Cast/Copy/Transposing (150,150)array 1 times\n    #  speed in python: 0.870999932289\n    #  speed in c: 0.25\n    #  speed up: 3.48\n    #  inplace transpose c: 0.129999995232\n    #  speed up: 6.70\n
              \n\n\n

              wxPython

              \n\ninline knows how to handle wxPython objects. Thats nice in and of\nitself, but it also demonstrates that the type conversion mechanism is reasonably \nflexible. Chances are, it won't take a ton of effort to support special types\nyou might have. The examples/wx_example.py borrows the scrolled window\nexample from the wxPython demo, accept that it mixes inline C code in the middle\nof the drawing function.\n\n 
              \n    def DoDrawing(self, dc):\n        \n        red = wxNamedColour(\"RED\");\n        blue = wxNamedColour(\"BLUE\");\n        grey_brush = wxLIGHT_GREY_BRUSH;\n        code = \\\n        \"\"\"\n        #line 108 \"wx_example.py\" \n        dc->BeginDrawing();\n        dc->SetPen(wxPen(*red,4,wxSOLID));\n        dc->DrawRectangle(5,5,50,50);\n        dc->SetBrush(*grey_brush);\n        dc->SetPen(wxPen(*blue,4,wxSOLID));\n        dc->DrawRectangle(15, 15, 50, 50);\n        \"\"\"\n        inline(code,['dc','red','blue','grey_brush'])\n        \n        dc.SetFont(wxFont(14, wxSWISS, wxNORMAL, wxNORMAL))\n        dc.SetTextForeground(wxColour(0xFF, 0x20, 0xFF))\n        te = dc.GetTextExtent(\"Hello World\")\n        dc.DrawText(\"Hello World\", 60, 65)\n\n        dc.SetPen(wxPen(wxNamedColour('VIOLET'), 4))\n        dc.DrawLine(5, 65+te[1], 60+te[0], 65+te[1])\n        ...\n
              \n\nHere, some of the Python calls to wx objects were just converted to C++ calls. There\nisn't any benefit, it just demonstrates the capabilities. You might want to use this\nif you have a computationally intensive loop in your drawing code that you want to \nspeed up.\n\nOn windows, you'll have to use the MSVC compiler if you use the standard wxPython\nDLLs distributed by Robin Dunn. Thats because MSVC and gcc, while binary\ncompatible in C, are not binary compatible for C++. In fact, its probably best, no \nmatter what platform you're on, to specify that inline use the same\ncompiler that was used to build wxPython to be on the safe side. There isn't currently\na way to learn this info from the library -- you just have to know. Also, at least\non the windows platform, you'll need to install the wxWindows libraries and link to \nthem. I think there is a way around this, but I haven't found it yet -- I get some\nlinking errors dealing with wxString. One final note. You'll probably have to\ntweak weave/wx_spec.py or weave/wx_info.py for your machine's configuration to\npoint at the correct directories etc. There. That should sufficiently scare people\ninto not even looking at this... :)\n\n              \n

              Keyword Options

              \n

              \nThe basic definition of the inline() function has a slew of \noptional variables. It also takes keyword arguments that are passed to \ndistutils as compiler options. The following is a formatted \ncut/paste of the argument section of inline's doc-string. It \nexplains all of the variables. Some examples using various options will \nfollow.\n\n 

                     \n    def inline(code,arg_names,local_dict = None, global_dict = None, \n               force = 0, \n               compiler='',\n               verbose = 0, \n               support_code = None,\n               customize=None, \n               type_factories = None, \n               auto_downcast=1,\n               **kw):\n
              \n\n \ninline has quite \na few options as listed below. Also, the keyword arguments for distutils \nextension modules are accepted to specify extra information needed for \ncompiling. \n
              \n

              inline Arguments:

              \n
              \n
              \n
              code
              \n \n
              \nstring. A string of valid C++ code. It should not \n specify a return statement. Instead it should assign results that need to be \n returned to Python in the return_val. \n
              \n\n
              arg_names
              \n \n
              \nlist of strings. A list of Python variable names \n that should be transferred from Python into the C/C++ code. \n
              \n\n
              local_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the local scope for the C/C++ \n code. If local_dict is not specified the local dictionary of the calling \n function is used. \n
              \n\n
              global_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the global scope for the C/C++ \n code. If global_dict is not specified the global dictionary of the calling \n function is used. \n
              \n\n
              force
              \n \n
              \noptional. 0 or 1. default 0. If 1, the C++ code is \n compiled every time inline is called. This is really only useful for \n debugging, and probably only useful if you're editing support_code a lot. \n
              \n\n
              compiler
              \n \n
              \noptional. string. The name of compiler to use when compiling. On windows, it \nunderstands 'msvc' and 'gcc' as well as all the compiler names understood by \ndistutils. On Unix, it'll only understand the values understoof by distutils. \n(I should add 'gcc' though to this).\n

              \nOn windows, the compiler defaults to the Microsoft C++ compiler. If this isn't \navailable, it looks for mingw32 (the gcc compiler).\n

              \nOn Unix, it'll probably use the same compiler that was used when compiling \nPython. Cygwin's behavior should be similar.

              \n
              \n\n
              verbose
              \n \n
              \noptional. 0,1, or 2. defualt 0. Speficies how much \n much information is printed during the compile phase of inlining code. 0 is \n silent (except on windows with msvc where it still prints some garbage). 1 \n informs you when compiling starts, finishes, and how long it took. 2 prints \n out the command lines for the compilation process and can be useful if you're \n having problems getting code to work. Its handy for finding the name of the \n .cpp file if you need to examine it. verbose has no affect if the \n compilation isn't necessary. \n
              \n\n
              support_code
              \n \n
              \noptional. string. A string of valid C++ code \n declaring extra code that might be needed by your compiled function. This \n could be declarations of functions, classes, or structures. \n
              \n\n
              customize
              \n \n
              \noptional. base_info.custom_info object. An \n alternative way to specifiy support_code, headers, etc. needed by the \n function see the weave.base_info module for more details. (not sure \n this'll be used much). \n \n
              \n
              type_factories
              \n \n
              \noptional. list of type specification factories. These guys are what convert \nPython data types to C/C++ data types. If you'd like to use a different set of \ntype conversions than the default, specify them here. Look in the type \nconversions section of the main documentation for examples.\n
              \n
              auto_downcast
              \n \n
              \noptional. 0 or 1. default 1. This only affects functions that have Numeric \narrays as input variables. Setting this to 1 will cause all floating point \nvalues to be cast as float instead of double if all the Numeric arrays are of \ntype float. If even one of the arrays has type double or double complex, all \nvariables maintain there standard types.\n
              \n
              \n
              \n\n

              Distutils keywords:

              \n
              \ninline() also accepts a number of distutils keywords \nfor controlling how the code is compiled. The following descriptions have been \ncopied from Greg Ward's distutils.extension.Extension class doc-\nstrings for convenience:\n\n
              \n
              sources
              \n \n
              \n[string] list of source filenames, relative to the \n distribution root (where the setup script lives), in Unix form \n (slash-separated) for portability. Source files may be C, C++, SWIG (.i), \n platform-specific resource files, or whatever else is recognized by the \n \"build_ext\" command as source for a Python extension. Note: The module_path \n file is always appended to the front of this list \n
              \n\n
              include_dirs
              \n \n
              \n[string] list of directories to search for C/C++ \n header files (in Unix form for portability) \n
              \n\n
              define_macros
              \n \n
              \n[(name : string, value : string|None)] list of \n macros to define; each macro is defined using a 2-tuple, where 'value' is \n either the string to define it to or None to define it without a particular \n value (equivalent of \"#define FOO\" in source or -DFOO on Unix C compiler \n command line) \n
              \n
              undef_macros
              \n \n
              \n[string] list of macros to undefine explicitly \n
              \n
              library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at link time \n
              \n
              libraries
              \n
              \n[string] list of library names (not filenames or paths) to link against \n
              \n
              runtime_library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at run time (for \nshared extensions, this is when the extension is loaded) \n
              \n\n
              extra_objects
              \n \n
              \n[string] list of extra files to link with (eg. \n object files not implied by 'sources', static library that must be \n explicitly specified, binary resource files, etc.) \n
              \n\n
              extra_compile_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when compiling the source files in 'sources'. For \n platforms and compilers where \"command line\" makes sense, this is typically \n a list of command-line arguments, but for other platforms it could be \n anything. \n
              \n
              extra_link_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when linking object files together to create the \n extension (or to create a new static Python interpreter). Similar \n interpretation as for 'extra_compile_args'. \n
              \n
              export_symbols
              \n \n
              \n[string] list of symbols to be exported from a shared extension. Not used on \nall platforms, and not generally necessary for Python extensions, which \ntypically export exactly one symbol: \"init\" + extension_name. \n
              \n
              \n
              \n\n\n

              Keyword Option Examples

              \nWe'll walk through several examples here to demonstrate the behavior of \ninline and also how the various arguments are used.\n\nIn the simplest (most) cases, code and arg_names\nare the only arguments that need to be specified. Here's a simple example\nrun on Windows machine that has Microsoft VC++ installed.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'string'\n    >>> code = \"\"\"\n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));\n    ...        \"\"\"\n    >>> inline(code,['a'])\n     sc_86e98826b65b047ffd2cd5f479c627f12.cpp\n    Creating\n       library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f12.lib\n    and object C:\\DOCUME~ 1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ff\n    d2cd5f479c627f12.exp\n    6\n    >>> inline(code,['a'])\n    6\n
              \n \nWhen inline is first run, you'll notice that pause and some \ntrash printed to the screen. The \"trash\" is acutually part of the compilers\noutput that distutils does not supress. On Unix or windows machines with only\ngcc installed, the trash will not appear. On the second call, the code \nfragment is not compiled since it already exists, and only the answer is \nreturned. Now kill the interpreter and restart, and run the same code with\na different string.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'a longer string' \n    >>> code = \"\"\" \n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));  \n    ...        \"\"\"\n    >>> inline(code,['a'])\n    15\n
              \n

              \nNotice this time, inline() did not recompile the code because it\nfound the compiled function in the persistent catalog of functions. There is\na short pause as it looks up and loads the function, but it is much shorter \nthan compiling would require.\n

              \nYou can specify the local and global dictionaries if you'd like (much like \nexec or eval() in Python), but if they aren't \nspecified, the \"expected\" ones are used -- i.e. the ones from the function that \ncalled inline() . This is accomplished through a little call \nframe trickery. Here is an example where the local_dict is specified using\nthe same code example from above:\n\n 

              \n    >>> a = 'a longer string'\n    >>> b = 'an even  longer string' \n    >>> my_dict = {'a':b}\n    >>> inline(code,['a'])\n    15\n    >>> inline(code,['a'],my_dict)\n    21\n
              \n \n

              \nEverytime, the code is changed, inline does a \nrecompile. However, changing any of the other options in inline does not\nforce a recompile. The force option was added so that one\ncould force a recompile when tinkering with other variables. In practice,\nit is just as easy to change the code by a single character\n(like adding a space some place) to force the recompile. Note: It also \nmight be nice to add some methods for purging the cache and on disk \ncatalogs.\n

              \nI use verbose sometimes for debugging. When set to 2, it'll \noutput all the information (including the name of the .cpp file) that you'd\nexpect from running a make file. This is nice if you need to examine the\ngenerated code to see where things are going haywire. Note that error\nmessages from failed compiles are printed to the screen even if verbose\n is set to 0.\n

              \nThe following example demonstrates using gcc instead of the standard msvc \ncompiler on windows using same code fragment as above. Because the example has \nalready been compiled, the force=1 flag is needed to make \ninline() ignore the previously compiled version and recompile \nusing gcc. The verbose flag is added to show what is printed out:\n\n 

              \n    >>>inline(code,['a'],compiler='gcc',verbose=2,force=1)\n    running build_ext    \n    building 'sc_86e98826b65b047ffd2cd5f479c627f13' extension \n    c:\\gcc-2.95.2\\bin\\g++.exe -mno-cygwin -mdll -O2 -w -Wstrict-prototypes -IC:\n    \\home\\ej\\wrk\\scipy\\weave -IC:\\Python21\\Include -c C:\\DOCUME~1\\eric\\LOCAL\n    S~1\\Temp\\python21_compiled\\sc_86e98826b65b047ffd2cd5f479c627f13.cpp -o C:\\D\n    OCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b04\n    7ffd2cd5f479c627f13.o    \n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxextensions.c (C:\\DOCUME~1\\eri\n    c\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxextensions.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxsupport.cxx (C:\\DOCUME~1\\eric\n    \\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxsupport.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\IndirectPythonInterface.cxx (C:\\\n    DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\indirectpythonin\n    terface.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxx_extensions.cxx (C:\\DOCUME~1\\\n    eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxx_extensions.o up-to-da\n    te)\n    writing C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86\n    e98826b65b047ffd2cd5f479c627f13.def\n    c:\\gcc-2.95.2\\bin\\dllwrap.exe --driver-name g++ -mno-cygwin -mdll -static -\n    -output-lib C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\l\n    ibsc_86e98826b65b047ffd2cd5f479c627f13.a --def C:\\DOCUME~1\\eric\\LOCALS~1\\Te\n    mp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f13.def \n    -s C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e9882\n    6b65b047ffd2cd5f479c627f13.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compil\n    ed\\temp\\Release\\cxxextensions.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\cxxsupport.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\indirectpythoninterface.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\n    \\python21_compiled\\temp\\Release\\cxx_extensions.o -LC:\\Python21\\libs -lpytho\n    n21 -o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\sc_86e98826b65b047f\n    fd2cd5f479c627f13.pyd\n    15\n
              \n\nThat's quite a bit of output. verbose=1 just prints the compile\ntime.\n\n 
              \n    >>>inline(code,['a'],compiler='gcc',verbose=1,force=1)\n    Compiling code...\n    finished compiling (sec):  6.00800001621\n    15\n
              \n\n

              \n Note: I've only used the weave option for switching between 'msvc'\nand 'gcc' on windows. It may have use on Unix also, but I don't know yet.\n\n\n

              \nThe support_code argument is likely to be used a lot. It allows \nyou to specify extra code fragments such as function, structure or class \ndefinitions that you want to use in the code string. Note that \nchanges to support_code do not force a recompile. The \ncatalog only relies on code (for performance reasons) to determine \nwhether recompiling is necessary. So, if you make a change to support_code, \nyou'll need to alter code in some way or use the \nforce argument to get the code to recompile. I usually just add \nsome inocuous whitespace to the end of one of the lines in code \nsomewhere. Here's an example of defining a separate method for calculating\nthe string length:\n\n 

              \n    >>> from weave import inline\n    >>> a = 'a longer string'\n    >>> support_code = \"\"\"\n    ...                PyObject* length(Py::String a)\n    ...                {\n    ...                    int l = a.length();  \n    ...                    return Py::new_reference_to(Py::Int(l)); \n    ...                }\n    ...                \"\"\"        \n    >>> inline(\"return_val = length(a);\",['a'],\n    ...        support_code = support_code)\n    15\n
              \n

              \ncustomize is a left over from a previous way of specifying \ncompiler options. It is a custom_info object that can specify \nquite a bit of information about how a file is compiled. These \ninfo objects are the standard way of defining compile information \nfor type conversion classes. However, I don't think they are as handy here, \nespecially since we've exposed all the keyword arguments that distutils can \nhandle. Between these keywords, and the support_code option, I \nthink customize may be obsolete. We'll see if anyone cares to use \nit. If not, it'll get axed in the next version.\n

              \nThe type_factories variable is important to people who want to\ncustomize the way arguments are converted from Python to C. We'll talk about\nthis in the next chapter **xx** of this document when we discuss type\nconversions.\n

              \nauto_downcast handles one of the big type conversion issues that\nis common when using Numeric arrays in conjunction with Python scalar values.\nIf you have an array of single precision values and multiply that array by a \nPython scalar, the result is upcast to a double precision array because the\nscalar value is double precision. This is not usually the desired behavior\nbecause it can double your memory usage. auto_downcast goes\nsome distance towards changing the casting precedence of arrays and scalars.\nIf your only using single precision arrays, it will automatically downcast all\nscalar values from double to single precision when they are passed into the\nC++ code. This is the default behavior. If you want all values to keep there\ndefault type, set auto_downcast to 0.\n

              \n\n\n\n

              Returning Values

              \n\nPython variables in the local and global scope transfer seemlessly from Python \ninto the C++ snippets. And, if inline were to completely live up\nto its name, any modifications to variables in the C++ code would be reflected\nin the Python variables when control was passed back to Python. For example,\nthe desired behavior would be something like:\n\n 
              \n    # THIS DOES NOT WORK\n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    2\n
              \n\nInstead you get:\n\n 
              \n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    1\n
              \n \nVariables are passed into C++ as if you are calling a Python function. Python's \ncalling convention is sometimes called \"pass by assignment\". This means its as \nif a c_a = a assignment is made right before inline \ncall is made and the c_a variable is used within the C++ code. \nThus, any changes made to c_a are not reflected in Python's \na variable. Things do get a little more confusing, however, when \nlooking at variables with mutable types. Changes made in C++ to the contents \nof mutable types are reflected in the Python variables.\n\n 
              \n    >>> a= [1,2]\n    >>> weave.inline(\"PyList_SetItem(a.ptr(),0,PyInt_FromLong(3));\",['a'])\n    >>> print a\n    [3, 2]\n
              \n\nSo modifications to the contents of mutable types in C++ are seen when control\nis returned to Python. Modifications to immutable types such as tuples,\nstrings, and numbers do not alter the Python variables.\n\nIf you need to make changes to an immutable variable, you'll need to assign\nthe new value to the \"magic\" variable return_val in C++. This\nvalue is returned by the inline() function:\n\n 
              \n    >>> a = 1\n    >>> a = weave.inline(\"return_val = Py::new_reference_to(Py::Int(a+1));\",['a'])  \n    >>> a\n    2\n
              \n\nThe return_val variable can also be used to return newly created \nvalues. This is possible by returning a tuple. The following trivial example \nillustrates how this can be done:\n\n 
                     \n    # python version\n    def multi_return():\n        return 1, '2nd'\n    \n    # C version.\n    def c_multi_return():    \n        code =  \"\"\"\n     \t        Py::Tuple results(2);\n     \t        results[0] = Py::Int(1);\n     \t        results[1] = Py::String(\"2nd\");\n     \t        return_val = Py::new_reference_to(results); \t        \n                \"\"\"\n        return inline_tools.inline(code)\n
              \n

              \nThe example is available in examples/tuple_return.py. It also\nhas the dubious honor of demonstrating how much inline() can \nslow things down. The C version here is about 10 times slower than the Python\nversion. Of course, something so trivial has no reason to be written in\nC anyway.\n\n\n

              The issue with locals()

              \n

              \ninline passes the locals() and globals() \ndictionaries from Python into the C++ function from the calling function. It \nextracts the variables that are used in the C++ code from these dictionaries, \nconverts then to C++ variables, and then calculates using them. It seems like \nit would be trivial, then, after the calculations were finished to then insert \nthe new values back into the locals() and globals() \ndictionaries so that the modified values were reflected in Python. \nUnfortunately, as pointed out by the Python manual, the locals() dictionary is \nnot writable. \n

              \n\nI suspect locals() is not writable because there are some \noptimizations done to speed lookups of the local namespace. I'm guessing local \nlookups don't always look at a dictionary to find values. Can someone \"in the \nknow\" confirm or correct this? Another thing I'd like to know is whether there \nis a way to write to the local namespace of another stack frame from C/C++. If \nso, it would be possible to have some clean up code in compiled functions that \nwrote final values of variables in C++ back to the correct Python stack frame. \nI think this goes a long way toward making inline truely live up \nto its name. I don't think we'll get to the point of creating variables in \nPython for variables created in C -- although I suppose with a C/C++ parser you \ncould do that also.\n\n

              \n\n\n

              A quick look at the code

              \n\nweave generates a C++ file holding an extension function for \neach inline code snippet. These file names are generated using \nfrom the md5 signature of the code snippet and saved to a location specified by \nthe PYTHONCOMPILED environment variable (discussed later). The cpp files are \ngenerally about 200-400 lines long and include quite a few functions to support \ntype conversions, etc. However, the actual compiled function is pretty simple. \nBelow is the familiar printf example:\n\n 
              \n    >>> import weave    \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n\nAnd here is the extension function generated by inline:\n\n 
              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        // The Py_None needs an incref before returning\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n        \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try                              \n        {                                \n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n            /* Here is the inline code */            \n            printf(\"%d\\n\",a);\n            /* I would like to fill in changed locals and globals here... */\n        }                                       \n        catch( Py::Exception& e)           \n        {                                \n            return_val =  Py::Null();    \n            exception_occured = 1;       \n        }                                 \n        if(!return_val && !exception_occured)\n        {\n                                      \n            Py_INCREF(Py_None);              \n            return_val = Py_None;            \n        }\n        /* clean up code */\n        \n        /* return */                              \n        return return_val;           \n    }                                \n
              \n\nEvery inline function takes exactly two arguments -- the local and global\ndictionaries for the current scope. All variable values are looked up out\nof these dictionaries. The lookups, along with all inline code \nexecution, are done within a C++ try block. If the variables\naren't found, or there is an error converting a Python variable to the \nappropriate type in C++, an exception is raised. The C++ exception\nis automatically converted to a Python exception by CXX and returned to Python.\n\nThe py_to_int() function illustrates how the conversions and\nexception handling works. py_to_int first checks that the given PyObject*\npointer is not NULL and is a Python integer. If all is well, it calls the\nPython API to convert the value to an int. Otherwise, it calls\nhandle_bad_type() which gathers information about what went wrong\nand then raises a CXX TypeError which returns to Python as a TypeError.\n\n 
              \n    int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\n 
              \n    void handle_bad_type(PyObject* py_obj, char* good_type, char*  var_name)\n    {\n        char msg[500];\n        sprintf(msg,\"received '%s' type instead of '%s' for variable '%s'\",\n                find_type(py_obj),good_type,var_name);\n        throw Py::TypeError(msg);\n    }\n    \n    char* find_type(PyObject* py_obj)\n    {\n        if(py_obj == NULL) return \"C NULL value\";\n        if(PyCallable_Check(py_obj)) return \"callable\";\n        if(PyString_Check(py_obj)) return \"string\";\n        if(PyInt_Check(py_obj)) return \"int\";\n        if(PyFloat_Check(py_obj)) return \"float\";\n        if(PyDict_Check(py_obj)) return \"dict\";\n        if(PyList_Check(py_obj)) return \"list\";\n        if(PyTuple_Check(py_obj)) return \"tuple\";\n        if(PyFile_Check(py_obj)) return \"file\";\n        if(PyModule_Check(py_obj)) return \"module\";\n        \n        //should probably do more interagation (and thinking) on these.\n        if(PyCallable_Check(py_obj) && PyInstance_Check(py_obj)) return \"callable\";\n        if(PyInstance_Check(py_obj)) return \"instance\"; \n        if(PyCallable_Check(py_obj)) return \"callable\";\n        return \"unkown type\";\n    }\n
              \n\nSince the inline is also executed within the try/catch\nblock, you can use CXX exceptions within your code. It is usually a bad idea\nto directly return from your code, even if an error occurs. This\nskips the clean up section of the extension function. In this simple example,\nthere isn't any clean up code, but in more complicated examples, there may\nbe some reference counting that needs to be taken care of here on converted\nvariables. To avoid this, either uses exceptions or set \nreturn_val to NULL and use if/then's to skip code\nafter errors.\n\n\n

              Technical Details

              \n

              \nThere are \n

                \n
              1. Type conversion \n
              2. Generating C/C++ code \n
              3. Compile the code to an extension module \n
              4. Catalog (and cache) the function for future use
                5. \n
              \n

              \nItems 1 and 2 above are related, but most easily discussed separately. Type \nconversions are customizable by the user if needed. Understanding them is \npretty important for anything beyond trivial uses of inline. \nGenerating the C/C++ code is handled by ext_function and \next_module classes and . For the most part, compiling the code is \nhandled by distutils. Some customizations were needed, but they were \nrelatively minor and do not require changes to distutils itself. Cataloging is \npretty simple in concept, but surprisingly required the most code to implement \n(and still likely needs some work). So, this section covers items 1 and 4 from \nthe list. Item 2 is covered later in the chapter covering the \next_tools module, and distutils is covered by a completely \nseparate document xxx.\n\n

              Passing Variables in/out of the C/C++ code

              \n\nNote: Passing variables into the C code is pretty straight forward, but there \nare subtlties to how variable modifications in C are returned to Python. see Returning Values for a more thorough discussion of \nthis issue.\n \n \n\n

              Type Conversions

              \n\n\nNote: Maybe xxx_converter instead of \nxxx_specification is a more descriptive name. Might change in \nfuture version?\n\n\n

              \nBy default, inline() makes the following type conversions between\nPython and C++ types.\n

              \n\n

              \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
              \n

              Default Data Type Conversions

              \n

              Python

              		\n

              C++

                 int   int
                 float   double
                 complex   std::complex
                 string   Py::String
                 list   Py::List
                 dict   Py::Dict
                 tuple   Py::Tuple
                 file   FILE*
                 callable   PyObject*
                 instance   PyObject*
                 Numeric.array   PyArrayObject*
                 wxXXX   wxXXX*
              \n
              \n

              \nThe Py:: namespace is defined by the \nCXX library which has C++ class\nequivalents for many Python types. std:: is the namespace of the\nstandard library in C++.\n

              \n\nNote: \n

                \n
              • I haven't figured out how to handle long int yet (I think they are currenlty converted \n to int - - check this). \n \n
              • \nHopefully VTK will be added to the list soon
                • \n
              \n\n

              \n\nPython to C++ conversions fill in code in several locations in the generated\ninline extension function. Below is the basic template for the\nfunction. This is actually the exact code that is generated by calling\nweave.inline(\"\").\n\n 

              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n    \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try\n        {\n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            /* argument conversion code */\n            /* inline code */\n            /*I would like to fill in changed locals and globals here...*/\n    \n        }\n        catch( Py::Exception& e)\n        {\n            return_val =  Py::Null();\n            exception_occured = 1;\n        }\n        /* cleanup code */\n        if(!return_val && !exception_occured)\n        {\n    \n            Py_INCREF(Py_None);\n            return_val = Py_None;\n        }\n    \n        return return_val;\n    }\n
              \n\nThe /* inline code */ section is filled with the code passed to\nthe inline() function call. The \n/*argument convserion code*/ and /* cleanup code */\nsections are filled with code that handles conversion from Python to C++\ntypes and code that deallocates memory or manipulates reference counts before\nthe function returns. The following sections demostrate how these two areas\nare filled in by the default conversion methods.\n\n \nNote: I'm not sure I have reference counting correct on a few of these. The \nonly thing I increase/decrease the ref count on is Numeric arrays. If you\nsee an issue, please let me know.\n\n\n\n

              Numeric Argument Conversion

              \n\nInteger, floating point, and complex arguments are handled in a very similar\nfashion. Consider the following inline function that has a single integer \nvariable passed in:\n\n 
              \n    >>> a = 1\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_int() has the following\nform:\n\n 
              \n    static int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\nSimilarly, the float and complex conversion routines look like:\n\n 
                  \n    static double py_to_float(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyFloat_Check(py_obj))\n            handle_bad_type(py_obj,\"float\", name);\n        return PyFloat_AsDouble(py_obj);\n    }\n    \n    static std::complex py_to_complex(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyComplex_Check(py_obj))\n            handle_bad_type(py_obj,\"complex\", name);\n        return std::complex(PyComplex_RealAsDouble(py_obj),\n                                    PyComplex_ImagAsDouble(py_obj));    \n    }\n
              \n\nNumeric conversions do not require any clean up code.\n\n\n

              String, List, Tuple, and Dictionary Conversion

              \n\nStrings, Lists, Tuples and Dictionary conversions are all converted to \nCXX types by default.\n\nFor the following code, \n\n 
              \n    >>> a = [1]\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    Py::List a = py_to_list (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_list() and its\nfriends has the following form:\n\n 
                  \n    static Py::List py_to_list(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyList_Check(py_obj))\n            handle_bad_type(py_obj,\"list\", name);\n        return Py::List(py_obj);\n    }\n    \n    static Py::String py_to_string(PyObject* py_obj,char* name)\n    {\n        if (!PyString_Check(py_obj))\n            handle_bad_type(py_obj,\"string\", name);\n        return Py::String(py_obj);\n    }\n\n    static Py::Dict py_to_dict(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyDict_Check(py_obj))\n            handle_bad_type(py_obj,\"dict\", name);\n        return Py::Dict(py_obj);\n    }\n    \n    static Py::Tuple py_to_tuple(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyTuple_Check(py_obj))\n            handle_bad_type(py_obj,\"tuple\", name);\n        return Py::Tuple(py_obj);\n    }\n
              \n\nCXX handles reference counts on for strings, lists, tuples, and dictionaries,\nso clean up code isn't necessary.\n\n\n

              File Conversion

              \n\nFor the following code, \n\n 
              \n    >>> a = open(\"bob\",'w')  \n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code is:\n\n 
              \n    /* argument conversion code */\n    PyObject* py_a = get_variable(\"a\",raw_locals,raw_globals);\n    FILE* a = py_to_file(py_a,\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_file() converts\nPyObject* to a FILE* and increments the reference count of the PyObject*:\n\n 
              \n    FILE* py_to_file(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"file\", name);\n    \n        Py_INCREF(py_obj);\n        return PyFile_AsFile(py_obj);\n    }\n
              \n\nBecause the PyObject* was incremented, the clean up code needs to decrement\nthe counter\n\n 
              \n    /* cleanup code */\n    Py_XDECREF(py_a);\n
              \n\nIts important to understand that file conversion only works on actual files --\ni.e. ones created using the open() command in Python. It does\nnot support converting arbitrary objects that support the file interface into\nC FILE* pointers. This can affect many things. For example, in\ninitial printf() examples, one might be tempted to solve the \nproblem of C and Python IDE's (PythonWin, PyCrust, etc.) writing to different\nstdout and stderr by using fprintf() and passing in \nsys.stdout and sys.stderr. For example, instead of\n\n 
              \n    >>> weave.inline('printf(\"hello\\\\n\");')\n
              \n \nYou might try:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n
              \n\nThis will work as expected from a standard python interpreter, but in PythonWin,\nthe following occurs:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n    Traceback (most recent call last):\n        File \"\", line 1, in ?\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 315, in inline\n            auto_downcast = auto_downcast,\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 386, in compile_function\n            type_factories = type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 197, in __init__\n            auto_downcast, type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 390, in assign_variable_types\n            raise TypeError, format_error_msg(errors)\n        TypeError: {'buf': \"Unable to convert variable 'buf' to a C++ type.\"}\n
              \n\nThe traceback tells us that inline() was unable to convert 'buf' to a\nC++ type (If instance conversion was implemented, the error would have occurred at \nruntime instead). Why is this? Let's look at what the buf object \nreally is:\n\n 
              \n    >>> buf\n    pywin.framework.interact.InteractiveView instance at 00EAD014\n
              \n\nPythonWin has reassigned sys.stdout to a special object that \nimplements the Python file interface. This works great in Python, but since \nthe special object doesn't have a FILE* pointer underlying it, fprintf doesn't \nknow what to do with it (well this will be the problem when instance conversion \nis implemented...).\n\n\n

              Callable, Instance, and Module Conversion

              \n\nNote: Need to look into how ref counts should be handled. Also,\nInstance and Module conversion are not currently implemented.\n\n\n 
              \n    >>> def a(): \n        pass\n    >>> inline(\"\",['a'])\n
              \n\nCallable and instance variables are converted to PyObject*. Nothing is done\nto there reference counts.\n\n 
              \n    /* argument conversion code */\n    PyObject* a = py_to_callable(get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. The py_to_callable() and\npy_to_instance() don't currently increment the ref count.\n\n 
                  \n    PyObject* py_to_callable(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyCallable_Check(py_obj))\n            handle_bad_type(py_obj,\"callable\", name);    \n        return py_obj;\n    }\n\n    PyObject* py_to_instance(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"instance\", name);    \n        return py_obj;\n    }\n
              \n \nThere is no cleanup code for callables, modules, or instances.\n\n\n

              Customizing Conversions

              \n

              \nConverting from Python to C++ types is handled by xxx_specification classes. A \ntype specification class actually serve in two related but different \nroles. The first is in determining whether a Python variable that needs to be \nconverted should be represented by the given class. The second is as a code \ngenerator that generate C++ code needed to convert from Python to C++ types for \na specific variable.\n

              \nWhen \n\n 

              \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\",a);',['a'])\n
              \n \nis called for the first time, the code snippet has to be compiled. In this \nprocess, the variable 'a' is tested against a list of type specifications (the \ndefault list is stored in weave/ext_tools.py). The first \nspecification in the list is used to represent the variable. \n\n

              \nExamples of xxx_specification are scattered throughout numerous \n\"xxx_spec.py\" files in the weave package. Closely related to \nthe xxx_specification classes are yyy_info classes. \nThese classes contain compiler, header, and support code information necessary \nfor including a certain set of capabilities (such as blitz++ or CXX support)\nin a compiled module. xxx_specification classes have one or more\nyyy_info classes associated with them.\n\nIf you'd like to define your own set of type specifications, the current best route\nis to examine some of the existing spec and info files. Maybe looking over\nsequence_spec.py and cxx_info.py are a good place to start. After defining \nspecification classes, you'll need to pass them into inline using the \ntype_factories argument. \n\nA lot of times you may just want to change how a specific variable type is \nrepresented. Say you'd rather have Python strings converted to \nstd::string or maybe char* instead of using the CXX \nstring object, but would like all other type conversions to have default \nbehavior. This requires that a new specification class that handles strings\nis written and then prepended to a list of the default type specifications. Since\nit is closer to the front of the list, it effectively overrides the default\nstring specification.\n\nThe following code demonstrates how this is done:\n\n...\n\n\n

              The Catalog

              \n

              \ncatalog.py has a class called catalog that helps keep \ntrack of previously compiled functions. This prevents inline() \nand related functions from having to compile functions everytime they are \ncalled. Instead, catalog will check an in memory cache to see if the function \nhas already been loaded into python. If it hasn't, then it starts searching \nthrough persisent catalogs on disk to see if it finds an entry for the given \nfunction. By saving information about compiled functions to disk, it isn't\nnecessary to re-compile functions everytime you stop and restart the interpreter.\nFunctions are compiled once and stored for future use.\n\n

              \nWhen inline(cpp_code) is called the following things happen:\n

                \n
              1. \n A fast local cache of functions is checked for the last function called for \n cpp_code. If an entry for cpp_code doesn't exist in the \n cache or the cached function call fails (perhaps because the function doesn't \n have compatible types) then the next step is to check the catalog. \n
              2. \n The catalog class also keeps an in-memory cache with a list of all the \n functions compiled for cpp_code. If cpp_code has\n ever been called, then this cache will be present (loaded from disk). If\n the cache isn't present, then it is loaded from disk.\n

                \n If the cache is present, each function in the cache is \n called until one is found that was compiled for the correct argument types. If \n none of the functions work, a new function is compiled with the given argument \n types. This function is written to the on-disk catalog as well as into the \n in-memory cache.

                \n
              3. \n When a lookup for cpp_code fails, the catalog looks through \n the on-disk function catalogs for the entries. The PYTHONCOMPILED variable \n determines where to search for these catalogs and in what order. If \n PYTHONCOMPILED is not present several platform dependent locations are \n searched. All functions found for cpp_code in the path are \n loaded into the in-memory cache with functions found earlier in the search \n path closer to the front of the call list.\n

                \n If the function isn't found in the on-disk catalog, \n then the function is compiled, written to the first writable directory in the \n PYTHONCOMPILED path, and also loaded into the in-memory cache.

                \n
                4. \n
              \n\n\n

              Function Storage: How functions are stored in caches and on disk

              \n

              \nFunction caches are stored as dictionaries where the key is the entire C++\ncode string and the value is either a single function (as in the \"level 1\"\ncache) or a list of functions (as in the main catalog cache). On disk\ncatalogs are stored in the same manor using standard Python shelves.\n

              \nEarly on, there was a question as to whether md5 check sums of the C++\ncode strings should be used instead of the actual code strings. I think this\nis the route inline Perl took. Some (admittedly quick) tests of the md5 vs.\nthe entire string showed that using the entire string was at least a\nfactor of 3 or 4 faster for Python. I think this is because it is more\ntime consuming to compute the md5 value than it is to do look-ups of long\nstrings in the dictionary. Look at the examples/md5_speed.py file for the\ntest run. \n\n\n

              Catalog search paths and the PYTHONCOMPILED variable

              \n

              \nThe default location for catalog files on Unix is is ~/.pythonXX_compiled where \nXX is version of Python being used. If this directory doesn't exist, it is \ncreated the first time a catalog is used. The directory must be writable. If, \nfor any reason it isn't, then the catalog attempts to create a directory based \non your user id in the /tmp directory. The directory permissions are set so \nthat only you have access to the directory. If this fails, I think you're out of \nluck. I don't think either of these should ever fail though. On Windows, a \ndirectory called pythonXX_compiled is created in the user's temporary \ndirectory. \n

              \nThe actual catalog file that lives in this directory is a Python shelve with\na platform specific name such as \"nt21compiled_catalog\" so that multiple OSes\ncan share the same file systems without trampling on each other. Along with\nthe catalog file, the .cpp and .so or .pyd files created by inline will live\nin this directory. The catalog file simply contains keys which are the C++\ncode strings with values that are lists of functions. The function lists point\nat functions within these compiled modules. Each function in the lists \nexecutes the same C++ code string, but compiled for different input variables.\n

              \nYou can use the PYTHONCOMPILED environment variable to specify alternative\nlocations for compiled functions. On Unix this is a colon (':') separated\nlist of directories. On windows, it is a (';') separated list of directories.\nThese directories will be searched prior to the default directory for a\ncompiled function catalog. Also, the first writable directory in the list\nis where all new compiled function catalogs, .cpp and .so or .pyd files are\nwritten. Relative directory paths ('.' and '..') should work fine in the\nPYTHONCOMPILED variable as should environement variables.\n

              \nThere is a \"special\" path variable called MODULE that can be placed in the \nPYTHONCOMPILED variable. It specifies that the compiled catalog should\nreside in the same directory as the module that called it. This is useful\nif an admin wants to build a lot of compiled functions during the build\nof a package and then install them in site-packages along with the package.\nUser's who specify MODULE in their PYTHONCOMPILED variable will have access\nto these compiled functions. Note, however, that if they call the function\nwith a set of argument types that it hasn't previously been built for, the\nnew function will be stored in their default directory (or some other writable\ndirectory in the PYTHONCOMPILED path) because the user will not have write\naccess to the site-packages directory.\n

              \nAn example of using the PYTHONCOMPILED path on bash follows:\n\n 

              \n    PYTHONCOMPILED=MODULE:/some/path;export PYTHONCOMPILED;\n
              \n\nIf you are using python21 on linux, and the module bob.py in site-packages\nhas a compiled function in it, then the catalog search order when calling that\nfunction for the first time in a python session would be:\n\n 
              \n    /usr/lib/python21/site-packages/linuxpython_compiled\n    /some/path/linuxpython_compiled\n    ~/.python21_compiled/linuxpython_compiled\n
              \n\nThe default location is always included in the search path.\n

              \n \nNote: hmmm. see a possible problem here. I should probably make a sub-\ndirectory such as /usr/lib/python21/site-\npackages/python21_compiled/linuxpython_compiled so that library files compiled \nwith python21 are tried to link with python22 files in some strange scenarios. \nNeed to check this.\n\n\n

              \nThe in-module cache (in weave.inline_tools reduces the overhead \nof calling inline functions by about a factor of 2. It can be reduced a little \nmore for type loop calls where the same function is called over and over again \nif the cache was a single value instead of a dictionary, but the benefit is \nvery small (less than 5%) and the utility is quite a bit less. So, we'll stick \nwith a dictionary as the cache.\n

              \n\n\n

              Blitz

              \n Note: most of this section is lifted from old documentation. It should be\npretty accurate, but there may be a few discrepancies.\n

              \nweave.blitz() compiles Numeric Python expressions for fast \nexecution. For most applications, compiled expressions should provide a \nfactor of 2-10 speed-up over Numeric arrays. Using compiled \nexpressions is meant to be as unobtrusive as possible and works much like \npythons exec statement. As an example, the following code fragment takes a 5 \npoint average of the 512x512 2d image, b, and stores it in array, a:\n\n 

              \n    from scipy import *  # or from Numeric import *\n    a = ones((512,512), Float64) \n    b = ones((512,512), Float64) \n    # ...do some stuff to fill in b...\n    # now average\n    a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] \\\n                   + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n
              \n \nTo compile the expression, convert the expression to a string by putting\nquotes around it and then use weave.blitz:\n\n 
              \n    import weave\n    expr = \"a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n                          \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n    weave.blitz(expr)\n
              \n\nThe first time weave.blitz is run for a given expression and \nset of arguements, C++ code that accomplishes the exact same task as the Python \nexpression is generated and compiled to an extension module. This can take up \nto a couple of minutes depending on the complexity of the function. Subsequent \ncalls to the function are very fast. Futher, the generated module is saved \nbetween program executions so that the compilation is only done once for a \ngiven expression and associated set of array types. If the given expression\nis executed with a new set of array types, the code most be compiled again. This\ndoes not overwrite the previously compiled function -- both of them are saved and\navailable for exectution. \n

              \nThe following table compares the run times for standard Numeric code and \ncompiled code for the 5 point averaging.\n

              \n

              \n\n\n\n\n\n
              Method Run Time (seconds)
              Standard Numeric 0.46349
              blitz (1st time compiling) 78.95526
              blitz (subsequent calls) 0.05843 (factor of 8 speedup)
              \n
              \n

              \nThese numbers are for a 512x512 double precision image run on a 400 MHz Celeron \nprocessor under RedHat Linux 6.2.\n

              \nBecause of the slow compile times, its probably most effective to develop \nalgorithms as you usually do using the capabilities of scipy or the Numeric \nmodule. Once the algorithm is perfected, put quotes around it and execute it \nusing weave.blitz. This provides the standard rapid \nprototyping strengths of Python and results in algorithms that run close to \nthat of hand coded C or Fortran.\n\n\n

              Requirements

              \n\nCurrently, the weave.blitz has only been tested under Linux \nwith gcc-2.95-3 and on Windows with Mingw32 (2.95.2). Its compiler \nrequirements are pretty heavy duty (see the \nblitz++ home page), so it won't \nwork with just any compiler. Particularly MSVC++ isn't up to snuff. A number \nof other compilers such as KAI++ will also work, but my suspicions are that gcc \nwill get the most use.\n\n\n

              Limitations

              \n
                \n
              1. \nCurrently, weave.blitz handles all standard mathematic \noperators except for the ** power operator. The built-in trigonmetric, log, \nfloor/ceil, and fabs functions might work (but haven't been tested). It also \nhandles all types of array indexing supported by the Numeric module. \n

                \nweave.blitz does not currently support operations that use \narray broadcasting, nor have any of the special purpose functions in Numeric \nsuch as take, compress, etc. been implemented. Note that there are no obvious \nreasons why most of this functionality cannot be added to scipy.weave, so it \nwill likely trickle into future versions. Using slice() objects \ndirectly instead of start:stop:step is also not supported.\n

                2. \n
              2. \nCurrently Python only works on expressions that include assignment such as\n \n 
                \n    >>> result = b + c + d\n
                \n\nThis means that the result array must exist before calling \nweave.blitz. Future versions will allow the following:\n\n 
                \n    >>> result = weave.blitz_eval(\"b + c + d\")\n
                \n
                3. \n
              3. \nweave.blitz works best when algorithms can be expressed in a \n\"vectorized\" form. Algorithms that have a large number of if/thens and other \nconditions are better hand written in C or Fortran. Further, the restrictions \nimposed by requiring vectorized expressions sometimes preclude the use of more \nefficient data structures or algorithms. For maximum speed in these cases, \nhand-coded C or Fortran code is the only way to go.\n
                4. \n
              4. \nOne other point deserves mention lest people be confused. \nweave.blitz is not a general purpose Python->C compiler. It \nonly works for expressions that contain Numeric arrays and/or \nPython scalar values. This focused scope concentrates effort on the \ncompuationally intensive regions of the program and sidesteps the difficult \nissues associated with a general purpose Python->C compiler.\n
                5. \n
              \n\n\n

              Numeric efficiency issues: What compilation buys you

              \n\nSome might wonder why compiling Numeric expressions to C++ is beneficial since \noperations on Numeric array operations are already executed within C loops. \nThe problem is that anything other than the simplest expression are executed in \nless than optimal fashion. Consider the following Numeric expression:\n\n 
              \n    a = 1.2 * b + c * d\n
              \n \nWhen Numeric calculates the value for the 2d array, a, it does \nthe following steps:\n\n 
              \n    temp1 = 1.2 * b\n    temp2 = c * d\n    a = temp1 + temp2\n
              \n \nTwo things to note. Since c is an (perhaps large) array, a large \ntemporary array must be created to store the results of 1.2 * b. \nThe same is true for temp2. Allocation is slow. The second thing \nis that we have 3 loops executing, one to calculate temp1, one for \ntemp2 and one for adding them up. A C loop for the same problem \nmight look like:\n\n 
              \n    for(int i = 0; i < M; i++)\n        for(int j = 0; j < N; j++)\n            a[i,j] = 1.2 * b[i,j] + c[i,j] * d[i,j]\n
              \n \nHere, the 3 loops have been fused into a single loop and there is no longer\na need for a temporary array. This provides a significant speed improvement\nover the above example (write me and tell me what you get). \n

              \nSo, converting Numeric expressions into C/C++ loops that fuse the loops and \neliminate temporary arrays can provide big gains. The goal then,is to convert \nNumeric expression to C/C++ loops, compile them in an extension module, and \nthen call the compiled extension function. The good news is that there is an \nobvious correspondence between the Numeric expression above and the C loop. The \nbad news is that Numeric is generally much more powerful than this simple \nexample illustrates and handling all possible indexing possibilities results in \nloops that are less than straight forward to write. (take a peak in Numeric for \nconfirmation). Luckily, there are several available tools that simplify the \nprocess.\n\n\n

              The Tools

              \n\nweave.blitz relies heavily on several remarkable tools. On the \nPython side, the main facilitators are Jermey Hylton's parser module and Jim \nHuginin's Numeric module. On the compiled language side, Todd Veldhuizen's \nblitz++ array library, written in C++ (shhhh. don't tell David Beazley), does \nthe heavy lifting. Don't assume that, because it's C++, it's much slower than C \nor Fortran. Blitz++ uses a jaw dropping array of template techniques \n(metaprogramming, template expression, etc) to convert innocent looking and \nreadable C++ expressions into to code that usually executes within a few \npercentage points of Fortran code for the same problem. This is good. \nUnfortunately all the template raz-ma-taz is very expensive to compile, so the \n200 line extension modules often take 2 or more minutes to compile. This isn't so \ngood. weave.blitz works to minimize this issue by remembering \nwhere compiled modules live and reusing them instead of re-compiling every time \na program is re-run.\n\n\n

              Parser

              \nTearing Numeric expressions apart, examining the pieces, and then rebuilding \nthem as C++ (blitz) expressions requires a parser of some sort. I can imagine \nsomeone attacking this problem with regular expressions, but it'd likely be \nugly and fragile. Amazingly, Python solves this problem for us. It actually \nexposes its parsing engine to the world through the parser module. \nThe following fragment creates an Abstract Syntax Tree (AST) object for the \nexpression and then converts to a (rather unpleasant looking) deeply nested list \nrepresentation of the tree. \n \n 
              \n    >>> import parser\n    >>> import scipy.weave.misc\n    >>> ast = parser.suite(\"a = b * c + d\")\n    >>> ast_list = ast.tolist()\n    >>> sym_list = scipy.weave.misc.translate_symbols(ast_list)\n    >>> pprint.pprint(sym_list)\n    ['file_input',\n     ['stmt',\n      ['simple_stmt',\n       ['small_stmt',\n        ['expr_stmt',\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'a']]]]]]]]]]]]]]],\n         ['EQUAL', '='],\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'b']]]],\n                    ['STAR', '*'],\n                    ['factor', ['power', ['atom', ['NAME', 'c']]]]],\n                   ['PLUS', '+'],\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'd']]]]]]]]]]]]]]]]],\n       ['NEWLINE', '']]],\n     ['ENDMARKER', '']]\n
              \n\nDespite its looks, with some tools developed by Jermey H., its possible\nto search these trees for specific patterns (sub-trees), extract the \nsub-tree, manipulate them converting python specific code fragments\nto blitz code fragments, and then re-insert it in the parse tree. The parser\nmodule documentation has some details on how to do this. Traversing the \nnew blitzified tree, writing out the terminal symbols as you go, creates\nour new blitz++ expression string.\n\n \n

              Blitz and Numeric

              \nThe other nice discovery in the project is that the data structure used\nfor Numeric arrays and blitz arrays is nearly identical. Numeric stores\n\"strides\" as byte offsets and blitz stores them as element offsets, but\nother than that, they are the same. Further, most of the concept and\ncapabilities of the two libraries are remarkably similar. It is satisfying \nthat two completely different implementations solved the problem with \nsimilar basic architectures. It is also fortitous. The work involved in \nconverting Numeric expressions to blitz expressions was greatly diminished.\nAs an example, consider the code for slicing an array in Python with a\nstride:\n\n 
              \n    >>> a = b[0:4:2] + c\n    >>> a\n    [0,2,4]\n
              \n\n\nIn Blitz it is as follows:\n\n 
              \n    Array<2,int> b(10);\n    Array<2,int> c(3);\n    // ...\n    Array<2,int> a = b(Range(0,3,2)) + c;\n
              \n\n\nHere the range object works exactly like Python slice objects with the exception\nthat the top index (3) is inclusive where as Python's (4) is exclusive. Other \ndifferences include the type declaraions in C++ and parentheses instead of \nbrackets for indexing arrays. Currently, weave.blitz handles the \ninclusive/exclusive issue by subtracting one from upper indices during the\ntranslation. An alternative that is likely more robust/maintainable in the \nlong run, is to write a PyRange class that behaves like Python's range. \nThis is likely very easy.\n

              \nThe stock blitz also doesn't handle negative indices in ranges. The current \nimplementation of the blitz() has a partial solution to this \nproblem. It calculates and index that starts with a '-' sign by subtracting it \nfrom the maximum index in the array so that:\n\n 

              \n                    upper index limit\n                        /-----\\\n    b[:-1] -> b(Range(0,Nb[0]-1-1))\n
              \n\nThis approach fails, however, when the top index is calculated from other \nvalues. In the following scenario, if i+j evaluates to a negative \nvalue, the compiled code will produce incorrect results and could even core-\ndump. Right now, all calculated indices are assumed to be positive.\n \n 
              \n    b[:i-j] -> b(Range(0,i+j))\n
              \n\nA solution is to calculate all indices up front using if/then to handle the\n+/- cases. This is a little work and results in more code, so it hasn't been\ndone. I'm holding out to see if blitz++ can be modified to handle negative\nindexing, but haven't looked into how much effort is involved yet. While it \nneeds fixin', I don't think there is a ton of code where this is an issue.\n

              \nThe actual translation of the Python expressions to blitz expressions is \ncurrently a two part process. First, all x:y:z slicing expression are removed\nfrom the AST, converted to slice(x,y,z) and re-inserted into the tree. Any\nmath needed on these expressions (subtracting from the \nmaximum index, etc.) are also preformed here. _beg and _end are used as special\nvariables that are defined as blitz::fromBegin and blitz::toEnd.\n\n 

              \n    a[i+j:i+j+1,:] = b[2:3,:] \n
              \n\nbecomes a more verbose:\n \n 
              \n    a[slice(i+j,i+j+1),slice(_beg,_end)] = b[slice(2,3),slice(_beg,_end)]\n
              \n \nThe second part does a simple string search/replace to convert to a blitz \nexpression with the following translations:\n\n 
              \n    slice(_beg,_end) -> _all  # not strictly needed, but cuts down on code.\n    slice            -> blitz::Range\n    [                -> (\n    ]                -> )\n    _stp             -> 1\n
              \n\n_all is defined in the compiled function as \nblitz::Range.all(). These translations could of course happen \ndirectly in the syntax tree. But the string replacement is slightly easier. \nNote that name spaces are maintained in the C++ code to lessen the likelyhood \nof name clashes. Currently no effort is made to detect name clashes. A good \nrule of thumb is don't use values that start with '_' or 'py_' in compiled \nexpressions and you'll be fine.\n\n \n

              Type definitions and coersion

              \n\nSo far we've glossed over the dynamic vs. static typing issue between Python \nand C++. In Python, the type of value that a variable holds can change\nthrough the course of program execution. C/C++, on the other hand, forces you\nto declare the type of value a variables will hold prior at compile time.\nweave.blitz handles this issue by examining the types of the\nvariables in the expression being executed, and compiling a function for those\nexplicit types. For example:\n\n 
              \n    a = ones((5,5),Float32)\n    b = ones((5,5),Float32)\n    weave.blitz(\"a = a + b\")\n
              \n\nWhen compiling this expression to C++, weave.blitz sees that the\nvalues for a and b in the local scope have type Float32, or 'float'\non a 32 bit architecture. As a result, it compiles the function using \nthe float type (no attempt has been made to deal with 64 bit issues).\nIt also goes one step further. If all arrays have the same type, a templated\nversion of the function is made and instantiated for float, double, \ncomplex, and complex arrays. Note: This feature has been \nremoved from the current version of the code. Each version will be compiled\nseparately \n

              \nWhat happens if you call a compiled function with array types that are \ndifferent than the ones for which it was originally compiled? No biggie, you'll \njust have to wait on it to compile a new version for your new types. This \ndoesn't overwrite the old functions, as they are still accessible. See the \ncatalog section in the inline() documentation to see how this is handled. \nSuffice to say, the mechanism is transparent to the user and behaves \nlike dynamic typing with the occasional wait for compiling newly typed \nfunctions.\n

              \nWhen working with combined scalar/array operations, the type of the array is \nalways used. This is similar to the savespace flag that was recently \nadded to Numeric. This prevents issues with the following expression perhaps \nunexpectedly being calculated at a higher (more expensive) precision that can \noccur in Python:\n\n 

              \n    >>> a = array((1,2,3),typecode = Float32)\n    >>> b = a * 2.1 # results in b being a Float64 array.\n
              \n \nIn this example, \n\n 
              \n    >>> a = ones((5,5),Float32)\n    >>> b = ones((5,5),Float32)\n    >>> weave.blitz(\"b = a * 2.1\")\n
              \n \nthe 2.1 is cast down to a float before carrying out \nthe operation. If you really want to force the calculation to be a \ndouble, define a and b as \ndouble arrays.\n

              \nOne other point of note. Currently, you must include both the right hand side \nand left hand side (assignment side) of your equation in the compiled \nexpression. Also, the array being assigned to must be created prior to calling \nweave.blitz. I'm pretty sure this is easily changed so that a \ncompiled_eval expression can be defined, but no effort has been made to \nallocate new arrays (and decern their type) on the fly.\n\n \n

              Cataloging Compiled Functions

              \n\nSee the Cataloging functions section in the \nweave.inline() documentation.\n\n \n

              Checking Array Sizes

              \n\nSurprisingly, one of the big initial problems with compiled code was making\nsure all the arrays in an operation were of compatible type. The following\ncase, is of course, trivially easy:\n\n 
              \n    a = b + c\n
              \n \nIt only requires that arrays a, b, and c \nhave the same shape. However, expressions like:\n\n 
              \n    a[i+j:i+j+1,:] = b[2:3,:] + c\n
              \n\nare not so trivial. Since slicing is involved, the size of the slices, not the \ninput arrays must be checked. Broadcasting complicates things further because \narrays and slices with different dimensions and shapes may be compatible for \nmath operations (broadcasting isn't yet supported by \nweave.blitz). Reductions have a similar effect as their \nresults are different shapes than their input operand. The binary operators in \nNumeric compare the shapes of their two operands just before they operate on \nthem. This is possible because Numeric treats each operation independently. \nThe intermediate (temporary) arrays created during sub-operations in an \nexpression are tested for the correct shape before they are combined by another \noperation. Because weave.blitz fuses all operations into a \nsingle loop, this isn't possible. The shape comparisons must be done and \nguaranteed compatible before evaluating the expression.\n

              \nThe solution chosen converts input arrays to \"dummy arrays\" that only represent \nthe dimensions of the arrays, not the data. Binary operations on dummy arrays \ncheck that input array sizes are comptible and return a dummy array with the \nsize correct size. Evaluating an expression of dummy arrays traces the \nchanging array sizes through all operations and fails if incompatible array \nsizes are ever found. \n

              \nThe machinery for this is housed in weave.size_check. It \nbasically involves writing a new class (dummy array) and overloading it math \noperators to calculate the new sizes correctly. All the code is in Python and \nthere is a fair amount of logic (mainly to handle indexing and slicing) so the \noperation does impose some overhead. For large arrays (ie. 50x50x50), the \noverhead is negligible compared to evaluating the actual expression. For small \narrays (ie. 16x16), the overhead imposed for checking the shapes with this \nmethod can cause the weave.blitz to be slower than evaluating \nthe expression in Python. \n

              \nWhat can be done to reduce the overhead? (1) The size checking code could be \nmoved into C. This would likely remove most of the overhead penalty compared \nto Numeric (although there is also some calling overhead), but no effort has \nbeen made to do this. (2) You can also call weave.blitz with\ncheck_size=0 and the size checking isn't done. However, if the \nsizes aren't compatible, it can cause a core-dump. So, foregoing size_checking\nisn't advisable until your code is well debugged.\n\n \n

              Creating the Extension Module

              \n\nweave.blitz uses the same machinery as \nweave.inline to build the extension module. The only difference\nis the code included in the function is automatically generated from the\nNumeric array expression instead of supplied by the user.\n\n\n

              Extension Modules

              \nweave.inline and weave.blitz are high level tools\nthat generate extension modules automatically. Under the covers, they use several\nclasses from weave.ext_tools to help generate the extension module.\nThe main two classes are ext_module and ext_function (I'd\nlike to add ext_class and ext_method also). These classes\nsimplify the process of generating extension modules by handling most of the \"boiler\nplate\" code automatically.\n\n\nNote: inline actually sub-classes weave.ext_tools.ext_function \nto generate slightly different code than the standard ext_function.\nThe main difference is that the standard class converts function arguments to\nC types, while inline always has two arguments, the local and global dicts, and\nthe grabs the variables that need to be convereted to C from these.\n\n\n\n

              A Simple Example

              \nThe following simple example demonstrates how to build an extension module within\na Python function:\n\n 
              \n    # examples/increment_example.py\n    from weave import ext_tools\n    \n    def build_increment_ext():\n        \"\"\" Build a simple extension with functions that increment numbers.\n            The extension will be built in the local directory.\n        \"\"\"        \n        mod = ext_tools.ext_module('increment_ext')\n    \n        a = 1 # effectively a type declaration for 'a' in the \n              # following functions.\n    \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n        mod.add_function(func)\n        \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+2));\"    \n        func = ext_tools.ext_function('increment_by_2',ext_code,['a'])\n        mod.add_function(func)\n                \n        mod.compile()\n
              \n\n\nThe function build_increment_ext() creates an extension module \nnamed increment_ext and compiles it to a shared library (.so or \n.pyd) that can be loaded into Python.. increment_ext contains two \nfunctions, increment and increment_by_2. \n\nThe first line of build_increment_ext(),\n\n 
              \n        mod = ext_tools.ext_module('increment_ext') \n
              \n\ncreates an ext_module instance that is ready to have \next_function instances added to it. ext_function \ninstances are created much with a calling convention similar to \nweave.inline(). The most common call includes a C/C++ code \nsnippet and a list of the arguments for the function. The following\n\n 
              \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n
              \n \ncreates a C/C++ extension function that is equivalent to the following Python\nfunction:\n\n 
              \n        def increment(a):\n            return a + 1\n
              \n\nA second method is also added to the module and then,\n\n 
              \n        mod.compile()\n
              \n\nis called to build the extension module. By default, the module is created\nin the current working directory.\n\nThis example is available in the examples/increment_example.py file\nfound in the weave directory. At the bottom of the file in the\nmodule's \"main\" program, an attempt to import increment_ext without\nbuilding it is made. If this fails (the module doesn't exist in the PYTHONPATH), \nthe module is built by calling build_increment_ext(). This approach\nonly takes the time consuming ( a few seconds for this example) process of building\nthe module if it hasn't been built before.\n\n 
              \n    if __name__ == \"__main__\":\n        try:\n            import increment_ext\n        except ImportError:\n            build_increment_ext()\n            import increment_ext\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\n\nNote: If we were willing to always pay the penalty of building the C++ code for \na module, we could store the md5 checksum of the C++ code along with some \ninformation about the compiler, platform, etc. Then, \next_module.compile() could try importing the module before it actually\ncompiles it, check the md5 checksum and other meta-data in the imported module\nwith the meta-data of the code it just produced and only compile the code if\nthe module didn't exist or the meta-data didn't match. This would reduce the\nabove code to:\n\n 
              \n    if __name__ == \"__main__\":\n        build_increment_ext()\n\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\nNote: There would always be the overhead of building the C++ code, but it would only actually compile the code once. You pay a little in overhead and get cleaner\n\"import\" code. Needs some thought.\n\n

              \n\nIf you run increment_example.py from the command line, you get\nthe following:\n\n 

              \n    [eric@n0]$ python increment_example.py\n    a, a+1: 1 2\n    a, a+2: 1 3\n
              \n\nIf the module didn't exist before it was run, the module is created. If it did\nexist, it is just imported and used.\n\n\n

              Fibonacci Example

              \nexamples/fibonacci.py provides a little more complex example of \nhow to use ext_tools. Fibonacci numbers are a series of numbers \nwhere each number in the series is the sum of the previous two: 1, 1, 2, 3, 5, \n8, etc. Here, the first two numbers in the series are taken to be 1. One \napproach to calculating Fibonacci numbers uses recursive function calls. In \nPython, it might be written as:\n\n 
              \n    def fib(a):\n        if a <= 2:\n            return 1\n        else:\n            return fib(a-2) + fib(a-1)\n
              \n\nIn C, the same function would look something like this:\n\n 
              \n     int fib(int a)\n     {                   \n         if(a <= 2)\n             return 1;\n         else\n             return fib(a-2) + fib(a-1);  \n     }                      \n
              \n\nRecursion is much faster in C than in Python, so it would be beneficial\nto use the C version for fibonacci number calculations instead of the\nPython version. We need an extension function that calls this C function\nto do this. This is possible by including the above code snippet as \n\"support code\" and then calling it from the extension function. Support \ncode snippets (usually structure definitions, helper functions and the like)\nare inserted into the extension module C/C++ file before the extension\nfunction code. Here is how to build the C version of the fibonacci number\ngenerator:\n\n 
              \ndef build_fibonacci():\n    \"\"\" Builds an extension module with fibonacci calculators.\n    \"\"\"\n    mod = ext_tools.ext_module('fibonacci_ext')\n    a = 1 # this is effectively a type declaration\n    \n    # recursive fibonacci in C \n    fib_code = \"\"\"\n                   int fib1(int a)\n                   {                   \n                       if(a <= 2)\n                           return 1;\n                       else\n                           return fib1(a-2) + fib1(a-1);  \n                   }                         \n               \"\"\"\n    ext_code = \"\"\"\n                   int val = fib1(a);\n                   return_val = Py::new_reference_to(Py::Int(val));\n               \"\"\"    \n    fib = ext_tools.ext_function('fib',ext_code,['a'])\n    fib.customize.add_support_code(fib_code)\n    mod.add_function(fib)\n\n    mod.compile()\n\n
              \n\nXXX More about custom_info, and what xxx_info instances are good for.\n\n

              \n\nNote: recursion is not the fastest way to calculate fibonacci numbers, but this \napproach serves nicely for this example.\n\n

              \n\n

              Customizing Type Conversions -- Type Factories

              \nnot written\n\n

              Things I wish weave did

              \n\nIt is possible to get name clashes if you uses a variable name that is already defined\nin a header automatically included (such as stdio.h) For instance, if you\ntry to pass in a variable named stdout, you'll get a cryptic error report\ndue to the fact that stdio.h also defines the name. weave\nshould probably try and handle this in some way.\n\nOther things...", "methods": [], "methods_before": [], "changed_methods": [], "nloc": null, "complexity": null, "token_count": null, "diff_parsed": { "added": [ "
              Installation", "
              Testing", " On Unix gcc is the preferred choice because I've done a little", " stdc++ library. Is this standard across", " Unix compilers, or is this a gcc-ism?", " which is the \"next generation\" implementation. This is not", " required for using inline() or ext_tools.", "

              Installation

              ", "href=\"http://www.scipy.org/weave\">here. Unix users should grab the", "both are used in the unit-testing process. Numeric is required if you want to", "use blitz(), but isn't necessary for inline() or", "ext_tools", "For Windows users, it's even easier. You can download the click-install .exe", "file and run it for automatic installation. There is also a .zip file of the", "source for those interested. It also includes a setup.py file to simplify", "installation.", "If you're using the CVS version, you'll need to install", "scipy_distutils and scipy_test packages (also", "available from CVS) on your own.", "

              ", "", "Note: The dependency issue here is a little sticky. I hate to make people", "lead to undesired clobbering of the scipy_test and scipy_distutils modules.", "What to do, what to do... Right now it is a very minor issue.", "", "", "

              Testing

              ", " runs long time... spews tons of output and a few warnings", " .", " .", " .", " ..............................................................", " ................................................................", " ..................................................", " ----------------------------------------------------------------------", " Ran 184 tests in 158.418s", "", " OK", " ", " >>>", "get errors, they'll be reported at the end of the output. Please let me know", "what if this occurs.", "Testing Notes:", "
                ", "
              • ", " Windows 1", "

                ", " I've had some test fail on windows machines where I have msvc, gcc-2.95.2", " (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My", " environment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the", " path. The test process runs very smoothly until the end where several test", " using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v')", " before running tests, I get gcc-2.95.3-6. If I check after running tests", " (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH']", " still has c:\\gcc first in it and is not corrupted (msvc/distutils messes", " with the environment variables, so we have to undo its work in some", " places). If anyone else sees this, let me know - - it may just be an quirk", " on my machine (unlikely). Testing with the gcc- 2.95.2 installation always", " works.", "

                ", "

                • ", "
              • ", " Windows 2", "

                ", " If you run the tests from PythonWin or some other GUI tool, you'll get a", " ton of DOS windows popping up periodically as weave spawns", " the compiler multiple times. Very annoying. Anyone know how to fix this?", "

                ", "

                • ", "
              • ", " wxPython", "

                ", " wxPython tests are not enabled by default because importing wxPython on a", " Unix machine without access to a X-term will cause the program to exit.", " Anyone know of a safe way to detect whether wxPython can be imported and", " whether a display exists on a machine?", "

                ", "

                • ", "", "
              ", "Nothing bad is happening, its just a bit annoying. Anyone know how to", "output that distutils does not supress. The name of the extension file,", "sc_bighonkingnumber.cpp, is generated from the md5 check sum", "of the C/C++ code fragment. On Unix or windows machines with only", " Note: I've only used the compiler option for switching between 'msvc'", "There are several main steps to using C/C++ code withing Python:", "case is trivially easy:", "

              Fibonacci Example

              " ], "deleted": [ "
              Installation and Testing", " On Unix gcc is the preferred choice, because I've done a little", " stdc++ library. Is this standard across", " Unix compilers, or is this a gcc-ism?", " which is the \"next generation\" implementation.", "

              Installation and Testing

              ", "href=\"www.scipy.org/weave\">here. Unix users should grab the", "both are used in the unit-testing process. For Windows users, it's even easier.", "They can download the click-install .exe file and run it for automatic", "installation. Numeric is required if you want to use blitz(), but", "isn't necessary for inline() or ext_tools", "If you're using the CVS version, you'll need to install scipy_distutils and", "scipy_test modules (also available from CVS) on your own.", " Note: The dependency issue here is a little sticky. I hate to make people", "lead to undesired clobbering of modules. What to do, what to do...", " runs long time... spews tons of output", "get errors, please let me know.", "Windows Note: I've had some test fail on windows machines where I have msvc,", "gcc-2.95.2 (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My", "environment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the path.", "The test process runs very smoothly until the end where several test using gcc", "fail with cpp0 not found by g++. If I check os.system('gcc -v') before running", "tests, I get gcc-2.95.3-6. If I check after running tests (and after failure),", "I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\\gcc first in it", "and is not corrupted (msvc/distutils messes with the environment variables, so", "we have to undo its work in some places). If anyone else sees this, let me", "know - - it may just be an quirk on my machine (unlikely). Testing with the", "gcc- 2.95.2 installation always works.", "", "wxPython Note: wxPython tests are not enabled by default because importing", "wxPython on a Unix machine without access to a X-term will cause the", "program to exit. Anyone know of a safe way to detect whether wxPython", "can be imported and whether a display exists on a machine?", "", "Nothing bead is happening, its just a bit annoying. Anyone know how to", "output that distutils does not supress. On Unix or windows machines with only", " Note: I've only used the weave option for switching between 'msvc'", "There are", "case, is of course, trivially easy:", "

              Fibonacci Example

              " ] } } ] }, { "hash": "223f42b6e3201935e7e9304fddf798f1115de9eb", "msg": "added benchmarks", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-04T20:52:02+00:00", "author_timezone": 0, "committer_date": "2002-01-04T20:52:02+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "c6ca53cd5ff3671d088cb1728b40e7ff8c0c5bb6" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 1, "insertions": 34, "lines": 35, "files": 1, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": "weave/doc/tutorial.html", "new_path": "weave/doc/tutorial.html", "filename": "tutorial.html", "extension": "html", "change_type": "MODIFY", "diff": "@@ -9,6 +9,7 @@

              Outline

              \n
              Requirements\n
              Installation\n
              Testing\n+
              Benchmarks\n
              Inline\n
              \n
              More with printf\n@@ -174,7 +175,7 @@

              Requirements

              \n For blitz(), you'll need a reasonably recent version of \n gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n versions are likely to work. Its likely that KAI's C++ compiler and \n- maybe some others will work, but I haven't tried. My advise is to use \n+ maybe some others will work, but I haven't tried. My advice is to use \n gcc for now unless your willing to tinker with the code some.\n

              \n On Windows, either MSVC or gcc (Testing\n

              \n \n \n+\n+

              Benchmarks

              \n+This section has a few benchmarks -- thats all people want to see anyway right? \n+These are mostly taken from running files in the weave/example \n+directory and also from the test scripts. Without more information about what \n+the test actually do, their value is limited. Still, their here for the \n+curious. Look at the example scripts for more specifics about what problem was \n+actually solved by each run. These examples are run under windows 2000 using \n+Microsoft Visual C++ and python2.1 on a 850 MHz PIII laptop with 320 MB of RAM.\n+

              \n+

              \n+\n+\n+ \n+ \n+ \n+ \n+ \n+ \n+ \n+ \n+\n+ \n+ \n+ \n+ \n+ \n+
              \n+

              inline and ext_tools

              Algorithm

              Speed up

              binary search   1.50
              fibonacci (recursive)  82.10
              fibonacci (loop)   9.17
              return None   0.14
              map   1.20
              dictionary sort   2.54
              vector quantization  37.40
              \n+

              blitz -- double precision

              Algorithm

              Speed up

              a = b + c 512x512   3.05
              a = b + c + d 512x512   4.59
              5 pt avg. filter, 2D Image 512x512   9.01
              Electromagnetics (FDTD) 100x100x100   8.61
              \n+
              \n+

              \n \n

              Inline

              \n

              \n", "added_lines": 34, "deleted_lines": 1, "source_code": "\n

              Weave Documentation

              \n

              \nBy Eric Jones eric@enthought.com\n

              \n

              Outline

              \n
              \n
              Introduction\n
              Requirements\n
              Installation\n
              Testing\n
              Benchmarks\n
              Inline\n
              \n
              More with printf\n
              \n More examples\n
              \n
              Binary search\n
              Dictionary sort\n
              Numeric -- cast/copy/transpose\n
              wxPython
              \n
              \n
              Keyword options\n
              Returning values\n
              \n
              \n The issue with locals()
              \n
              \n
              A quick look at the code\n
              \n Technical Details\n
              \n
              Converting Types\n
              \n
              \n Numeric Argument Conversion\n
              \n String, List, Tuple, and Dictionary Conversion\n
              File Conversion \n
              \n Callable, Instance, and Module Conversion \n
              Customizing Conversions\n
              \n
              Compiling Code\n
              \"Cataloging\" functions\n
              \n
              Function Storage\n
              The PYTHONCOMPILED evnironment variable
              \n
              \n
              \n
              \n
              \n
              \n
              Blitz\n
              \n
              Requirements\n
              Limitations\n
              Numeric Efficiency Issues\n
              The Tools \n
              \n
              Parser\n
              Blitz and Numeric\n
              \n
              Type defintions and coersion\n
              Cataloging Compiled Functions\n
              Checking Array Sizes\n
              Creating the Extension Module\n
              \n
              Extension Modules\n
              \n
              A Simple Example\n
              Fibonacci Example\n
              \n
              Customizing Type Conversions -- Type Factories (not written)\n
              \n
              Type Specifications\n
              Type Information\n
              The Conversion Process \n
              \n
              \n\n

              Introduction

              \n\n

              \nThe weave package provides tools for including C/C++ code within\nin Python code. This offers both another level of optimization to those who need \nit, and an easy way to modify and extend any supported extension libraries such \nas wxPython and hopefully VTK soon. Inlining C/C++ code within Python generally\nresults in speed ups of 1.5x to 30x speed-up over algorithms written in pure\nPython (However, it is also possible to slow things down...). Generally \nalgorithms that require a large number of calls to the Python API don't benefit\nas much from the conversion to C/C++ as algorithms that have inner loops \ncompletely convertable to C.\n

              \nThere are three basic ways to use weave. The \nweave.inline() function executes C code directly within Python, \nand weave.blitz() translates Python Numeric expressions to C++ \nfor fast execution. blitz() was the original reason \nweave was built. For those interested in building extension\nlibraries, the ext_tools module provides classes for building \nextension modules within Python. \n

              \nMost of weave's functionality should work on Windows and Unix, \nalthough some of its functionality requires gcc or a similarly \nmodern C++ compiler that handles templates well. Up to now, most testing has \nbeen done on Windows 2000 with Microsoft's C++ compiler (MSVC) and with gcc \n(mingw32 2.95.2 and 2.95.3-6). All tests also pass on Linux (RH 7.1 \nwith gcc 2.96), and I've had reports that it works on Debian also (thanks \nPearu).\n

              \nThe inline and blitz provide new functionality to \nPython (although I've recently learned about the PyInline project which may offer \nsimilar functionality to inline). On the other hand, tools for \nbuilding Python extension modules already exists (SWIG, SIP, pycpp, CXX, and \nothers). As of yet, I'm not sure where weave fits in this \nspectrum. It is closest in flavor to CXX in that it makes creating new C/C++ \nextension modules pretty easy. However, if you're wrapping a gaggle of legacy \nfunctions or classes, SWIG and friends are definitely the better choice. \nweave is set up so that you can customize how Python types are \nconverted to C types in weave. This is great for \ninline(), but, for wrapping legacy code, it is more flexible to \nspecify things the other way around -- that is how C types map to Python types. \nThis weave does not do. I guess it would be possible to build \nsuch a tool on top of weave, but with good tools like SWIG around, \nI'm not sure the effort produces any new capabilities. Things like function \noverloading are probably easily implemented in weave and it might \nbe easier to mix Python/C code in function calls, but nothing beyond this comes \nto mind. So, if you're developing new extension modules or optimizing Python \nfunctions in C, weave.ext_tools() might be the tool \nfor you. If you're wrapping legacy code, stick with SWIG.\n

              \nThe next several sections give the basics of how to use weave.\nWe'll discuss what's happening under the covers in more detail later \non. Serious users will need to at least look at the type conversion section to \nunderstand how Python variables map to C/C++ types and how to customize this \nbehavior. One other note. If you don't know C or C++ then these docs are \nprobably of very little help to you. Further, it'd be helpful if you know \nsomething about writing Python extensions. weave does quite a \nbit for you, but for anything complex, you'll need to do some conversions, \nreference counting, etc.\n

              \n\nNote: weave is actually part of the SciPy package. However, it works fine as a \nstandalone package. The examples here are given as if it is used as a stand \nalone package. If you are using from within scipy, you can use from \nscipy import weave and the examples will work identically.\n\n\n

              Requirements

              \n
                \n
              • Python\n

                \n I use 2.1.1. Probably 2.0 or higher should work.\n

                \n

                • \n \n
              • C++ compiler\n

                \n weave uses distutils to actually build \n extension modules, so it uses whatever compiler was originally used to \n build Python. weave itself requires a C++ compiler. If \n you used a C++ compiler to build Python, your probably fine.\n

                \n On Unix gcc is the preferred choice because I've done a little \n testing with it. All testing has been done with gcc, but I expect the \n majority of compilers should work for inline and \n ext_tools. The one issue I'm not sure about is that I've \n hard coded things so that compilations are linked with the \n stdc++ library. Is this standard across \n Unix compilers, or is this a gcc-ism?\n

                \n For blitz(), you'll need a reasonably recent version of \n gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n versions are likely to work. Its likely that KAI's C++ compiler and \n maybe some others will work, but I haven't tried. My advice is to use \n gcc for now unless your willing to tinker with the code some.\n

                \n On Windows, either MSVC or gcc (www.mingw.org\" > mingw32) should work. Again, \n you'll need gcc for blitz() as the\n MSVC compiler doesn't handle templates well.\n

                \n I have not tried Cygwin, so please report success if it works for you.\n

                \n

                • \n\n
              • Numeric (optional)\n

                \n The python Numeric module from here. is required for \n blitz() to work. Be sure and get NumPy, not NumArray\n which is the \"next generation\" implementation. This is not\n required for using inline() or ext_tools.\n

                \n

                • \n
              • scipy_distutils and scipy_test (packaged with weave)\n

                \n These two modules are packaged with weave in both\n the windows installer and the source distributions. If you are using\n CVS, however, you'll need to download these separately (also available\n through CVS at SciPy).\n

                \n

                • \n
              \n

              \n\n\n

              Installation

              \n

              \nThere are currently two ways to get weave. Fist, \nweave is part of SciPy and installed automatically (as a sub-\npackage) whenever SciPy is installed (although the latest version isn't in \nSciPy yet, so use this one for now). Second, since weave is \nuseful outside of the scientific community, it has been setup so that it can be\nused as a stand-alone module. \n\n

              \nThe stand-alone version can be downloaded from here. Unix users should grab the \ntar ball (.tgz file) and install it using the following commands.\n\n 

              \n    tar -xzvf weave-0.2.tar.gz\n    cd weave-0.2\n    python setup.py install\n
              \n\nThis will also install two other packages, scipy_distutils and \nscipy_test. The first is needed by the setup process itself and \nboth are used in the unit-testing process. Numeric is required if you want to \nuse blitz(), but isn't necessary for inline() or \next_tools\n

              \nFor Windows users, it's even easier. You can download the click-install .exe \nfile and run it for automatic installation. There is also a .zip file of the\nsource for those interested. It also includes a setup.py file to simplify\ninstallation. \n

              \nIf you're using the CVS version, you'll need to install \nscipy_distutils and scipy_test packages (also \navailable from CVS) on your own.\n

              \n \nNote: The dependency issue here is a little sticky. I hate to make people \ndownload more than one file (and so I haven't), but distutils doesn't have a \nway to do conditional installation -- at least that I know about. This can \nlead to undesired clobbering of the scipy_test and scipy_distutils modules. \nWhat to do, what to do... Right now it is a very minor issue.\n\n

              \n\n

              Testing

              \nOnce weave is installed, fire up python and run its unit tests.\n\n 
              \n    >>> import weave\n    >>> weave.test()\n    runs long time... spews tons of output and a few warnings\n    .\n    .\n    .\n    ..............................................................\n    ................................................................\n    ..................................................\n    ----------------------------------------------------------------------\n    Ran 184 tests in 158.418s\n\n    OK\n    \n    >>> \n
              \n\nThis takes a loooong time. On windows, it is usually several minutes. On Unix \nwith remote file systems, I've had it take 15 or so minutes. In the end, it \nshould run about 180 tests and spew some speed results along the way. If you \nget errors, they'll be reported at the end of the output. Please let me know\nwhat if this occurs.\n\nIf you don't have Numeric installed, you'll get some module import errors \nduring the test setup phase for modules that are Numeric specific (blitz_spec, \nblitz_tools, size_check, standard_array_spec, ast_tools), but all test should\npass (about 100 and they should complete in several minutes).\n

              \nIf you only want to test a single module of the package, you can do this by\nrunning test() for that specific module.\n\n 

              \n    >>> import weave.scalar_spec\n    >>> weave.scalar_spec.test()\n    .......\n    ----------------------------------------------------------------------\n    Ran 7 tests in 23.284s\n
              \n\nTesting Notes:\n
                \n
              • \n Windows 1\n

                \n I've had some test fail on windows machines where I have msvc, gcc-2.95.2 \n (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My \n environment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the \n path. The test process runs very smoothly until the end where several test \n using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') \n before running tests, I get gcc-2.95.3-6. If I check after running tests \n (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] \n still has c:\\gcc first in it and is not corrupted (msvc/distutils messes \n with the environment variables, so we have to undo its work in some \n places). If anyone else sees this, let me know - - it may just be an quirk \n on my machine (unlikely). Testing with the gcc- 2.95.2 installation always \n works.\n

                \n

                • \n
              • \n Windows 2\n

                \n If you run the tests from PythonWin or some other GUI tool, you'll get a\n ton of DOS windows popping up periodically as weave spawns\n the compiler multiple times. Very annoying. Anyone know how to fix this?\n

                \n

                • \n
              • \n wxPython\n

                \n wxPython tests are not enabled by default because importing wxPython on a \n Unix machine without access to a X-term will cause the program to exit. \n Anyone know of a safe way to detect whether wxPython can be imported and \n whether a display exists on a machine? \n

                \n

                • \n                \n\n

                \n

              \n\n\n

              Benchmarks

              \nThis section has a few benchmarks -- thats all people want to see anyway right? \nThese are mostly taken from running files in the weave/example \ndirectory and also from the test scripts. Without more information about what \nthe test actually do, their value is limited. Still, their here for the \ncurious. Look at the example scripts for more specifics about what problem was \nactually solved by each run. These examples are run under windows 2000 using \nMicrosoft Visual C++ and python2.1 on a 850 MHz PIII laptop with 320 MB of RAM.\n

              \n

              \n\n\n \n \n \n \n \n \n \n \n\n \n \n \n \n \n
              \n

              inline and ext_tools

              Algorithm

              Speed up

              binary search   1.50
              fibonacci (recursive)  82.10
              fibonacci (loop)   9.17
              return None   0.14
              map   1.20
              dictionary sort   2.54
              vector quantization  37.40
              \n

              blitz -- double precision

              Algorithm

              Speed up

              a = b + c 512x512   3.05
              a = b + c + d 512x512   4.59
              5 pt avg. filter, 2D Image 512x512   9.01
              Electromagnetics (FDTD) 100x100x100   8.61
              \n
              \n

              \n\n

              Inline

              \n

              \ninline() compiles and executes C/C++ code on the fly. Variables \nin the local and global Python scope are also available in the C/C++ code. \nValues are passed to the C/C++ code by assignment much like variables \nare passed into a standard Python function. Values are returned from the C/C++ \ncode through a special argument called return_val. Also, the contents of \nmutable objects can be changed within the C/C++ code and the changes remain \nafter the C code exits and returns to Python. (more on this later)\n

              \nHere's a trivial printf example using inline():\n\n 

              \n    >>> import weave    \n    >>> a  = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n

              \nIn this, its most basic form, inline(c_code, var_list) requires two \narguments. c_code is a string of valid C/C++ code. \nvar_list is a list of variable names that are passed from \nPython into C/C++. Here we have a simple printf statement that \nwrites the Python variable a to the screen. The first time you run \nthis, there will be a pause while the code is written to a .cpp file, compiled \ninto an extension module, loaded into Python, cataloged for future use, and \nexecuted. On windows (850 MHz PIII), this takes about 1.5 seconds when using \nMicrosoft's C++ compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). \nAll subsequent executions of the code will happen very quickly because the code \nonly needs to be compiled once. If you kill and restart the interpreter and then \nexecute the same code fragment again, there will be a much shorter delay in the \nfractions of seconds range. This is because weave stores a \ncatalog of all previously compiled functions in an on disk cache. When it sees \na string that has been compiled, it loads the already compiled module and \nexecutes the appropriate function. \n

              \n\nNote: If you try the printf example in a GUI shell such as IDLE, \nPythonWin, PyShell, etc., you're unlikely to see the output. This is because the \nC code is writing to stdout, instead of to the GUI window. This doesn't mean \nthat inline doesn't work in these environments -- it only means that standard \nout in C is not the same as the standard out for Python in these cases. Non \ninput/output functions will work as expected.\n\n

              \nAlthough effort has been made to reduce the overhead associated with calling \ninline, it is still less efficient for simple code snippets than using \nequivalent Python code. The simple printf example is actually \nslower by 30% or so than using Python print statement. And, it is \nnot difficult to create code fragments that are 8-10 times slower using inline \nthan equivalent Python. However, for more complicated algorithms, \nthe speed up can be worth while -- anywhwere from 1.5- 30 times faster. \nAlgorithms that have to manipulate Python objects (sorting a list) usually only \nsee a factor of 2 or so improvement. Algorithms that are highly computational \nor manipulate Numeric arrays can see much larger improvements. The \nexamples/vq.py file shows a factor of 30 or more improvement on the vector \nquantization algorithm that is used heavily in information theory and \nclassification problems.\n

              \n\n\n

              More with printf

              \n

              \nMSVC users will actually see a bit of compiler output that distutils does not\nsupress the first time the code executes:\n\n 

                  \n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    sc_e013937dbc8c647ac62438874e5795131.cpp\n       Creating library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\n       \\Release\\sc_e013937dbc8c647ac62438874e5795131.lib and object C:\\DOCUME\n       ~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_e013937dbc8c64\n       7ac62438874e5795131.exp\n    1\n
              \n

              \nNothing bad is happening, its just a bit annoying. Anyone know how to \nturn this off? \n

              \nThis example also demonstrates using 'raw strings'. The r \npreceeding the code string in the last example denotes that this is a 'raw \nstring'. In raw strings, the backslash character is not interpreted as an \nescape character, and so it isn't necessary to use a double backslash to \nindicate that the '\\n' is meant to be interpreted in the C printf \nstatement instead of by Python. If your C code contains a lot\nof strings and control characters, raw strings might make things easier.\nMost of the time, however, standard strings work just as well.\n\n

              \nThe printf statement in these examples is formatted to print \nout integers. What happens if a is a string? inline\nwill happily, compile a new version of the code to accept strings as input,\nand execute the code. The result?\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    32956972\n
              \n

              \nIn this case, the result is non-sensical, but also non-fatal. In other \nsituations, it might produce a compile time error because a is \nrequired to be an integer at some point in the code, or it could produce a \nsegmentation fault. Its possible to protect against passing \ninline arguments of the wrong data type by using asserts in \nPython.\n\n 

                  \n    >>> a = 'string'\n    >>> def protected_printf(a):    \n    ...     assert(type(a) == type(1))\n    ...     weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    >>> protected_printf(1)\n     1\n    >>> protected_printf('string')\n    AssertError...\n
              \n\n

              \nFor printing strings, the format statement needs to be changed.\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%s\\n\",a);',['a'])\n    string\n
              \n\n

              \nAs in this case, C/C++ code fragments often have to change to accept different \ntypes. For the given printing task, however, C++ streams provide a way of a \nsingle statement that works for integers and strings. By default, the stream \nobjects live in the std (standard) namespace and thus require the use of \nstd::.\n\n 

                  \n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    1    \n    >>> a = 'string'\n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    string\n
              \n \n

              \nExamples using printf and cout are included in \nexamples/print_example.py.\n\n\n

              More examples

              \n\nThis section shows several more advanced uses of inline. It \nincludes a few algorithms from the Python Cookbook \nthat have been re-written in inline C to improve speed as well as a couple \nexamples using Numeric and wxPython.\n\n\n

              Binary search

              \nLets look at the example of searching a sorted list of integers for a value. \nFor inspiration, we'll use Kalle Svensson's \nbinary_search() algorithm from the Python Cookbook. His recipe follows:\n\n 
              \n    def binary_search(seq, t):\n        min = 0; max = len(seq) - 1\n        while 1:\n            if max < min:\n                return -1\n            m = (min  + max)  / 2\n            if seq[m] < t: \n                min = m  + 1 \n            elif seq[m] > t: \n                max = m  - 1 \n            else:\n                return m    \n
              \n\nThis Python version works for arbitrary Python data types. The C version below is \nspecialized to handle integer values. There is a little type checking done in \nPython to assure that we're working with the correct data types before heading \ninto C. The variables seq and t don't need to be \ndeclared beacuse weave handles converting and declaring them in \nthe C code. All other temporary variables such as min, max, etc. \nmust be declared -- it is C after all. Here's the new mixed Python/C function:\n\n 
                  \n    def c_int_binary_search(seq,t):\n        # do a little type checking in Python\n        assert(type(t) == type(1))\n        assert(type(seq) == type([]))\n        \n        # now the C code\n        code = \"\"\"\n               #line 29 \"binary_search.py\"\n               int val, m, min = 0;  \n               int max = seq.length() - 1;\n               PyObject *py_val; \n               for(;;)\n               {\n                   if (max < min  ) \n                   { \n                       return_val =  Py::new_reference_to(Py::Int(-1)); \n                       break;\n                   } \n                   m =  (min + max) /2;\n                   val =    py_to_int(PyList_GetItem(seq.ptr(),m),\"val\"); \n                   if (val  < t) \n                       min = m  + 1;\n                   else if (val >  t)\n                       max = m - 1;\n                   else\n                   {\n                       return_val = Py::new_reference_to(Py::Int(m));\n                       break;\n                   }\n               }\n               \"\"\"\n        return inline(code,['seq','t'])\n
              \n

              \nWe have two variables seq and t passed in. \nt is guaranteed (by the assert) to be an integer. \nPython integers are converted to C int types in the transition from Python to \nC. seq is a Python list. By default, it is translated to a CXX \nlist object. Full documentation for the CXX library can be found at its website. The basics are that the CXX \nprovides C++ class equivalents for Python objects that simplify, or at \nleast object orientify, working with Python objects in C/C++. For example, \nseq.length() returns the length of the list. A little more about\nCXX and its class methods, etc. is in the ** type conversions ** section.\n

              \n\nNote: CXX uses templates and therefore may be a little less portable than \nanother alternative by Gordan McMillan called SCXX which was inspired by\nCXX. It doesn't use templates so it should compile faster and be more portable.\nSCXX has a few less features, but it appears to me that it would mesh with\nthe needs of weave quite well. Hopefully xxx_spec files will be written\nfor SCXX in the future, and we'll be able to compare on a more empirical\nbasis. Both sets of spec files will probably stick around, it just a question\nof which becomes the default.\n\n

              \nMost of the algorithm above looks similar in C to the original Python code. \nThere are two main differences. The first is the setting of \nreturn_val instead of directly returning from the C code with a \nreturn statement. return_val is an automatically \ndefined variable of type PyObject* that is returned from the C \ncode back to Python. You'll have to handle reference counting issues when \nsetting this variable. In this example, CXX classes and functions handle the \ndirty work. All CXX functions and classes live in the namespace \nPy::. The following code converts the integer m to a \nCXX Int() object and then to a PyObject* with an \nincremented reference count using Py::new_reference_to().\n\n 

                 \n    return_val = Py::new_reference_to(Py::Int(m));\n
              \n

              \nThe second big differences shows up in the retrieval of integer values from the \nPython list. The simple Python seq[i] call balloons into a C \nPython API call to grab the value out of the list and then a separate call to \npy_to_int() that converts the PyObject* to an integer. \npy_to_int() includes both a NULL cheack and a \nPyInt_Check() call as well as the conversion call. If either of \nthe checks fail, an exception is raised. The entire C++ code block is executed \nwith in a try/catch block that handles exceptions much like Python \ndoes. This removes the need for most error checking code.\n

              \nIt is worth note that CXX lists do have indexing operators that result \nin code that looks much like Python. However, the overhead in using them \nappears to be relatively high, so the standard Python API was used on the \nseq.ptr() which is the underlying PyObject* of the \nList object.\n

              \nThe #line directive that is the first line of the C code \nblock isn't necessary, but it's nice for debugging. If the compilation fails \nbecause of the syntax error in the code, the error will be reported as an error \nin the Python file \"binary_search.py\" with an offset from the given line number \n(29 here).\n

              \nSo what was all our effort worth in terms of efficiency? Well not a lot in \nthis case. The examples/binary_search.py file runs both Python and C versions \nof the functions As well as using the standard bisect module. If \nwe run it on a 1 million element list and run the search 3000 times (for 0-\n2999), here are the results we get:\n\n 

                 \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python binary_search.py\n    Binary search for 3000 items in 1000000 length list of integers:\n     speed in python: 0.159999966621\n     speed of bisect: 0.121000051498\n     speed up: 1.32\n     speed in c: 0.110000014305\n     speed up: 1.45\n     speed in c(no asserts): 0.0900000333786\n     speed up: 1.78\n
              \n

              \nSo, we get roughly a 50-75% improvement depending on whether we use the Python \nasserts in our C version. If we move down to searching a 10000 element list, \nthe advantage evaporates. Even smaller lists might result in the Python \nversion being faster. I'd like to say that moving to Numeric lists (and \ngetting rid of the GetItem() call) offers a substantial speed up, but my \npreliminary efforts didn't produce one. I think the log(N) algorithm is to \nblame. Because the algorithm is nice, there just isn't much time spent \ncomputing things, so moving to C isn't that big of a win. If there are ways to \nreduce conversion overhead of values, this may improve the C/Python speed \nup. Anyone have other explanations or faster code, please let me know.\n\n\n

              Dictionary Sort

              \n

              \nThe demo in examples/dict_sort.py is another example from the Python CookBook. \nThis \nsubmission, by Alex Martelli, demonstrates how to return the values from a \ndictionary sorted by their keys:\n\n 

                     \n    def sortedDictValues3(adict):\n        keys = adict.keys()\n        keys.sort()\n        return map(adict.get, keys)\n
              \n

              \nAlex provides 3 algorithms and this is the 3rd and fastest of the set. The C \nversion of this same algorithm follows:\n\n 

                     \n    def c_sort(adict):\n        assert(type(adict) == type({}))\n        code = \"\"\"     \n        #line 21 \"dict_sort.py\"  \n        Py::List keys = adict.keys();\n        Py::List items(keys.length()); keys.sort();     \n        PyObject* item = NULL; \n        for(int i = 0;  i < keys.length();i++)\n        {\n            item = PyList_GET_ITEM(keys.ptr(),i);\n            item = PyDict_GetItem(adict.ptr(),item);\n            Py_XINCREF(item);\n            PyList_SetItem(items.ptr(),i,item);              \n        }           \n        return_val = Py::new_reference_to(items);\n        \"\"\"   \n        return inline_tools.inline(code,['adict'],verbose=1)\n
              \n

              \nLike the original Python function, the C++ version can handle any Python \ndictionary regardless of the key/value pair types. It uses CXX objects for the \nmost part to declare python types in C++, but uses Python API calls to manipulate \ntheir contents. Again, this choice is made for speed. The C++ version, while\nmore complicated, is about a factor of 2 faster than Python.\n\n 

                     \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python dict_sort.py\n    Dict sort of 1000 items for 300 iterations:\n     speed in python: 0.319999933243\n    [0, 1, 2, 3, 4]\n     speed in c: 0.151000022888\n     speed up: 2.12\n    [0, 1, 2, 3, 4]\n
              \n

              \n\n

              Numeric -- cast/copy/transpose

              \n\nCastCopyTranspose is a function called quite heavily by Linear Algebra routines\nin the Numeric library. Its needed in part because of the row-major memory layout\nof multi-demensional Python (and C) arrays vs. the col-major order of the underlying\nFortran algorithms. For small matrices (say 100x100 or less), a significant\nportion of the common routines such as LU decompisition or singular value decompostion\nare spent in this setup routine. This shouldn't happen. Here is the Python\nversion of the function using standard Numeric operations.\n\n 
                     \n    def _castCopyAndTranspose(type, array):\n        if a.typecode() == type:\n            cast_array = copy.copy(Numeric.transpose(a))\n        else:\n            cast_array = copy.copy(Numeric.transpose(a).astype(type))\n        return cast_array\n
              \n\nAnd the following is a inline C version of the same function:\n\n 
              \n    from weave.blitz_tools import blitz_type_factories\n    from weave import scalar_spec\n    from weave import inline\n    def _cast_copy_transpose(type,a_2d):\n        assert(len(shape(a_2d)) == 2)\n        new_array = zeros(shape(a_2d),type)\n        numeric_type = scalar_spec.numeric_to_blitz_type_mapping[type]\n        code = \\\n        \"\"\"  \n        for(int i = 0;i < _Na_2d[0]; i++)  \n            for(int j = 0;  j < _Na_2d[1]; j++)\n                new_array(i,j) = (%s) a_2d(j,i);\n        \"\"\" % numeric_type\n        inline(code,['new_array','a_2d'],\n               type_factories = blitz_type_factories,compiler='gcc')\n        return new_array\n
              \n\nThis example uses blitz++ arrays instead of the standard representation of \nNumeric arrays so that indexing is simplier to write. This is accomplished by \npassing in the blitz++ \"type factories\" to override the standard Python to C++ \ntype conversions. Blitz++ arrays allow you to write clean, fast code, but they \nalso are sloooow to compile (20 seconds or more for this snippet). This is why \nthey aren't the default type used for Numeric arrays (and also because most \ncompilers can't compile blitz arrays...). inline() is also forced \nto use 'gcc' as the compiler because the default compiler on Windows (MSVC) \nwill not compile blitz code. 'gcc' I think will use the standard compiler \non Unix machine instead of explicitly forcing gcc (check this) \n\nComparisons of the Python vs inline C++ code show a factor of 3 speed up. Also \nshown are the results of an \"inplace\" transpose routine that can be used if the \noutput of the linear algebra routine can overwrite the original matrix (this is \noften appropriate). This provides another factor of 2 improvement.\n\n 
              \n     #C:\\home\\ej\\wrk\\scipy\\weave\\examples> python cast_copy_transpose.py\n    # Cast/Copy/Transposing (150,150)array 1 times\n    #  speed in python: 0.870999932289\n    #  speed in c: 0.25\n    #  speed up: 3.48\n    #  inplace transpose c: 0.129999995232\n    #  speed up: 6.70\n
              \n\n\n

              wxPython

              \n\ninline knows how to handle wxPython objects. Thats nice in and of\nitself, but it also demonstrates that the type conversion mechanism is reasonably \nflexible. Chances are, it won't take a ton of effort to support special types\nyou might have. The examples/wx_example.py borrows the scrolled window\nexample from the wxPython demo, accept that it mixes inline C code in the middle\nof the drawing function.\n\n 
              \n    def DoDrawing(self, dc):\n        \n        red = wxNamedColour(\"RED\");\n        blue = wxNamedColour(\"BLUE\");\n        grey_brush = wxLIGHT_GREY_BRUSH;\n        code = \\\n        \"\"\"\n        #line 108 \"wx_example.py\" \n        dc->BeginDrawing();\n        dc->SetPen(wxPen(*red,4,wxSOLID));\n        dc->DrawRectangle(5,5,50,50);\n        dc->SetBrush(*grey_brush);\n        dc->SetPen(wxPen(*blue,4,wxSOLID));\n        dc->DrawRectangle(15, 15, 50, 50);\n        \"\"\"\n        inline(code,['dc','red','blue','grey_brush'])\n        \n        dc.SetFont(wxFont(14, wxSWISS, wxNORMAL, wxNORMAL))\n        dc.SetTextForeground(wxColour(0xFF, 0x20, 0xFF))\n        te = dc.GetTextExtent(\"Hello World\")\n        dc.DrawText(\"Hello World\", 60, 65)\n\n        dc.SetPen(wxPen(wxNamedColour('VIOLET'), 4))\n        dc.DrawLine(5, 65+te[1], 60+te[0], 65+te[1])\n        ...\n
              \n\nHere, some of the Python calls to wx objects were just converted to C++ calls. There\nisn't any benefit, it just demonstrates the capabilities. You might want to use this\nif you have a computationally intensive loop in your drawing code that you want to \nspeed up.\n\nOn windows, you'll have to use the MSVC compiler if you use the standard wxPython\nDLLs distributed by Robin Dunn. Thats because MSVC and gcc, while binary\ncompatible in C, are not binary compatible for C++. In fact, its probably best, no \nmatter what platform you're on, to specify that inline use the same\ncompiler that was used to build wxPython to be on the safe side. There isn't currently\na way to learn this info from the library -- you just have to know. Also, at least\non the windows platform, you'll need to install the wxWindows libraries and link to \nthem. I think there is a way around this, but I haven't found it yet -- I get some\nlinking errors dealing with wxString. One final note. You'll probably have to\ntweak weave/wx_spec.py or weave/wx_info.py for your machine's configuration to\npoint at the correct directories etc. There. That should sufficiently scare people\ninto not even looking at this... :)\n\n              \n

              Keyword Options

              \n

              \nThe basic definition of the inline() function has a slew of \noptional variables. It also takes keyword arguments that are passed to \ndistutils as compiler options. The following is a formatted \ncut/paste of the argument section of inline's doc-string. It \nexplains all of the variables. Some examples using various options will \nfollow.\n\n 

                     \n    def inline(code,arg_names,local_dict = None, global_dict = None, \n               force = 0, \n               compiler='',\n               verbose = 0, \n               support_code = None,\n               customize=None, \n               type_factories = None, \n               auto_downcast=1,\n               **kw):\n
              \n\n \ninline has quite \na few options as listed below. Also, the keyword arguments for distutils \nextension modules are accepted to specify extra information needed for \ncompiling. \n
              \n

              inline Arguments:

              \n
              \n
              \n
              code
              \n \n
              \nstring. A string of valid C++ code. It should not \n specify a return statement. Instead it should assign results that need to be \n returned to Python in the return_val. \n
              \n\n
              arg_names
              \n \n
              \nlist of strings. A list of Python variable names \n that should be transferred from Python into the C/C++ code. \n
              \n\n
              local_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the local scope for the C/C++ \n code. If local_dict is not specified the local dictionary of the calling \n function is used. \n
              \n\n
              global_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the global scope for the C/C++ \n code. If global_dict is not specified the global dictionary of the calling \n function is used. \n
              \n\n
              force
              \n \n
              \noptional. 0 or 1. default 0. If 1, the C++ code is \n compiled every time inline is called. This is really only useful for \n debugging, and probably only useful if you're editing support_code a lot. \n
              \n\n
              compiler
              \n \n
              \noptional. string. The name of compiler to use when compiling. On windows, it \nunderstands 'msvc' and 'gcc' as well as all the compiler names understood by \ndistutils. On Unix, it'll only understand the values understoof by distutils. \n(I should add 'gcc' though to this).\n

              \nOn windows, the compiler defaults to the Microsoft C++ compiler. If this isn't \navailable, it looks for mingw32 (the gcc compiler).\n

              \nOn Unix, it'll probably use the same compiler that was used when compiling \nPython. Cygwin's behavior should be similar.

              \n
              \n\n
              verbose
              \n \n
              \noptional. 0,1, or 2. defualt 0. Speficies how much \n much information is printed during the compile phase of inlining code. 0 is \n silent (except on windows with msvc where it still prints some garbage). 1 \n informs you when compiling starts, finishes, and how long it took. 2 prints \n out the command lines for the compilation process and can be useful if you're \n having problems getting code to work. Its handy for finding the name of the \n .cpp file if you need to examine it. verbose has no affect if the \n compilation isn't necessary. \n
              \n\n
              support_code
              \n \n
              \noptional. string. A string of valid C++ code \n declaring extra code that might be needed by your compiled function. This \n could be declarations of functions, classes, or structures. \n
              \n\n
              customize
              \n \n
              \noptional. base_info.custom_info object. An \n alternative way to specifiy support_code, headers, etc. needed by the \n function see the weave.base_info module for more details. (not sure \n this'll be used much). \n \n
              \n
              type_factories
              \n \n
              \noptional. list of type specification factories. These guys are what convert \nPython data types to C/C++ data types. If you'd like to use a different set of \ntype conversions than the default, specify them here. Look in the type \nconversions section of the main documentation for examples.\n
              \n
              auto_downcast
              \n \n
              \noptional. 0 or 1. default 1. This only affects functions that have Numeric \narrays as input variables. Setting this to 1 will cause all floating point \nvalues to be cast as float instead of double if all the Numeric arrays are of \ntype float. If even one of the arrays has type double or double complex, all \nvariables maintain there standard types.\n
              \n
              \n
              \n\n

              Distutils keywords:

              \n
              \ninline() also accepts a number of distutils keywords \nfor controlling how the code is compiled. The following descriptions have been \ncopied from Greg Ward's distutils.extension.Extension class doc-\nstrings for convenience:\n\n
              \n
              sources
              \n \n
              \n[string] list of source filenames, relative to the \n distribution root (where the setup script lives), in Unix form \n (slash-separated) for portability. Source files may be C, C++, SWIG (.i), \n platform-specific resource files, or whatever else is recognized by the \n \"build_ext\" command as source for a Python extension. Note: The module_path \n file is always appended to the front of this list \n
              \n\n
              include_dirs
              \n \n
              \n[string] list of directories to search for C/C++ \n header files (in Unix form for portability) \n
              \n\n
              define_macros
              \n \n
              \n[(name : string, value : string|None)] list of \n macros to define; each macro is defined using a 2-tuple, where 'value' is \n either the string to define it to or None to define it without a particular \n value (equivalent of \"#define FOO\" in source or -DFOO on Unix C compiler \n command line) \n
              \n
              undef_macros
              \n \n
              \n[string] list of macros to undefine explicitly \n
              \n
              library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at link time \n
              \n
              libraries
              \n
              \n[string] list of library names (not filenames or paths) to link against \n
              \n
              runtime_library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at run time (for \nshared extensions, this is when the extension is loaded) \n
              \n\n
              extra_objects
              \n \n
              \n[string] list of extra files to link with (eg. \n object files not implied by 'sources', static library that must be \n explicitly specified, binary resource files, etc.) \n
              \n\n
              extra_compile_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when compiling the source files in 'sources'. For \n platforms and compilers where \"command line\" makes sense, this is typically \n a list of command-line arguments, but for other platforms it could be \n anything. \n
              \n
              extra_link_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when linking object files together to create the \n extension (or to create a new static Python interpreter). Similar \n interpretation as for 'extra_compile_args'. \n
              \n
              export_symbols
              \n \n
              \n[string] list of symbols to be exported from a shared extension. Not used on \nall platforms, and not generally necessary for Python extensions, which \ntypically export exactly one symbol: \"init\" + extension_name. \n
              \n
              \n
              \n\n\n

              Keyword Option Examples

              \nWe'll walk through several examples here to demonstrate the behavior of \ninline and also how the various arguments are used.\n\nIn the simplest (most) cases, code and arg_names\nare the only arguments that need to be specified. Here's a simple example\nrun on Windows machine that has Microsoft VC++ installed.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'string'\n    >>> code = \"\"\"\n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));\n    ...        \"\"\"\n    >>> inline(code,['a'])\n     sc_86e98826b65b047ffd2cd5f479c627f12.cpp\n    Creating\n       library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f12.lib\n    and object C:\\DOCUME~ 1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ff\n    d2cd5f479c627f12.exp\n    6\n    >>> inline(code,['a'])\n    6\n
              \n \nWhen inline is first run, you'll notice that pause and some \ntrash printed to the screen. The \"trash\" is acutually part of the compilers\noutput that distutils does not supress. The name of the extension file, \nsc_bighonkingnumber.cpp, is generated from the md5 check sum\nof the C/C++ code fragment. On Unix or windows machines with only\ngcc installed, the trash will not appear. On the second call, the code \nfragment is not compiled since it already exists, and only the answer is \nreturned. Now kill the interpreter and restart, and run the same code with\na different string.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'a longer string' \n    >>> code = \"\"\" \n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));  \n    ...        \"\"\"\n    >>> inline(code,['a'])\n    15\n
              \n

              \nNotice this time, inline() did not recompile the code because it\nfound the compiled function in the persistent catalog of functions. There is\na short pause as it looks up and loads the function, but it is much shorter \nthan compiling would require.\n

              \nYou can specify the local and global dictionaries if you'd like (much like \nexec or eval() in Python), but if they aren't \nspecified, the \"expected\" ones are used -- i.e. the ones from the function that \ncalled inline() . This is accomplished through a little call \nframe trickery. Here is an example where the local_dict is specified using\nthe same code example from above:\n\n 

              \n    >>> a = 'a longer string'\n    >>> b = 'an even  longer string' \n    >>> my_dict = {'a':b}\n    >>> inline(code,['a'])\n    15\n    >>> inline(code,['a'],my_dict)\n    21\n
              \n \n

              \nEverytime, the code is changed, inline does a \nrecompile. However, changing any of the other options in inline does not\nforce a recompile. The force option was added so that one\ncould force a recompile when tinkering with other variables. In practice,\nit is just as easy to change the code by a single character\n(like adding a space some place) to force the recompile. Note: It also \nmight be nice to add some methods for purging the cache and on disk \ncatalogs.\n

              \nI use verbose sometimes for debugging. When set to 2, it'll \noutput all the information (including the name of the .cpp file) that you'd\nexpect from running a make file. This is nice if you need to examine the\ngenerated code to see where things are going haywire. Note that error\nmessages from failed compiles are printed to the screen even if verbose\n is set to 0.\n

              \nThe following example demonstrates using gcc instead of the standard msvc \ncompiler on windows using same code fragment as above. Because the example has \nalready been compiled, the force=1 flag is needed to make \ninline() ignore the previously compiled version and recompile \nusing gcc. The verbose flag is added to show what is printed out:\n\n 

              \n    >>>inline(code,['a'],compiler='gcc',verbose=2,force=1)\n    running build_ext    \n    building 'sc_86e98826b65b047ffd2cd5f479c627f13' extension \n    c:\\gcc-2.95.2\\bin\\g++.exe -mno-cygwin -mdll -O2 -w -Wstrict-prototypes -IC:\n    \\home\\ej\\wrk\\scipy\\weave -IC:\\Python21\\Include -c C:\\DOCUME~1\\eric\\LOCAL\n    S~1\\Temp\\python21_compiled\\sc_86e98826b65b047ffd2cd5f479c627f13.cpp -o C:\\D\n    OCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b04\n    7ffd2cd5f479c627f13.o    \n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxextensions.c (C:\\DOCUME~1\\eri\n    c\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxextensions.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxsupport.cxx (C:\\DOCUME~1\\eric\n    \\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxsupport.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\IndirectPythonInterface.cxx (C:\\\n    DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\indirectpythonin\n    terface.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxx_extensions.cxx (C:\\DOCUME~1\\\n    eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxx_extensions.o up-to-da\n    te)\n    writing C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86\n    e98826b65b047ffd2cd5f479c627f13.def\n    c:\\gcc-2.95.2\\bin\\dllwrap.exe --driver-name g++ -mno-cygwin -mdll -static -\n    -output-lib C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\l\n    ibsc_86e98826b65b047ffd2cd5f479c627f13.a --def C:\\DOCUME~1\\eric\\LOCALS~1\\Te\n    mp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f13.def \n    -s C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e9882\n    6b65b047ffd2cd5f479c627f13.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compil\n    ed\\temp\\Release\\cxxextensions.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\cxxsupport.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\indirectpythoninterface.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\n    \\python21_compiled\\temp\\Release\\cxx_extensions.o -LC:\\Python21\\libs -lpytho\n    n21 -o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\sc_86e98826b65b047f\n    fd2cd5f479c627f13.pyd\n    15\n
              \n\nThat's quite a bit of output. verbose=1 just prints the compile\ntime.\n\n 
              \n    >>>inline(code,['a'],compiler='gcc',verbose=1,force=1)\n    Compiling code...\n    finished compiling (sec):  6.00800001621\n    15\n
              \n\n

              \n Note: I've only used the compiler option for switching between 'msvc'\nand 'gcc' on windows. It may have use on Unix also, but I don't know yet.\n\n\n

              \nThe support_code argument is likely to be used a lot. It allows \nyou to specify extra code fragments such as function, structure or class \ndefinitions that you want to use in the code string. Note that \nchanges to support_code do not force a recompile. The \ncatalog only relies on code (for performance reasons) to determine \nwhether recompiling is necessary. So, if you make a change to support_code, \nyou'll need to alter code in some way or use the \nforce argument to get the code to recompile. I usually just add \nsome inocuous whitespace to the end of one of the lines in code \nsomewhere. Here's an example of defining a separate method for calculating\nthe string length:\n\n 

              \n    >>> from weave import inline\n    >>> a = 'a longer string'\n    >>> support_code = \"\"\"\n    ...                PyObject* length(Py::String a)\n    ...                {\n    ...                    int l = a.length();  \n    ...                    return Py::new_reference_to(Py::Int(l)); \n    ...                }\n    ...                \"\"\"        \n    >>> inline(\"return_val = length(a);\",['a'],\n    ...        support_code = support_code)\n    15\n
              \n

              \ncustomize is a left over from a previous way of specifying \ncompiler options. It is a custom_info object that can specify \nquite a bit of information about how a file is compiled. These \ninfo objects are the standard way of defining compile information \nfor type conversion classes. However, I don't think they are as handy here, \nespecially since we've exposed all the keyword arguments that distutils can \nhandle. Between these keywords, and the support_code option, I \nthink customize may be obsolete. We'll see if anyone cares to use \nit. If not, it'll get axed in the next version.\n

              \nThe type_factories variable is important to people who want to\ncustomize the way arguments are converted from Python to C. We'll talk about\nthis in the next chapter **xx** of this document when we discuss type\nconversions.\n

              \nauto_downcast handles one of the big type conversion issues that\nis common when using Numeric arrays in conjunction with Python scalar values.\nIf you have an array of single precision values and multiply that array by a \nPython scalar, the result is upcast to a double precision array because the\nscalar value is double precision. This is not usually the desired behavior\nbecause it can double your memory usage. auto_downcast goes\nsome distance towards changing the casting precedence of arrays and scalars.\nIf your only using single precision arrays, it will automatically downcast all\nscalar values from double to single precision when they are passed into the\nC++ code. This is the default behavior. If you want all values to keep there\ndefault type, set auto_downcast to 0.\n

              \n\n\n\n

              Returning Values

              \n\nPython variables in the local and global scope transfer seemlessly from Python \ninto the C++ snippets. And, if inline were to completely live up\nto its name, any modifications to variables in the C++ code would be reflected\nin the Python variables when control was passed back to Python. For example,\nthe desired behavior would be something like:\n\n 
              \n    # THIS DOES NOT WORK\n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    2\n
              \n\nInstead you get:\n\n 
              \n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    1\n
              \n \nVariables are passed into C++ as if you are calling a Python function. Python's \ncalling convention is sometimes called \"pass by assignment\". This means its as \nif a c_a = a assignment is made right before inline \ncall is made and the c_a variable is used within the C++ code. \nThus, any changes made to c_a are not reflected in Python's \na variable. Things do get a little more confusing, however, when \nlooking at variables with mutable types. Changes made in C++ to the contents \nof mutable types are reflected in the Python variables.\n\n 
              \n    >>> a= [1,2]\n    >>> weave.inline(\"PyList_SetItem(a.ptr(),0,PyInt_FromLong(3));\",['a'])\n    >>> print a\n    [3, 2]\n
              \n\nSo modifications to the contents of mutable types in C++ are seen when control\nis returned to Python. Modifications to immutable types such as tuples,\nstrings, and numbers do not alter the Python variables.\n\nIf you need to make changes to an immutable variable, you'll need to assign\nthe new value to the \"magic\" variable return_val in C++. This\nvalue is returned by the inline() function:\n\n 
              \n    >>> a = 1\n    >>> a = weave.inline(\"return_val = Py::new_reference_to(Py::Int(a+1));\",['a'])  \n    >>> a\n    2\n
              \n\nThe return_val variable can also be used to return newly created \nvalues. This is possible by returning a tuple. The following trivial example \nillustrates how this can be done:\n\n 
                     \n    # python version\n    def multi_return():\n        return 1, '2nd'\n    \n    # C version.\n    def c_multi_return():    \n        code =  \"\"\"\n     \t        Py::Tuple results(2);\n     \t        results[0] = Py::Int(1);\n     \t        results[1] = Py::String(\"2nd\");\n     \t        return_val = Py::new_reference_to(results); \t        \n                \"\"\"\n        return inline_tools.inline(code)\n
              \n

              \nThe example is available in examples/tuple_return.py. It also\nhas the dubious honor of demonstrating how much inline() can \nslow things down. The C version here is about 10 times slower than the Python\nversion. Of course, something so trivial has no reason to be written in\nC anyway.\n\n\n

              The issue with locals()

              \n

              \ninline passes the locals() and globals() \ndictionaries from Python into the C++ function from the calling function. It \nextracts the variables that are used in the C++ code from these dictionaries, \nconverts then to C++ variables, and then calculates using them. It seems like \nit would be trivial, then, after the calculations were finished to then insert \nthe new values back into the locals() and globals() \ndictionaries so that the modified values were reflected in Python. \nUnfortunately, as pointed out by the Python manual, the locals() dictionary is \nnot writable. \n

              \n\nI suspect locals() is not writable because there are some \noptimizations done to speed lookups of the local namespace. I'm guessing local \nlookups don't always look at a dictionary to find values. Can someone \"in the \nknow\" confirm or correct this? Another thing I'd like to know is whether there \nis a way to write to the local namespace of another stack frame from C/C++. If \nso, it would be possible to have some clean up code in compiled functions that \nwrote final values of variables in C++ back to the correct Python stack frame. \nI think this goes a long way toward making inline truely live up \nto its name. I don't think we'll get to the point of creating variables in \nPython for variables created in C -- although I suppose with a C/C++ parser you \ncould do that also.\n\n

              \n\n\n

              A quick look at the code

              \n\nweave generates a C++ file holding an extension function for \neach inline code snippet. These file names are generated using \nfrom the md5 signature of the code snippet and saved to a location specified by \nthe PYTHONCOMPILED environment variable (discussed later). The cpp files are \ngenerally about 200-400 lines long and include quite a few functions to support \ntype conversions, etc. However, the actual compiled function is pretty simple. \nBelow is the familiar printf example:\n\n 
              \n    >>> import weave    \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n\nAnd here is the extension function generated by inline:\n\n 
              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        // The Py_None needs an incref before returning\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n        \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try                              \n        {                                \n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n            /* Here is the inline code */            \n            printf(\"%d\\n\",a);\n            /* I would like to fill in changed locals and globals here... */\n        }                                       \n        catch( Py::Exception& e)           \n        {                                \n            return_val =  Py::Null();    \n            exception_occured = 1;       \n        }                                 \n        if(!return_val && !exception_occured)\n        {\n                                      \n            Py_INCREF(Py_None);              \n            return_val = Py_None;            \n        }\n        /* clean up code */\n        \n        /* return */                              \n        return return_val;           \n    }                                \n
              \n\nEvery inline function takes exactly two arguments -- the local and global\ndictionaries for the current scope. All variable values are looked up out\nof these dictionaries. The lookups, along with all inline code \nexecution, are done within a C++ try block. If the variables\naren't found, or there is an error converting a Python variable to the \nappropriate type in C++, an exception is raised. The C++ exception\nis automatically converted to a Python exception by CXX and returned to Python.\n\nThe py_to_int() function illustrates how the conversions and\nexception handling works. py_to_int first checks that the given PyObject*\npointer is not NULL and is a Python integer. If all is well, it calls the\nPython API to convert the value to an int. Otherwise, it calls\nhandle_bad_type() which gathers information about what went wrong\nand then raises a CXX TypeError which returns to Python as a TypeError.\n\n 
              \n    int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\n 
              \n    void handle_bad_type(PyObject* py_obj, char* good_type, char*  var_name)\n    {\n        char msg[500];\n        sprintf(msg,\"received '%s' type instead of '%s' for variable '%s'\",\n                find_type(py_obj),good_type,var_name);\n        throw Py::TypeError(msg);\n    }\n    \n    char* find_type(PyObject* py_obj)\n    {\n        if(py_obj == NULL) return \"C NULL value\";\n        if(PyCallable_Check(py_obj)) return \"callable\";\n        if(PyString_Check(py_obj)) return \"string\";\n        if(PyInt_Check(py_obj)) return \"int\";\n        if(PyFloat_Check(py_obj)) return \"float\";\n        if(PyDict_Check(py_obj)) return \"dict\";\n        if(PyList_Check(py_obj)) return \"list\";\n        if(PyTuple_Check(py_obj)) return \"tuple\";\n        if(PyFile_Check(py_obj)) return \"file\";\n        if(PyModule_Check(py_obj)) return \"module\";\n        \n        //should probably do more interagation (and thinking) on these.\n        if(PyCallable_Check(py_obj) && PyInstance_Check(py_obj)) return \"callable\";\n        if(PyInstance_Check(py_obj)) return \"instance\"; \n        if(PyCallable_Check(py_obj)) return \"callable\";\n        return \"unkown type\";\n    }\n
              \n\nSince the inline is also executed within the try/catch\nblock, you can use CXX exceptions within your code. It is usually a bad idea\nto directly return from your code, even if an error occurs. This\nskips the clean up section of the extension function. In this simple example,\nthere isn't any clean up code, but in more complicated examples, there may\nbe some reference counting that needs to be taken care of here on converted\nvariables. To avoid this, either uses exceptions or set \nreturn_val to NULL and use if/then's to skip code\nafter errors.\n\n\n

              Technical Details

              \n

              \nThere are several main steps to using C/C++ code withing Python:\n

                \n
              1. Type conversion \n
              2. Generating C/C++ code \n
              3. Compile the code to an extension module \n
              4. Catalog (and cache) the function for future use
                5. \n
              \n

              \nItems 1 and 2 above are related, but most easily discussed separately. Type \nconversions are customizable by the user if needed. Understanding them is \npretty important for anything beyond trivial uses of inline. \nGenerating the C/C++ code is handled by ext_function and \next_module classes and . For the most part, compiling the code is \nhandled by distutils. Some customizations were needed, but they were \nrelatively minor and do not require changes to distutils itself. Cataloging is \npretty simple in concept, but surprisingly required the most code to implement \n(and still likely needs some work). So, this section covers items 1 and 4 from \nthe list. Item 2 is covered later in the chapter covering the \next_tools module, and distutils is covered by a completely \nseparate document xxx.\n\n

              Passing Variables in/out of the C/C++ code

              \n\nNote: Passing variables into the C code is pretty straight forward, but there \nare subtlties to how variable modifications in C are returned to Python. see Returning Values for a more thorough discussion of \nthis issue.\n \n \n\n

              Type Conversions

              \n\n\nNote: Maybe xxx_converter instead of \nxxx_specification is a more descriptive name. Might change in \nfuture version?\n\n\n

              \nBy default, inline() makes the following type conversions between\nPython and C++ types.\n

              \n\n

              \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
              \n

              Default Data Type Conversions

              \n

              Python

              		\n

              C++

                 int   int
                 float   double
                 complex   std::complex
                 string   Py::String
                 list   Py::List
                 dict   Py::Dict
                 tuple   Py::Tuple
                 file   FILE*
                 callable   PyObject*
                 instance   PyObject*
                 Numeric.array   PyArrayObject*
                 wxXXX   wxXXX*
              \n
              \n

              \nThe Py:: namespace is defined by the \nCXX library which has C++ class\nequivalents for many Python types. std:: is the namespace of the\nstandard library in C++.\n

              \n\nNote: \n

                \n
              • I haven't figured out how to handle long int yet (I think they are currenlty converted \n to int - - check this). \n \n
              • \nHopefully VTK will be added to the list soon
                • \n
              \n\n

              \n\nPython to C++ conversions fill in code in several locations in the generated\ninline extension function. Below is the basic template for the\nfunction. This is actually the exact code that is generated by calling\nweave.inline(\"\").\n\n 

              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n    \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try\n        {\n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            /* argument conversion code */\n            /* inline code */\n            /*I would like to fill in changed locals and globals here...*/\n    \n        }\n        catch( Py::Exception& e)\n        {\n            return_val =  Py::Null();\n            exception_occured = 1;\n        }\n        /* cleanup code */\n        if(!return_val && !exception_occured)\n        {\n    \n            Py_INCREF(Py_None);\n            return_val = Py_None;\n        }\n    \n        return return_val;\n    }\n
              \n\nThe /* inline code */ section is filled with the code passed to\nthe inline() function call. The \n/*argument convserion code*/ and /* cleanup code */\nsections are filled with code that handles conversion from Python to C++\ntypes and code that deallocates memory or manipulates reference counts before\nthe function returns. The following sections demostrate how these two areas\nare filled in by the default conversion methods.\n\n \nNote: I'm not sure I have reference counting correct on a few of these. The \nonly thing I increase/decrease the ref count on is Numeric arrays. If you\nsee an issue, please let me know.\n\n\n\n

              Numeric Argument Conversion

              \n\nInteger, floating point, and complex arguments are handled in a very similar\nfashion. Consider the following inline function that has a single integer \nvariable passed in:\n\n 
              \n    >>> a = 1\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_int() has the following\nform:\n\n 
              \n    static int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\nSimilarly, the float and complex conversion routines look like:\n\n 
                  \n    static double py_to_float(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyFloat_Check(py_obj))\n            handle_bad_type(py_obj,\"float\", name);\n        return PyFloat_AsDouble(py_obj);\n    }\n    \n    static std::complex py_to_complex(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyComplex_Check(py_obj))\n            handle_bad_type(py_obj,\"complex\", name);\n        return std::complex(PyComplex_RealAsDouble(py_obj),\n                                    PyComplex_ImagAsDouble(py_obj));    \n    }\n
              \n\nNumeric conversions do not require any clean up code.\n\n\n

              String, List, Tuple, and Dictionary Conversion

              \n\nStrings, Lists, Tuples and Dictionary conversions are all converted to \nCXX types by default.\n\nFor the following code, \n\n 
              \n    >>> a = [1]\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    Py::List a = py_to_list (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_list() and its\nfriends has the following form:\n\n 
                  \n    static Py::List py_to_list(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyList_Check(py_obj))\n            handle_bad_type(py_obj,\"list\", name);\n        return Py::List(py_obj);\n    }\n    \n    static Py::String py_to_string(PyObject* py_obj,char* name)\n    {\n        if (!PyString_Check(py_obj))\n            handle_bad_type(py_obj,\"string\", name);\n        return Py::String(py_obj);\n    }\n\n    static Py::Dict py_to_dict(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyDict_Check(py_obj))\n            handle_bad_type(py_obj,\"dict\", name);\n        return Py::Dict(py_obj);\n    }\n    \n    static Py::Tuple py_to_tuple(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyTuple_Check(py_obj))\n            handle_bad_type(py_obj,\"tuple\", name);\n        return Py::Tuple(py_obj);\n    }\n
              \n\nCXX handles reference counts on for strings, lists, tuples, and dictionaries,\nso clean up code isn't necessary.\n\n\n

              File Conversion

              \n\nFor the following code, \n\n 
              \n    >>> a = open(\"bob\",'w')  \n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code is:\n\n 
              \n    /* argument conversion code */\n    PyObject* py_a = get_variable(\"a\",raw_locals,raw_globals);\n    FILE* a = py_to_file(py_a,\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_file() converts\nPyObject* to a FILE* and increments the reference count of the PyObject*:\n\n 
              \n    FILE* py_to_file(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"file\", name);\n    \n        Py_INCREF(py_obj);\n        return PyFile_AsFile(py_obj);\n    }\n
              \n\nBecause the PyObject* was incremented, the clean up code needs to decrement\nthe counter\n\n 
              \n    /* cleanup code */\n    Py_XDECREF(py_a);\n
              \n\nIts important to understand that file conversion only works on actual files --\ni.e. ones created using the open() command in Python. It does\nnot support converting arbitrary objects that support the file interface into\nC FILE* pointers. This can affect many things. For example, in\ninitial printf() examples, one might be tempted to solve the \nproblem of C and Python IDE's (PythonWin, PyCrust, etc.) writing to different\nstdout and stderr by using fprintf() and passing in \nsys.stdout and sys.stderr. For example, instead of\n\n 
              \n    >>> weave.inline('printf(\"hello\\\\n\");')\n
              \n \nYou might try:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n
              \n\nThis will work as expected from a standard python interpreter, but in PythonWin,\nthe following occurs:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n    Traceback (most recent call last):\n        File \"\", line 1, in ?\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 315, in inline\n            auto_downcast = auto_downcast,\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 386, in compile_function\n            type_factories = type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 197, in __init__\n            auto_downcast, type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 390, in assign_variable_types\n            raise TypeError, format_error_msg(errors)\n        TypeError: {'buf': \"Unable to convert variable 'buf' to a C++ type.\"}\n
              \n\nThe traceback tells us that inline() was unable to convert 'buf' to a\nC++ type (If instance conversion was implemented, the error would have occurred at \nruntime instead). Why is this? Let's look at what the buf object \nreally is:\n\n 
              \n    >>> buf\n    pywin.framework.interact.InteractiveView instance at 00EAD014\n
              \n\nPythonWin has reassigned sys.stdout to a special object that \nimplements the Python file interface. This works great in Python, but since \nthe special object doesn't have a FILE* pointer underlying it, fprintf doesn't \nknow what to do with it (well this will be the problem when instance conversion \nis implemented...).\n\n\n

              Callable, Instance, and Module Conversion

              \n\nNote: Need to look into how ref counts should be handled. Also,\nInstance and Module conversion are not currently implemented.\n\n\n 
              \n    >>> def a(): \n        pass\n    >>> inline(\"\",['a'])\n
              \n\nCallable and instance variables are converted to PyObject*. Nothing is done\nto there reference counts.\n\n 
              \n    /* argument conversion code */\n    PyObject* a = py_to_callable(get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. The py_to_callable() and\npy_to_instance() don't currently increment the ref count.\n\n 
                  \n    PyObject* py_to_callable(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyCallable_Check(py_obj))\n            handle_bad_type(py_obj,\"callable\", name);    \n        return py_obj;\n    }\n\n    PyObject* py_to_instance(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"instance\", name);    \n        return py_obj;\n    }\n
              \n \nThere is no cleanup code for callables, modules, or instances.\n\n\n

              Customizing Conversions

              \n

              \nConverting from Python to C++ types is handled by xxx_specification classes. A \ntype specification class actually serve in two related but different \nroles. The first is in determining whether a Python variable that needs to be \nconverted should be represented by the given class. The second is as a code \ngenerator that generate C++ code needed to convert from Python to C++ types for \na specific variable.\n

              \nWhen \n\n 

              \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\",a);',['a'])\n
              \n \nis called for the first time, the code snippet has to be compiled. In this \nprocess, the variable 'a' is tested against a list of type specifications (the \ndefault list is stored in weave/ext_tools.py). The first \nspecification in the list is used to represent the variable. \n\n

              \nExamples of xxx_specification are scattered throughout numerous \n\"xxx_spec.py\" files in the weave package. Closely related to \nthe xxx_specification classes are yyy_info classes. \nThese classes contain compiler, header, and support code information necessary \nfor including a certain set of capabilities (such as blitz++ or CXX support)\nin a compiled module. xxx_specification classes have one or more\nyyy_info classes associated with them.\n\nIf you'd like to define your own set of type specifications, the current best route\nis to examine some of the existing spec and info files. Maybe looking over\nsequence_spec.py and cxx_info.py are a good place to start. After defining \nspecification classes, you'll need to pass them into inline using the \ntype_factories argument. \n\nA lot of times you may just want to change how a specific variable type is \nrepresented. Say you'd rather have Python strings converted to \nstd::string or maybe char* instead of using the CXX \nstring object, but would like all other type conversions to have default \nbehavior. This requires that a new specification class that handles strings\nis written and then prepended to a list of the default type specifications. Since\nit is closer to the front of the list, it effectively overrides the default\nstring specification.\n\nThe following code demonstrates how this is done:\n\n...\n\n\n

              The Catalog

              \n

              \ncatalog.py has a class called catalog that helps keep \ntrack of previously compiled functions. This prevents inline() \nand related functions from having to compile functions everytime they are \ncalled. Instead, catalog will check an in memory cache to see if the function \nhas already been loaded into python. If it hasn't, then it starts searching \nthrough persisent catalogs on disk to see if it finds an entry for the given \nfunction. By saving information about compiled functions to disk, it isn't\nnecessary to re-compile functions everytime you stop and restart the interpreter.\nFunctions are compiled once and stored for future use.\n\n

              \nWhen inline(cpp_code) is called the following things happen:\n

                \n
              1. \n A fast local cache of functions is checked for the last function called for \n cpp_code. If an entry for cpp_code doesn't exist in the \n cache or the cached function call fails (perhaps because the function doesn't \n have compatible types) then the next step is to check the catalog. \n
              2. \n The catalog class also keeps an in-memory cache with a list of all the \n functions compiled for cpp_code. If cpp_code has\n ever been called, then this cache will be present (loaded from disk). If\n the cache isn't present, then it is loaded from disk.\n

                \n If the cache is present, each function in the cache is \n called until one is found that was compiled for the correct argument types. If \n none of the functions work, a new function is compiled with the given argument \n types. This function is written to the on-disk catalog as well as into the \n in-memory cache.

                \n
              3. \n When a lookup for cpp_code fails, the catalog looks through \n the on-disk function catalogs for the entries. The PYTHONCOMPILED variable \n determines where to search for these catalogs and in what order. If \n PYTHONCOMPILED is not present several platform dependent locations are \n searched. All functions found for cpp_code in the path are \n loaded into the in-memory cache with functions found earlier in the search \n path closer to the front of the call list.\n

                \n If the function isn't found in the on-disk catalog, \n then the function is compiled, written to the first writable directory in the \n PYTHONCOMPILED path, and also loaded into the in-memory cache.

                \n
                4. \n
              \n\n\n

              Function Storage: How functions are stored in caches and on disk

              \n

              \nFunction caches are stored as dictionaries where the key is the entire C++\ncode string and the value is either a single function (as in the \"level 1\"\ncache) or a list of functions (as in the main catalog cache). On disk\ncatalogs are stored in the same manor using standard Python shelves.\n

              \nEarly on, there was a question as to whether md5 check sums of the C++\ncode strings should be used instead of the actual code strings. I think this\nis the route inline Perl took. Some (admittedly quick) tests of the md5 vs.\nthe entire string showed that using the entire string was at least a\nfactor of 3 or 4 faster for Python. I think this is because it is more\ntime consuming to compute the md5 value than it is to do look-ups of long\nstrings in the dictionary. Look at the examples/md5_speed.py file for the\ntest run. \n\n\n

              Catalog search paths and the PYTHONCOMPILED variable

              \n

              \nThe default location for catalog files on Unix is is ~/.pythonXX_compiled where \nXX is version of Python being used. If this directory doesn't exist, it is \ncreated the first time a catalog is used. The directory must be writable. If, \nfor any reason it isn't, then the catalog attempts to create a directory based \non your user id in the /tmp directory. The directory permissions are set so \nthat only you have access to the directory. If this fails, I think you're out of \nluck. I don't think either of these should ever fail though. On Windows, a \ndirectory called pythonXX_compiled is created in the user's temporary \ndirectory. \n

              \nThe actual catalog file that lives in this directory is a Python shelve with\na platform specific name such as \"nt21compiled_catalog\" so that multiple OSes\ncan share the same file systems without trampling on each other. Along with\nthe catalog file, the .cpp and .so or .pyd files created by inline will live\nin this directory. The catalog file simply contains keys which are the C++\ncode strings with values that are lists of functions. The function lists point\nat functions within these compiled modules. Each function in the lists \nexecutes the same C++ code string, but compiled for different input variables.\n

              \nYou can use the PYTHONCOMPILED environment variable to specify alternative\nlocations for compiled functions. On Unix this is a colon (':') separated\nlist of directories. On windows, it is a (';') separated list of directories.\nThese directories will be searched prior to the default directory for a\ncompiled function catalog. Also, the first writable directory in the list\nis where all new compiled function catalogs, .cpp and .so or .pyd files are\nwritten. Relative directory paths ('.' and '..') should work fine in the\nPYTHONCOMPILED variable as should environement variables.\n

              \nThere is a \"special\" path variable called MODULE that can be placed in the \nPYTHONCOMPILED variable. It specifies that the compiled catalog should\nreside in the same directory as the module that called it. This is useful\nif an admin wants to build a lot of compiled functions during the build\nof a package and then install them in site-packages along with the package.\nUser's who specify MODULE in their PYTHONCOMPILED variable will have access\nto these compiled functions. Note, however, that if they call the function\nwith a set of argument types that it hasn't previously been built for, the\nnew function will be stored in their default directory (or some other writable\ndirectory in the PYTHONCOMPILED path) because the user will not have write\naccess to the site-packages directory.\n

              \nAn example of using the PYTHONCOMPILED path on bash follows:\n\n 

              \n    PYTHONCOMPILED=MODULE:/some/path;export PYTHONCOMPILED;\n
              \n\nIf you are using python21 on linux, and the module bob.py in site-packages\nhas a compiled function in it, then the catalog search order when calling that\nfunction for the first time in a python session would be:\n\n 
              \n    /usr/lib/python21/site-packages/linuxpython_compiled\n    /some/path/linuxpython_compiled\n    ~/.python21_compiled/linuxpython_compiled\n
              \n\nThe default location is always included in the search path.\n

              \n \nNote: hmmm. see a possible problem here. I should probably make a sub-\ndirectory such as /usr/lib/python21/site-\npackages/python21_compiled/linuxpython_compiled so that library files compiled \nwith python21 are tried to link with python22 files in some strange scenarios. \nNeed to check this.\n\n\n

              \nThe in-module cache (in weave.inline_tools reduces the overhead \nof calling inline functions by about a factor of 2. It can be reduced a little \nmore for type loop calls where the same function is called over and over again \nif the cache was a single value instead of a dictionary, but the benefit is \nvery small (less than 5%) and the utility is quite a bit less. So, we'll stick \nwith a dictionary as the cache.\n

              \n\n\n

              Blitz

              \n Note: most of this section is lifted from old documentation. It should be\npretty accurate, but there may be a few discrepancies.\n

              \nweave.blitz() compiles Numeric Python expressions for fast \nexecution. For most applications, compiled expressions should provide a \nfactor of 2-10 speed-up over Numeric arrays. Using compiled \nexpressions is meant to be as unobtrusive as possible and works much like \npythons exec statement. As an example, the following code fragment takes a 5 \npoint average of the 512x512 2d image, b, and stores it in array, a:\n\n 

              \n    from scipy import *  # or from Numeric import *\n    a = ones((512,512), Float64) \n    b = ones((512,512), Float64) \n    # ...do some stuff to fill in b...\n    # now average\n    a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] \\\n                   + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n
              \n \nTo compile the expression, convert the expression to a string by putting\nquotes around it and then use weave.blitz:\n\n 
              \n    import weave\n    expr = \"a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n                          \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n    weave.blitz(expr)\n
              \n\nThe first time weave.blitz is run for a given expression and \nset of arguements, C++ code that accomplishes the exact same task as the Python \nexpression is generated and compiled to an extension module. This can take up \nto a couple of minutes depending on the complexity of the function. Subsequent \ncalls to the function are very fast. Futher, the generated module is saved \nbetween program executions so that the compilation is only done once for a \ngiven expression and associated set of array types. If the given expression\nis executed with a new set of array types, the code most be compiled again. This\ndoes not overwrite the previously compiled function -- both of them are saved and\navailable for exectution. \n

              \nThe following table compares the run times for standard Numeric code and \ncompiled code for the 5 point averaging.\n

              \n

              \n\n\n\n\n\n
              Method Run Time (seconds)
              Standard Numeric 0.46349
              blitz (1st time compiling) 78.95526
              blitz (subsequent calls) 0.05843 (factor of 8 speedup)
              \n
              \n

              \nThese numbers are for a 512x512 double precision image run on a 400 MHz Celeron \nprocessor under RedHat Linux 6.2.\n

              \nBecause of the slow compile times, its probably most effective to develop \nalgorithms as you usually do using the capabilities of scipy or the Numeric \nmodule. Once the algorithm is perfected, put quotes around it and execute it \nusing weave.blitz. This provides the standard rapid \nprototyping strengths of Python and results in algorithms that run close to \nthat of hand coded C or Fortran.\n\n\n

              Requirements

              \n\nCurrently, the weave.blitz has only been tested under Linux \nwith gcc-2.95-3 and on Windows with Mingw32 (2.95.2). Its compiler \nrequirements are pretty heavy duty (see the \nblitz++ home page), so it won't \nwork with just any compiler. Particularly MSVC++ isn't up to snuff. A number \nof other compilers such as KAI++ will also work, but my suspicions are that gcc \nwill get the most use.\n\n\n

              Limitations

              \n
                \n
              1. \nCurrently, weave.blitz handles all standard mathematic \noperators except for the ** power operator. The built-in trigonmetric, log, \nfloor/ceil, and fabs functions might work (but haven't been tested). It also \nhandles all types of array indexing supported by the Numeric module. \n

                \nweave.blitz does not currently support operations that use \narray broadcasting, nor have any of the special purpose functions in Numeric \nsuch as take, compress, etc. been implemented. Note that there are no obvious \nreasons why most of this functionality cannot be added to scipy.weave, so it \nwill likely trickle into future versions. Using slice() objects \ndirectly instead of start:stop:step is also not supported.\n

                2. \n
              2. \nCurrently Python only works on expressions that include assignment such as\n \n 
                \n    >>> result = b + c + d\n
                \n\nThis means that the result array must exist before calling \nweave.blitz. Future versions will allow the following:\n\n 
                \n    >>> result = weave.blitz_eval(\"b + c + d\")\n
                \n
                3. \n
              3. \nweave.blitz works best when algorithms can be expressed in a \n\"vectorized\" form. Algorithms that have a large number of if/thens and other \nconditions are better hand written in C or Fortran. Further, the restrictions \nimposed by requiring vectorized expressions sometimes preclude the use of more \nefficient data structures or algorithms. For maximum speed in these cases, \nhand-coded C or Fortran code is the only way to go.\n
                4. \n
              4. \nOne other point deserves mention lest people be confused. \nweave.blitz is not a general purpose Python->C compiler. It \nonly works for expressions that contain Numeric arrays and/or \nPython scalar values. This focused scope concentrates effort on the \ncompuationally intensive regions of the program and sidesteps the difficult \nissues associated with a general purpose Python->C compiler.\n
                5. \n
              \n\n\n

              Numeric efficiency issues: What compilation buys you

              \n\nSome might wonder why compiling Numeric expressions to C++ is beneficial since \noperations on Numeric array operations are already executed within C loops. \nThe problem is that anything other than the simplest expression are executed in \nless than optimal fashion. Consider the following Numeric expression:\n\n 
              \n    a = 1.2 * b + c * d\n
              \n \nWhen Numeric calculates the value for the 2d array, a, it does \nthe following steps:\n\n 
              \n    temp1 = 1.2 * b\n    temp2 = c * d\n    a = temp1 + temp2\n
              \n \nTwo things to note. Since c is an (perhaps large) array, a large \ntemporary array must be created to store the results of 1.2 * b. \nThe same is true for temp2. Allocation is slow. The second thing \nis that we have 3 loops executing, one to calculate temp1, one for \ntemp2 and one for adding them up. A C loop for the same problem \nmight look like:\n\n 
              \n    for(int i = 0; i < M; i++)\n        for(int j = 0; j < N; j++)\n            a[i,j] = 1.2 * b[i,j] + c[i,j] * d[i,j]\n
              \n \nHere, the 3 loops have been fused into a single loop and there is no longer\na need for a temporary array. This provides a significant speed improvement\nover the above example (write me and tell me what you get). \n

              \nSo, converting Numeric expressions into C/C++ loops that fuse the loops and \neliminate temporary arrays can provide big gains. The goal then,is to convert \nNumeric expression to C/C++ loops, compile them in an extension module, and \nthen call the compiled extension function. The good news is that there is an \nobvious correspondence between the Numeric expression above and the C loop. The \nbad news is that Numeric is generally much more powerful than this simple \nexample illustrates and handling all possible indexing possibilities results in \nloops that are less than straight forward to write. (take a peak in Numeric for \nconfirmation). Luckily, there are several available tools that simplify the \nprocess.\n\n\n

              The Tools

              \n\nweave.blitz relies heavily on several remarkable tools. On the \nPython side, the main facilitators are Jermey Hylton's parser module and Jim \nHuginin's Numeric module. On the compiled language side, Todd Veldhuizen's \nblitz++ array library, written in C++ (shhhh. don't tell David Beazley), does \nthe heavy lifting. Don't assume that, because it's C++, it's much slower than C \nor Fortran. Blitz++ uses a jaw dropping array of template techniques \n(metaprogramming, template expression, etc) to convert innocent looking and \nreadable C++ expressions into to code that usually executes within a few \npercentage points of Fortran code for the same problem. This is good. \nUnfortunately all the template raz-ma-taz is very expensive to compile, so the \n200 line extension modules often take 2 or more minutes to compile. This isn't so \ngood. weave.blitz works to minimize this issue by remembering \nwhere compiled modules live and reusing them instead of re-compiling every time \na program is re-run.\n\n\n

              Parser

              \nTearing Numeric expressions apart, examining the pieces, and then rebuilding \nthem as C++ (blitz) expressions requires a parser of some sort. I can imagine \nsomeone attacking this problem with regular expressions, but it'd likely be \nugly and fragile. Amazingly, Python solves this problem for us. It actually \nexposes its parsing engine to the world through the parser module. \nThe following fragment creates an Abstract Syntax Tree (AST) object for the \nexpression and then converts to a (rather unpleasant looking) deeply nested list \nrepresentation of the tree. \n \n 
              \n    >>> import parser\n    >>> import scipy.weave.misc\n    >>> ast = parser.suite(\"a = b * c + d\")\n    >>> ast_list = ast.tolist()\n    >>> sym_list = scipy.weave.misc.translate_symbols(ast_list)\n    >>> pprint.pprint(sym_list)\n    ['file_input',\n     ['stmt',\n      ['simple_stmt',\n       ['small_stmt',\n        ['expr_stmt',\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'a']]]]]]]]]]]]]]],\n         ['EQUAL', '='],\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'b']]]],\n                    ['STAR', '*'],\n                    ['factor', ['power', ['atom', ['NAME', 'c']]]]],\n                   ['PLUS', '+'],\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'd']]]]]]]]]]]]]]]]],\n       ['NEWLINE', '']]],\n     ['ENDMARKER', '']]\n
              \n\nDespite its looks, with some tools developed by Jermey H., its possible\nto search these trees for specific patterns (sub-trees), extract the \nsub-tree, manipulate them converting python specific code fragments\nto blitz code fragments, and then re-insert it in the parse tree. The parser\nmodule documentation has some details on how to do this. Traversing the \nnew blitzified tree, writing out the terminal symbols as you go, creates\nour new blitz++ expression string.\n\n \n

              Blitz and Numeric

              \nThe other nice discovery in the project is that the data structure used\nfor Numeric arrays and blitz arrays is nearly identical. Numeric stores\n\"strides\" as byte offsets and blitz stores them as element offsets, but\nother than that, they are the same. Further, most of the concept and\ncapabilities of the two libraries are remarkably similar. It is satisfying \nthat two completely different implementations solved the problem with \nsimilar basic architectures. It is also fortitous. The work involved in \nconverting Numeric expressions to blitz expressions was greatly diminished.\nAs an example, consider the code for slicing an array in Python with a\nstride:\n\n 
              \n    >>> a = b[0:4:2] + c\n    >>> a\n    [0,2,4]\n
              \n\n\nIn Blitz it is as follows:\n\n 
              \n    Array<2,int> b(10);\n    Array<2,int> c(3);\n    // ...\n    Array<2,int> a = b(Range(0,3,2)) + c;\n
              \n\n\nHere the range object works exactly like Python slice objects with the exception\nthat the top index (3) is inclusive where as Python's (4) is exclusive. Other \ndifferences include the type declaraions in C++ and parentheses instead of \nbrackets for indexing arrays. Currently, weave.blitz handles the \ninclusive/exclusive issue by subtracting one from upper indices during the\ntranslation. An alternative that is likely more robust/maintainable in the \nlong run, is to write a PyRange class that behaves like Python's range. \nThis is likely very easy.\n

              \nThe stock blitz also doesn't handle negative indices in ranges. The current \nimplementation of the blitz() has a partial solution to this \nproblem. It calculates and index that starts with a '-' sign by subtracting it \nfrom the maximum index in the array so that:\n\n 

              \n                    upper index limit\n                        /-----\\\n    b[:-1] -> b(Range(0,Nb[0]-1-1))\n
              \n\nThis approach fails, however, when the top index is calculated from other \nvalues. In the following scenario, if i+j evaluates to a negative \nvalue, the compiled code will produce incorrect results and could even core-\ndump. Right now, all calculated indices are assumed to be positive.\n \n 
              \n    b[:i-j] -> b(Range(0,i+j))\n
              \n\nA solution is to calculate all indices up front using if/then to handle the\n+/- cases. This is a little work and results in more code, so it hasn't been\ndone. I'm holding out to see if blitz++ can be modified to handle negative\nindexing, but haven't looked into how much effort is involved yet. While it \nneeds fixin', I don't think there is a ton of code where this is an issue.\n

              \nThe actual translation of the Python expressions to blitz expressions is \ncurrently a two part process. First, all x:y:z slicing expression are removed\nfrom the AST, converted to slice(x,y,z) and re-inserted into the tree. Any\nmath needed on these expressions (subtracting from the \nmaximum index, etc.) are also preformed here. _beg and _end are used as special\nvariables that are defined as blitz::fromBegin and blitz::toEnd.\n\n 

              \n    a[i+j:i+j+1,:] = b[2:3,:] \n
              \n\nbecomes a more verbose:\n \n 
              \n    a[slice(i+j,i+j+1),slice(_beg,_end)] = b[slice(2,3),slice(_beg,_end)]\n
              \n \nThe second part does a simple string search/replace to convert to a blitz \nexpression with the following translations:\n\n 
              \n    slice(_beg,_end) -> _all  # not strictly needed, but cuts down on code.\n    slice            -> blitz::Range\n    [                -> (\n    ]                -> )\n    _stp             -> 1\n
              \n\n_all is defined in the compiled function as \nblitz::Range.all(). These translations could of course happen \ndirectly in the syntax tree. But the string replacement is slightly easier. \nNote that name spaces are maintained in the C++ code to lessen the likelyhood \nof name clashes. Currently no effort is made to detect name clashes. A good \nrule of thumb is don't use values that start with '_' or 'py_' in compiled \nexpressions and you'll be fine.\n\n \n

              Type definitions and coersion

              \n\nSo far we've glossed over the dynamic vs. static typing issue between Python \nand C++. In Python, the type of value that a variable holds can change\nthrough the course of program execution. C/C++, on the other hand, forces you\nto declare the type of value a variables will hold prior at compile time.\nweave.blitz handles this issue by examining the types of the\nvariables in the expression being executed, and compiling a function for those\nexplicit types. For example:\n\n 
              \n    a = ones((5,5),Float32)\n    b = ones((5,5),Float32)\n    weave.blitz(\"a = a + b\")\n
              \n\nWhen compiling this expression to C++, weave.blitz sees that the\nvalues for a and b in the local scope have type Float32, or 'float'\non a 32 bit architecture. As a result, it compiles the function using \nthe float type (no attempt has been made to deal with 64 bit issues).\nIt also goes one step further. If all arrays have the same type, a templated\nversion of the function is made and instantiated for float, double, \ncomplex, and complex arrays. Note: This feature has been \nremoved from the current version of the code. Each version will be compiled\nseparately \n

              \nWhat happens if you call a compiled function with array types that are \ndifferent than the ones for which it was originally compiled? No biggie, you'll \njust have to wait on it to compile a new version for your new types. This \ndoesn't overwrite the old functions, as they are still accessible. See the \ncatalog section in the inline() documentation to see how this is handled. \nSuffice to say, the mechanism is transparent to the user and behaves \nlike dynamic typing with the occasional wait for compiling newly typed \nfunctions.\n

              \nWhen working with combined scalar/array operations, the type of the array is \nalways used. This is similar to the savespace flag that was recently \nadded to Numeric. This prevents issues with the following expression perhaps \nunexpectedly being calculated at a higher (more expensive) precision that can \noccur in Python:\n\n 

              \n    >>> a = array((1,2,3),typecode = Float32)\n    >>> b = a * 2.1 # results in b being a Float64 array.\n
              \n \nIn this example, \n\n 
              \n    >>> a = ones((5,5),Float32)\n    >>> b = ones((5,5),Float32)\n    >>> weave.blitz(\"b = a * 2.1\")\n
              \n \nthe 2.1 is cast down to a float before carrying out \nthe operation. If you really want to force the calculation to be a \ndouble, define a and b as \ndouble arrays.\n

              \nOne other point of note. Currently, you must include both the right hand side \nand left hand side (assignment side) of your equation in the compiled \nexpression. Also, the array being assigned to must be created prior to calling \nweave.blitz. I'm pretty sure this is easily changed so that a \ncompiled_eval expression can be defined, but no effort has been made to \nallocate new arrays (and decern their type) on the fly.\n\n \n

              Cataloging Compiled Functions

              \n\nSee the Cataloging functions section in the \nweave.inline() documentation.\n\n \n

              Checking Array Sizes

              \n\nSurprisingly, one of the big initial problems with compiled code was making\nsure all the arrays in an operation were of compatible type. The following\ncase is trivially easy:\n\n 
              \n    a = b + c\n
              \n \nIt only requires that arrays a, b, and c \nhave the same shape. However, expressions like:\n\n 
              \n    a[i+j:i+j+1,:] = b[2:3,:] + c\n
              \n\nare not so trivial. Since slicing is involved, the size of the slices, not the \ninput arrays must be checked. Broadcasting complicates things further because \narrays and slices with different dimensions and shapes may be compatible for \nmath operations (broadcasting isn't yet supported by \nweave.blitz). Reductions have a similar effect as their \nresults are different shapes than their input operand. The binary operators in \nNumeric compare the shapes of their two operands just before they operate on \nthem. This is possible because Numeric treats each operation independently. \nThe intermediate (temporary) arrays created during sub-operations in an \nexpression are tested for the correct shape before they are combined by another \noperation. Because weave.blitz fuses all operations into a \nsingle loop, this isn't possible. The shape comparisons must be done and \nguaranteed compatible before evaluating the expression.\n

              \nThe solution chosen converts input arrays to \"dummy arrays\" that only represent \nthe dimensions of the arrays, not the data. Binary operations on dummy arrays \ncheck that input array sizes are comptible and return a dummy array with the \nsize correct size. Evaluating an expression of dummy arrays traces the \nchanging array sizes through all operations and fails if incompatible array \nsizes are ever found. \n

              \nThe machinery for this is housed in weave.size_check. It \nbasically involves writing a new class (dummy array) and overloading it math \noperators to calculate the new sizes correctly. All the code is in Python and \nthere is a fair amount of logic (mainly to handle indexing and slicing) so the \noperation does impose some overhead. For large arrays (ie. 50x50x50), the \noverhead is negligible compared to evaluating the actual expression. For small \narrays (ie. 16x16), the overhead imposed for checking the shapes with this \nmethod can cause the weave.blitz to be slower than evaluating \nthe expression in Python. \n

              \nWhat can be done to reduce the overhead? (1) The size checking code could be \nmoved into C. This would likely remove most of the overhead penalty compared \nto Numeric (although there is also some calling overhead), but no effort has \nbeen made to do this. (2) You can also call weave.blitz with\ncheck_size=0 and the size checking isn't done. However, if the \nsizes aren't compatible, it can cause a core-dump. So, foregoing size_checking\nisn't advisable until your code is well debugged.\n\n \n

              Creating the Extension Module

              \n\nweave.blitz uses the same machinery as \nweave.inline to build the extension module. The only difference\nis the code included in the function is automatically generated from the\nNumeric array expression instead of supplied by the user.\n\n\n

              Extension Modules

              \nweave.inline and weave.blitz are high level tools\nthat generate extension modules automatically. Under the covers, they use several\nclasses from weave.ext_tools to help generate the extension module.\nThe main two classes are ext_module and ext_function (I'd\nlike to add ext_class and ext_method also). These classes\nsimplify the process of generating extension modules by handling most of the \"boiler\nplate\" code automatically.\n\n\nNote: inline actually sub-classes weave.ext_tools.ext_function \nto generate slightly different code than the standard ext_function.\nThe main difference is that the standard class converts function arguments to\nC types, while inline always has two arguments, the local and global dicts, and\nthe grabs the variables that need to be convereted to C from these.\n\n\n\n

              A Simple Example

              \nThe following simple example demonstrates how to build an extension module within\na Python function:\n\n 
              \n    # examples/increment_example.py\n    from weave import ext_tools\n    \n    def build_increment_ext():\n        \"\"\" Build a simple extension with functions that increment numbers.\n            The extension will be built in the local directory.\n        \"\"\"        \n        mod = ext_tools.ext_module('increment_ext')\n    \n        a = 1 # effectively a type declaration for 'a' in the \n              # following functions.\n    \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n        mod.add_function(func)\n        \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+2));\"    \n        func = ext_tools.ext_function('increment_by_2',ext_code,['a'])\n        mod.add_function(func)\n                \n        mod.compile()\n
              \n\n\nThe function build_increment_ext() creates an extension module \nnamed increment_ext and compiles it to a shared library (.so or \n.pyd) that can be loaded into Python.. increment_ext contains two \nfunctions, increment and increment_by_2. \n\nThe first line of build_increment_ext(),\n\n 
              \n        mod = ext_tools.ext_module('increment_ext') \n
              \n\ncreates an ext_module instance that is ready to have \next_function instances added to it. ext_function \ninstances are created much with a calling convention similar to \nweave.inline(). The most common call includes a C/C++ code \nsnippet and a list of the arguments for the function. The following\n\n 
              \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n
              \n \ncreates a C/C++ extension function that is equivalent to the following Python\nfunction:\n\n 
              \n        def increment(a):\n            return a + 1\n
              \n\nA second method is also added to the module and then,\n\n 
              \n        mod.compile()\n
              \n\nis called to build the extension module. By default, the module is created\nin the current working directory.\n\nThis example is available in the examples/increment_example.py file\nfound in the weave directory. At the bottom of the file in the\nmodule's \"main\" program, an attempt to import increment_ext without\nbuilding it is made. If this fails (the module doesn't exist in the PYTHONPATH), \nthe module is built by calling build_increment_ext(). This approach\nonly takes the time consuming ( a few seconds for this example) process of building\nthe module if it hasn't been built before.\n\n 
              \n    if __name__ == \"__main__\":\n        try:\n            import increment_ext\n        except ImportError:\n            build_increment_ext()\n            import increment_ext\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\n\nNote: If we were willing to always pay the penalty of building the C++ code for \na module, we could store the md5 checksum of the C++ code along with some \ninformation about the compiler, platform, etc. Then, \next_module.compile() could try importing the module before it actually\ncompiles it, check the md5 checksum and other meta-data in the imported module\nwith the meta-data of the code it just produced and only compile the code if\nthe module didn't exist or the meta-data didn't match. This would reduce the\nabove code to:\n\n 
              \n    if __name__ == \"__main__\":\n        build_increment_ext()\n\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\nNote: There would always be the overhead of building the C++ code, but it would only actually compile the code once. You pay a little in overhead and get cleaner\n\"import\" code. Needs some thought.\n\n

              \n\nIf you run increment_example.py from the command line, you get\nthe following:\n\n 

              \n    [eric@n0]$ python increment_example.py\n    a, a+1: 1 2\n    a, a+2: 1 3\n
              \n\nIf the module didn't exist before it was run, the module is created. If it did\nexist, it is just imported and used.\n\n\n

              Fibonacci Example

              \nexamples/fibonacci.py provides a little more complex example of \nhow to use ext_tools. Fibonacci numbers are a series of numbers \nwhere each number in the series is the sum of the previous two: 1, 1, 2, 3, 5, \n8, etc. Here, the first two numbers in the series are taken to be 1. One \napproach to calculating Fibonacci numbers uses recursive function calls. In \nPython, it might be written as:\n\n 
              \n    def fib(a):\n        if a <= 2:\n            return 1\n        else:\n            return fib(a-2) + fib(a-1)\n
              \n\nIn C, the same function would look something like this:\n\n 
              \n     int fib(int a)\n     {                   \n         if(a <= 2)\n             return 1;\n         else\n             return fib(a-2) + fib(a-1);  \n     }                      \n
              \n\nRecursion is much faster in C than in Python, so it would be beneficial\nto use the C version for fibonacci number calculations instead of the\nPython version. We need an extension function that calls this C function\nto do this. This is possible by including the above code snippet as \n\"support code\" and then calling it from the extension function. Support \ncode snippets (usually structure definitions, helper functions and the like)\nare inserted into the extension module C/C++ file before the extension\nfunction code. Here is how to build the C version of the fibonacci number\ngenerator:\n\n 
              \ndef build_fibonacci():\n    \"\"\" Builds an extension module with fibonacci calculators.\n    \"\"\"\n    mod = ext_tools.ext_module('fibonacci_ext')\n    a = 1 # this is effectively a type declaration\n    \n    # recursive fibonacci in C \n    fib_code = \"\"\"\n                   int fib1(int a)\n                   {                   \n                       if(a <= 2)\n                           return 1;\n                       else\n                           return fib1(a-2) + fib1(a-1);  \n                   }                         \n               \"\"\"\n    ext_code = \"\"\"\n                   int val = fib1(a);\n                   return_val = Py::new_reference_to(Py::Int(val));\n               \"\"\"    \n    fib = ext_tools.ext_function('fib',ext_code,['a'])\n    fib.customize.add_support_code(fib_code)\n    mod.add_function(fib)\n\n    mod.compile()\n\n
              \n\nXXX More about custom_info, and what xxx_info instances are good for.\n\n

              \n\nNote: recursion is not the fastest way to calculate fibonacci numbers, but this \napproach serves nicely for this example.\n\n

              \n\n

              Customizing Type Conversions -- Type Factories

              \nnot written\n\n

              Things I wish weave did

              \n\nIt is possible to get name clashes if you uses a variable name that is already defined\nin a header automatically included (such as stdio.h) For instance, if you\ntry to pass in a variable named stdout, you'll get a cryptic error report\ndue to the fact that stdio.h also defines the name. weave\nshould probably try and handle this in some way.\n\nOther things...", "source_code_before": "\n

              Weave Documentation

              \n

              \nBy Eric Jones eric@enthought.com\n

              \n

              Outline

              \n
              \n
              Introduction\n
              Requirements\n
              Installation\n
              Testing\n
              Inline\n
              \n
              More with printf\n
              \n More examples\n
              \n
              Binary search\n
              Dictionary sort\n
              Numeric -- cast/copy/transpose\n
              wxPython
              \n
              \n
              Keyword options\n
              Returning values\n
              \n
              \n The issue with locals()
              \n
              \n
              A quick look at the code\n
              \n Technical Details\n
              \n
              Converting Types\n
              \n
              \n Numeric Argument Conversion\n
              \n String, List, Tuple, and Dictionary Conversion\n
              File Conversion \n
              \n Callable, Instance, and Module Conversion \n
              Customizing Conversions\n
              \n
              Compiling Code\n
              \"Cataloging\" functions\n
              \n
              Function Storage\n
              The PYTHONCOMPILED evnironment variable
              \n
              \n
              \n
              \n
              \n
              \n
              Blitz\n
              \n
              Requirements\n
              Limitations\n
              Numeric Efficiency Issues\n
              The Tools \n
              \n
              Parser\n
              Blitz and Numeric\n
              \n
              Type defintions and coersion\n
              Cataloging Compiled Functions\n
              Checking Array Sizes\n
              Creating the Extension Module\n
              \n
              Extension Modules\n
              \n
              A Simple Example\n
              Fibonacci Example\n
              \n
              Customizing Type Conversions -- Type Factories (not written)\n
              \n
              Type Specifications\n
              Type Information\n
              The Conversion Process \n
              \n
              \n\n

              Introduction

              \n\n

              \nThe weave package provides tools for including C/C++ code within\nin Python code. This offers both another level of optimization to those who need \nit, and an easy way to modify and extend any supported extension libraries such \nas wxPython and hopefully VTK soon. Inlining C/C++ code within Python generally\nresults in speed ups of 1.5x to 30x speed-up over algorithms written in pure\nPython (However, it is also possible to slow things down...). Generally \nalgorithms that require a large number of calls to the Python API don't benefit\nas much from the conversion to C/C++ as algorithms that have inner loops \ncompletely convertable to C.\n

              \nThere are three basic ways to use weave. The \nweave.inline() function executes C code directly within Python, \nand weave.blitz() translates Python Numeric expressions to C++ \nfor fast execution. blitz() was the original reason \nweave was built. For those interested in building extension\nlibraries, the ext_tools module provides classes for building \nextension modules within Python. \n

              \nMost of weave's functionality should work on Windows and Unix, \nalthough some of its functionality requires gcc or a similarly \nmodern C++ compiler that handles templates well. Up to now, most testing has \nbeen done on Windows 2000 with Microsoft's C++ compiler (MSVC) and with gcc \n(mingw32 2.95.2 and 2.95.3-6). All tests also pass on Linux (RH 7.1 \nwith gcc 2.96), and I've had reports that it works on Debian also (thanks \nPearu).\n

              \nThe inline and blitz provide new functionality to \nPython (although I've recently learned about the PyInline project which may offer \nsimilar functionality to inline). On the other hand, tools for \nbuilding Python extension modules already exists (SWIG, SIP, pycpp, CXX, and \nothers). As of yet, I'm not sure where weave fits in this \nspectrum. It is closest in flavor to CXX in that it makes creating new C/C++ \nextension modules pretty easy. However, if you're wrapping a gaggle of legacy \nfunctions or classes, SWIG and friends are definitely the better choice. \nweave is set up so that you can customize how Python types are \nconverted to C types in weave. This is great for \ninline(), but, for wrapping legacy code, it is more flexible to \nspecify things the other way around -- that is how C types map to Python types. \nThis weave does not do. I guess it would be possible to build \nsuch a tool on top of weave, but with good tools like SWIG around, \nI'm not sure the effort produces any new capabilities. Things like function \noverloading are probably easily implemented in weave and it might \nbe easier to mix Python/C code in function calls, but nothing beyond this comes \nto mind. So, if you're developing new extension modules or optimizing Python \nfunctions in C, weave.ext_tools() might be the tool \nfor you. If you're wrapping legacy code, stick with SWIG.\n

              \nThe next several sections give the basics of how to use weave.\nWe'll discuss what's happening under the covers in more detail later \non. Serious users will need to at least look at the type conversion section to \nunderstand how Python variables map to C/C++ types and how to customize this \nbehavior. One other note. If you don't know C or C++ then these docs are \nprobably of very little help to you. Further, it'd be helpful if you know \nsomething about writing Python extensions. weave does quite a \nbit for you, but for anything complex, you'll need to do some conversions, \nreference counting, etc.\n

              \n\nNote: weave is actually part of the SciPy package. However, it works fine as a \nstandalone package. The examples here are given as if it is used as a stand \nalone package. If you are using from within scipy, you can use from \nscipy import weave and the examples will work identically.\n\n\n

              Requirements

              \n
                \n
              • Python\n

                \n I use 2.1.1. Probably 2.0 or higher should work.\n

                \n

                • \n \n
              • C++ compiler\n

                \n weave uses distutils to actually build \n extension modules, so it uses whatever compiler was originally used to \n build Python. weave itself requires a C++ compiler. If \n you used a C++ compiler to build Python, your probably fine.\n

                \n On Unix gcc is the preferred choice because I've done a little \n testing with it. All testing has been done with gcc, but I expect the \n majority of compilers should work for inline and \n ext_tools. The one issue I'm not sure about is that I've \n hard coded things so that compilations are linked with the \n stdc++ library. Is this standard across \n Unix compilers, or is this a gcc-ism?\n

                \n For blitz(), you'll need a reasonably recent version of \n gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n versions are likely to work. Its likely that KAI's C++ compiler and \n maybe some others will work, but I haven't tried. My advise is to use \n gcc for now unless your willing to tinker with the code some.\n

                \n On Windows, either MSVC or gcc (www.mingw.org\" > mingw32) should work. Again, \n you'll need gcc for blitz() as the\n MSVC compiler doesn't handle templates well.\n

                \n I have not tried Cygwin, so please report success if it works for you.\n

                \n

                • \n\n
              • Numeric (optional)\n

                \n The python Numeric module from here. is required for \n blitz() to work. Be sure and get NumPy, not NumArray\n which is the \"next generation\" implementation. This is not\n required for using inline() or ext_tools.\n

                \n

                • \n
              • scipy_distutils and scipy_test (packaged with weave)\n

                \n These two modules are packaged with weave in both\n the windows installer and the source distributions. If you are using\n CVS, however, you'll need to download these separately (also available\n through CVS at SciPy).\n

                \n

                • \n
              \n

              \n\n\n

              Installation

              \n

              \nThere are currently two ways to get weave. Fist, \nweave is part of SciPy and installed automatically (as a sub-\npackage) whenever SciPy is installed (although the latest version isn't in \nSciPy yet, so use this one for now). Second, since weave is \nuseful outside of the scientific community, it has been setup so that it can be\nused as a stand-alone module. \n\n

              \nThe stand-alone version can be downloaded from here. Unix users should grab the \ntar ball (.tgz file) and install it using the following commands.\n\n 

              \n    tar -xzvf weave-0.2.tar.gz\n    cd weave-0.2\n    python setup.py install\n
              \n\nThis will also install two other packages, scipy_distutils and \nscipy_test. The first is needed by the setup process itself and \nboth are used in the unit-testing process. Numeric is required if you want to \nuse blitz(), but isn't necessary for inline() or \next_tools\n

              \nFor Windows users, it's even easier. You can download the click-install .exe \nfile and run it for automatic installation. There is also a .zip file of the\nsource for those interested. It also includes a setup.py file to simplify\ninstallation. \n

              \nIf you're using the CVS version, you'll need to install \nscipy_distutils and scipy_test packages (also \navailable from CVS) on your own.\n

              \n \nNote: The dependency issue here is a little sticky. I hate to make people \ndownload more than one file (and so I haven't), but distutils doesn't have a \nway to do conditional installation -- at least that I know about. This can \nlead to undesired clobbering of the scipy_test and scipy_distutils modules. \nWhat to do, what to do... Right now it is a very minor issue.\n\n

              \n\n

              Testing

              \nOnce weave is installed, fire up python and run its unit tests.\n\n 
              \n    >>> import weave\n    >>> weave.test()\n    runs long time... spews tons of output and a few warnings\n    .\n    .\n    .\n    ..............................................................\n    ................................................................\n    ..................................................\n    ----------------------------------------------------------------------\n    Ran 184 tests in 158.418s\n\n    OK\n    \n    >>> \n
              \n\nThis takes a loooong time. On windows, it is usually several minutes. On Unix \nwith remote file systems, I've had it take 15 or so minutes. In the end, it \nshould run about 180 tests and spew some speed results along the way. If you \nget errors, they'll be reported at the end of the output. Please let me know\nwhat if this occurs.\n\nIf you don't have Numeric installed, you'll get some module import errors \nduring the test setup phase for modules that are Numeric specific (blitz_spec, \nblitz_tools, size_check, standard_array_spec, ast_tools), but all test should\npass (about 100 and they should complete in several minutes).\n

              \nIf you only want to test a single module of the package, you can do this by\nrunning test() for that specific module.\n\n 

              \n    >>> import weave.scalar_spec\n    >>> weave.scalar_spec.test()\n    .......\n    ----------------------------------------------------------------------\n    Ran 7 tests in 23.284s\n
              \n\nTesting Notes:\n
                \n
              • \n Windows 1\n

                \n I've had some test fail on windows machines where I have msvc, gcc-2.95.2 \n (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My \n environment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the \n path. The test process runs very smoothly until the end where several test \n using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') \n before running tests, I get gcc-2.95.3-6. If I check after running tests \n (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] \n still has c:\\gcc first in it and is not corrupted (msvc/distutils messes \n with the environment variables, so we have to undo its work in some \n places). If anyone else sees this, let me know - - it may just be an quirk \n on my machine (unlikely). Testing with the gcc- 2.95.2 installation always \n works.\n

                \n

                • \n
              • \n Windows 2\n

                \n If you run the tests from PythonWin or some other GUI tool, you'll get a\n ton of DOS windows popping up periodically as weave spawns\n the compiler multiple times. Very annoying. Anyone know how to fix this?\n

                \n

                • \n
              • \n wxPython\n

                \n wxPython tests are not enabled by default because importing wxPython on a \n Unix machine without access to a X-term will cause the program to exit. \n Anyone know of a safe way to detect whether wxPython can be imported and \n whether a display exists on a machine? \n

                \n

                • \n                \n\n

                \n

              \n\n\n

              Inline

              \n

              \ninline() compiles and executes C/C++ code on the fly. Variables \nin the local and global Python scope are also available in the C/C++ code. \nValues are passed to the C/C++ code by assignment much like variables \nare passed into a standard Python function. Values are returned from the C/C++ \ncode through a special argument called return_val. Also, the contents of \nmutable objects can be changed within the C/C++ code and the changes remain \nafter the C code exits and returns to Python. (more on this later)\n

              \nHere's a trivial printf example using inline():\n\n 

              \n    >>> import weave    \n    >>> a  = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n

              \nIn this, its most basic form, inline(c_code, var_list) requires two \narguments. c_code is a string of valid C/C++ code. \nvar_list is a list of variable names that are passed from \nPython into C/C++. Here we have a simple printf statement that \nwrites the Python variable a to the screen. The first time you run \nthis, there will be a pause while the code is written to a .cpp file, compiled \ninto an extension module, loaded into Python, cataloged for future use, and \nexecuted. On windows (850 MHz PIII), this takes about 1.5 seconds when using \nMicrosoft's C++ compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). \nAll subsequent executions of the code will happen very quickly because the code \nonly needs to be compiled once. If you kill and restart the interpreter and then \nexecute the same code fragment again, there will be a much shorter delay in the \nfractions of seconds range. This is because weave stores a \ncatalog of all previously compiled functions in an on disk cache. When it sees \na string that has been compiled, it loads the already compiled module and \nexecutes the appropriate function. \n

              \n\nNote: If you try the printf example in a GUI shell such as IDLE, \nPythonWin, PyShell, etc., you're unlikely to see the output. This is because the \nC code is writing to stdout, instead of to the GUI window. This doesn't mean \nthat inline doesn't work in these environments -- it only means that standard \nout in C is not the same as the standard out for Python in these cases. Non \ninput/output functions will work as expected.\n\n

              \nAlthough effort has been made to reduce the overhead associated with calling \ninline, it is still less efficient for simple code snippets than using \nequivalent Python code. The simple printf example is actually \nslower by 30% or so than using Python print statement. And, it is \nnot difficult to create code fragments that are 8-10 times slower using inline \nthan equivalent Python. However, for more complicated algorithms, \nthe speed up can be worth while -- anywhwere from 1.5- 30 times faster. \nAlgorithms that have to manipulate Python objects (sorting a list) usually only \nsee a factor of 2 or so improvement. Algorithms that are highly computational \nor manipulate Numeric arrays can see much larger improvements. The \nexamples/vq.py file shows a factor of 30 or more improvement on the vector \nquantization algorithm that is used heavily in information theory and \nclassification problems.\n

              \n\n\n

              More with printf

              \n

              \nMSVC users will actually see a bit of compiler output that distutils does not\nsupress the first time the code executes:\n\n 

                  \n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    sc_e013937dbc8c647ac62438874e5795131.cpp\n       Creating library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\n       \\Release\\sc_e013937dbc8c647ac62438874e5795131.lib and object C:\\DOCUME\n       ~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_e013937dbc8c64\n       7ac62438874e5795131.exp\n    1\n
              \n

              \nNothing bad is happening, its just a bit annoying. Anyone know how to \nturn this off? \n

              \nThis example also demonstrates using 'raw strings'. The r \npreceeding the code string in the last example denotes that this is a 'raw \nstring'. In raw strings, the backslash character is not interpreted as an \nescape character, and so it isn't necessary to use a double backslash to \nindicate that the '\\n' is meant to be interpreted in the C printf \nstatement instead of by Python. If your C code contains a lot\nof strings and control characters, raw strings might make things easier.\nMost of the time, however, standard strings work just as well.\n\n

              \nThe printf statement in these examples is formatted to print \nout integers. What happens if a is a string? inline\nwill happily, compile a new version of the code to accept strings as input,\nand execute the code. The result?\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    32956972\n
              \n

              \nIn this case, the result is non-sensical, but also non-fatal. In other \nsituations, it might produce a compile time error because a is \nrequired to be an integer at some point in the code, or it could produce a \nsegmentation fault. Its possible to protect against passing \ninline arguments of the wrong data type by using asserts in \nPython.\n\n 

                  \n    >>> a = 'string'\n    >>> def protected_printf(a):    \n    ...     assert(type(a) == type(1))\n    ...     weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    >>> protected_printf(1)\n     1\n    >>> protected_printf('string')\n    AssertError...\n
              \n\n

              \nFor printing strings, the format statement needs to be changed.\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%s\\n\",a);',['a'])\n    string\n
              \n\n

              \nAs in this case, C/C++ code fragments often have to change to accept different \ntypes. For the given printing task, however, C++ streams provide a way of a \nsingle statement that works for integers and strings. By default, the stream \nobjects live in the std (standard) namespace and thus require the use of \nstd::.\n\n 

                  \n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    1    \n    >>> a = 'string'\n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    string\n
              \n \n

              \nExamples using printf and cout are included in \nexamples/print_example.py.\n\n\n

              More examples

              \n\nThis section shows several more advanced uses of inline. It \nincludes a few algorithms from the Python Cookbook \nthat have been re-written in inline C to improve speed as well as a couple \nexamples using Numeric and wxPython.\n\n\n

              Binary search

              \nLets look at the example of searching a sorted list of integers for a value. \nFor inspiration, we'll use Kalle Svensson's \nbinary_search() algorithm from the Python Cookbook. His recipe follows:\n\n 
              \n    def binary_search(seq, t):\n        min = 0; max = len(seq) - 1\n        while 1:\n            if max < min:\n                return -1\n            m = (min  + max)  / 2\n            if seq[m] < t: \n                min = m  + 1 \n            elif seq[m] > t: \n                max = m  - 1 \n            else:\n                return m    \n
              \n\nThis Python version works for arbitrary Python data types. The C version below is \nspecialized to handle integer values. There is a little type checking done in \nPython to assure that we're working with the correct data types before heading \ninto C. The variables seq and t don't need to be \ndeclared beacuse weave handles converting and declaring them in \nthe C code. All other temporary variables such as min, max, etc. \nmust be declared -- it is C after all. Here's the new mixed Python/C function:\n\n 
                  \n    def c_int_binary_search(seq,t):\n        # do a little type checking in Python\n        assert(type(t) == type(1))\n        assert(type(seq) == type([]))\n        \n        # now the C code\n        code = \"\"\"\n               #line 29 \"binary_search.py\"\n               int val, m, min = 0;  \n               int max = seq.length() - 1;\n               PyObject *py_val; \n               for(;;)\n               {\n                   if (max < min  ) \n                   { \n                       return_val =  Py::new_reference_to(Py::Int(-1)); \n                       break;\n                   } \n                   m =  (min + max) /2;\n                   val =    py_to_int(PyList_GetItem(seq.ptr(),m),\"val\"); \n                   if (val  < t) \n                       min = m  + 1;\n                   else if (val >  t)\n                       max = m - 1;\n                   else\n                   {\n                       return_val = Py::new_reference_to(Py::Int(m));\n                       break;\n                   }\n               }\n               \"\"\"\n        return inline(code,['seq','t'])\n
              \n

              \nWe have two variables seq and t passed in. \nt is guaranteed (by the assert) to be an integer. \nPython integers are converted to C int types in the transition from Python to \nC. seq is a Python list. By default, it is translated to a CXX \nlist object. Full documentation for the CXX library can be found at its website. The basics are that the CXX \nprovides C++ class equivalents for Python objects that simplify, or at \nleast object orientify, working with Python objects in C/C++. For example, \nseq.length() returns the length of the list. A little more about\nCXX and its class methods, etc. is in the ** type conversions ** section.\n

              \n\nNote: CXX uses templates and therefore may be a little less portable than \nanother alternative by Gordan McMillan called SCXX which was inspired by\nCXX. It doesn't use templates so it should compile faster and be more portable.\nSCXX has a few less features, but it appears to me that it would mesh with\nthe needs of weave quite well. Hopefully xxx_spec files will be written\nfor SCXX in the future, and we'll be able to compare on a more empirical\nbasis. Both sets of spec files will probably stick around, it just a question\nof which becomes the default.\n\n

              \nMost of the algorithm above looks similar in C to the original Python code. \nThere are two main differences. The first is the setting of \nreturn_val instead of directly returning from the C code with a \nreturn statement. return_val is an automatically \ndefined variable of type PyObject* that is returned from the C \ncode back to Python. You'll have to handle reference counting issues when \nsetting this variable. In this example, CXX classes and functions handle the \ndirty work. All CXX functions and classes live in the namespace \nPy::. The following code converts the integer m to a \nCXX Int() object and then to a PyObject* with an \nincremented reference count using Py::new_reference_to().\n\n 

                 \n    return_val = Py::new_reference_to(Py::Int(m));\n
              \n

              \nThe second big differences shows up in the retrieval of integer values from the \nPython list. The simple Python seq[i] call balloons into a C \nPython API call to grab the value out of the list and then a separate call to \npy_to_int() that converts the PyObject* to an integer. \npy_to_int() includes both a NULL cheack and a \nPyInt_Check() call as well as the conversion call. If either of \nthe checks fail, an exception is raised. The entire C++ code block is executed \nwith in a try/catch block that handles exceptions much like Python \ndoes. This removes the need for most error checking code.\n

              \nIt is worth note that CXX lists do have indexing operators that result \nin code that looks much like Python. However, the overhead in using them \nappears to be relatively high, so the standard Python API was used on the \nseq.ptr() which is the underlying PyObject* of the \nList object.\n

              \nThe #line directive that is the first line of the C code \nblock isn't necessary, but it's nice for debugging. If the compilation fails \nbecause of the syntax error in the code, the error will be reported as an error \nin the Python file \"binary_search.py\" with an offset from the given line number \n(29 here).\n

              \nSo what was all our effort worth in terms of efficiency? Well not a lot in \nthis case. The examples/binary_search.py file runs both Python and C versions \nof the functions As well as using the standard bisect module. If \nwe run it on a 1 million element list and run the search 3000 times (for 0-\n2999), here are the results we get:\n\n 

                 \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python binary_search.py\n    Binary search for 3000 items in 1000000 length list of integers:\n     speed in python: 0.159999966621\n     speed of bisect: 0.121000051498\n     speed up: 1.32\n     speed in c: 0.110000014305\n     speed up: 1.45\n     speed in c(no asserts): 0.0900000333786\n     speed up: 1.78\n
              \n

              \nSo, we get roughly a 50-75% improvement depending on whether we use the Python \nasserts in our C version. If we move down to searching a 10000 element list, \nthe advantage evaporates. Even smaller lists might result in the Python \nversion being faster. I'd like to say that moving to Numeric lists (and \ngetting rid of the GetItem() call) offers a substantial speed up, but my \npreliminary efforts didn't produce one. I think the log(N) algorithm is to \nblame. Because the algorithm is nice, there just isn't much time spent \ncomputing things, so moving to C isn't that big of a win. If there are ways to \nreduce conversion overhead of values, this may improve the C/Python speed \nup. Anyone have other explanations or faster code, please let me know.\n\n\n

              Dictionary Sort

              \n

              \nThe demo in examples/dict_sort.py is another example from the Python CookBook. \nThis \nsubmission, by Alex Martelli, demonstrates how to return the values from a \ndictionary sorted by their keys:\n\n 

                     \n    def sortedDictValues3(adict):\n        keys = adict.keys()\n        keys.sort()\n        return map(adict.get, keys)\n
              \n

              \nAlex provides 3 algorithms and this is the 3rd and fastest of the set. The C \nversion of this same algorithm follows:\n\n 

                     \n    def c_sort(adict):\n        assert(type(adict) == type({}))\n        code = \"\"\"     \n        #line 21 \"dict_sort.py\"  \n        Py::List keys = adict.keys();\n        Py::List items(keys.length()); keys.sort();     \n        PyObject* item = NULL; \n        for(int i = 0;  i < keys.length();i++)\n        {\n            item = PyList_GET_ITEM(keys.ptr(),i);\n            item = PyDict_GetItem(adict.ptr(),item);\n            Py_XINCREF(item);\n            PyList_SetItem(items.ptr(),i,item);              \n        }           \n        return_val = Py::new_reference_to(items);\n        \"\"\"   \n        return inline_tools.inline(code,['adict'],verbose=1)\n
              \n

              \nLike the original Python function, the C++ version can handle any Python \ndictionary regardless of the key/value pair types. It uses CXX objects for the \nmost part to declare python types in C++, but uses Python API calls to manipulate \ntheir contents. Again, this choice is made for speed. The C++ version, while\nmore complicated, is about a factor of 2 faster than Python.\n\n 

                     \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python dict_sort.py\n    Dict sort of 1000 items for 300 iterations:\n     speed in python: 0.319999933243\n    [0, 1, 2, 3, 4]\n     speed in c: 0.151000022888\n     speed up: 2.12\n    [0, 1, 2, 3, 4]\n
              \n

              \n\n

              Numeric -- cast/copy/transpose

              \n\nCastCopyTranspose is a function called quite heavily by Linear Algebra routines\nin the Numeric library. Its needed in part because of the row-major memory layout\nof multi-demensional Python (and C) arrays vs. the col-major order of the underlying\nFortran algorithms. For small matrices (say 100x100 or less), a significant\nportion of the common routines such as LU decompisition or singular value decompostion\nare spent in this setup routine. This shouldn't happen. Here is the Python\nversion of the function using standard Numeric operations.\n\n 
                     \n    def _castCopyAndTranspose(type, array):\n        if a.typecode() == type:\n            cast_array = copy.copy(Numeric.transpose(a))\n        else:\n            cast_array = copy.copy(Numeric.transpose(a).astype(type))\n        return cast_array\n
              \n\nAnd the following is a inline C version of the same function:\n\n 
              \n    from weave.blitz_tools import blitz_type_factories\n    from weave import scalar_spec\n    from weave import inline\n    def _cast_copy_transpose(type,a_2d):\n        assert(len(shape(a_2d)) == 2)\n        new_array = zeros(shape(a_2d),type)\n        numeric_type = scalar_spec.numeric_to_blitz_type_mapping[type]\n        code = \\\n        \"\"\"  \n        for(int i = 0;i < _Na_2d[0]; i++)  \n            for(int j = 0;  j < _Na_2d[1]; j++)\n                new_array(i,j) = (%s) a_2d(j,i);\n        \"\"\" % numeric_type\n        inline(code,['new_array','a_2d'],\n               type_factories = blitz_type_factories,compiler='gcc')\n        return new_array\n
              \n\nThis example uses blitz++ arrays instead of the standard representation of \nNumeric arrays so that indexing is simplier to write. This is accomplished by \npassing in the blitz++ \"type factories\" to override the standard Python to C++ \ntype conversions. Blitz++ arrays allow you to write clean, fast code, but they \nalso are sloooow to compile (20 seconds or more for this snippet). This is why \nthey aren't the default type used for Numeric arrays (and also because most \ncompilers can't compile blitz arrays...). inline() is also forced \nto use 'gcc' as the compiler because the default compiler on Windows (MSVC) \nwill not compile blitz code. 'gcc' I think will use the standard compiler \non Unix machine instead of explicitly forcing gcc (check this) \n\nComparisons of the Python vs inline C++ code show a factor of 3 speed up. Also \nshown are the results of an \"inplace\" transpose routine that can be used if the \noutput of the linear algebra routine can overwrite the original matrix (this is \noften appropriate). This provides another factor of 2 improvement.\n\n 
              \n     #C:\\home\\ej\\wrk\\scipy\\weave\\examples> python cast_copy_transpose.py\n    # Cast/Copy/Transposing (150,150)array 1 times\n    #  speed in python: 0.870999932289\n    #  speed in c: 0.25\n    #  speed up: 3.48\n    #  inplace transpose c: 0.129999995232\n    #  speed up: 6.70\n
              \n\n\n

              wxPython

              \n\ninline knows how to handle wxPython objects. Thats nice in and of\nitself, but it also demonstrates that the type conversion mechanism is reasonably \nflexible. Chances are, it won't take a ton of effort to support special types\nyou might have. The examples/wx_example.py borrows the scrolled window\nexample from the wxPython demo, accept that it mixes inline C code in the middle\nof the drawing function.\n\n 
              \n    def DoDrawing(self, dc):\n        \n        red = wxNamedColour(\"RED\");\n        blue = wxNamedColour(\"BLUE\");\n        grey_brush = wxLIGHT_GREY_BRUSH;\n        code = \\\n        \"\"\"\n        #line 108 \"wx_example.py\" \n        dc->BeginDrawing();\n        dc->SetPen(wxPen(*red,4,wxSOLID));\n        dc->DrawRectangle(5,5,50,50);\n        dc->SetBrush(*grey_brush);\n        dc->SetPen(wxPen(*blue,4,wxSOLID));\n        dc->DrawRectangle(15, 15, 50, 50);\n        \"\"\"\n        inline(code,['dc','red','blue','grey_brush'])\n        \n        dc.SetFont(wxFont(14, wxSWISS, wxNORMAL, wxNORMAL))\n        dc.SetTextForeground(wxColour(0xFF, 0x20, 0xFF))\n        te = dc.GetTextExtent(\"Hello World\")\n        dc.DrawText(\"Hello World\", 60, 65)\n\n        dc.SetPen(wxPen(wxNamedColour('VIOLET'), 4))\n        dc.DrawLine(5, 65+te[1], 60+te[0], 65+te[1])\n        ...\n
              \n\nHere, some of the Python calls to wx objects were just converted to C++ calls. There\nisn't any benefit, it just demonstrates the capabilities. You might want to use this\nif you have a computationally intensive loop in your drawing code that you want to \nspeed up.\n\nOn windows, you'll have to use the MSVC compiler if you use the standard wxPython\nDLLs distributed by Robin Dunn. Thats because MSVC and gcc, while binary\ncompatible in C, are not binary compatible for C++. In fact, its probably best, no \nmatter what platform you're on, to specify that inline use the same\ncompiler that was used to build wxPython to be on the safe side. There isn't currently\na way to learn this info from the library -- you just have to know. Also, at least\non the windows platform, you'll need to install the wxWindows libraries and link to \nthem. I think there is a way around this, but I haven't found it yet -- I get some\nlinking errors dealing with wxString. One final note. You'll probably have to\ntweak weave/wx_spec.py or weave/wx_info.py for your machine's configuration to\npoint at the correct directories etc. There. That should sufficiently scare people\ninto not even looking at this... :)\n\n              \n

              Keyword Options

              \n

              \nThe basic definition of the inline() function has a slew of \noptional variables. It also takes keyword arguments that are passed to \ndistutils as compiler options. The following is a formatted \ncut/paste of the argument section of inline's doc-string. It \nexplains all of the variables. Some examples using various options will \nfollow.\n\n 

                     \n    def inline(code,arg_names,local_dict = None, global_dict = None, \n               force = 0, \n               compiler='',\n               verbose = 0, \n               support_code = None,\n               customize=None, \n               type_factories = None, \n               auto_downcast=1,\n               **kw):\n
              \n\n \ninline has quite \na few options as listed below. Also, the keyword arguments for distutils \nextension modules are accepted to specify extra information needed for \ncompiling. \n
              \n

              inline Arguments:

              \n
              \n
              \n
              code
              \n \n
              \nstring. A string of valid C++ code. It should not \n specify a return statement. Instead it should assign results that need to be \n returned to Python in the return_val. \n
              \n\n
              arg_names
              \n \n
              \nlist of strings. A list of Python variable names \n that should be transferred from Python into the C/C++ code. \n
              \n\n
              local_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the local scope for the C/C++ \n code. If local_dict is not specified the local dictionary of the calling \n function is used. \n
              \n\n
              global_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the global scope for the C/C++ \n code. If global_dict is not specified the global dictionary of the calling \n function is used. \n
              \n\n
              force
              \n \n
              \noptional. 0 or 1. default 0. If 1, the C++ code is \n compiled every time inline is called. This is really only useful for \n debugging, and probably only useful if you're editing support_code a lot. \n
              \n\n
              compiler
              \n \n
              \noptional. string. The name of compiler to use when compiling. On windows, it \nunderstands 'msvc' and 'gcc' as well as all the compiler names understood by \ndistutils. On Unix, it'll only understand the values understoof by distutils. \n(I should add 'gcc' though to this).\n

              \nOn windows, the compiler defaults to the Microsoft C++ compiler. If this isn't \navailable, it looks for mingw32 (the gcc compiler).\n

              \nOn Unix, it'll probably use the same compiler that was used when compiling \nPython. Cygwin's behavior should be similar.

              \n
              \n\n
              verbose
              \n \n
              \noptional. 0,1, or 2. defualt 0. Speficies how much \n much information is printed during the compile phase of inlining code. 0 is \n silent (except on windows with msvc where it still prints some garbage). 1 \n informs you when compiling starts, finishes, and how long it took. 2 prints \n out the command lines for the compilation process and can be useful if you're \n having problems getting code to work. Its handy for finding the name of the \n .cpp file if you need to examine it. verbose has no affect if the \n compilation isn't necessary. \n
              \n\n
              support_code
              \n \n
              \noptional. string. A string of valid C++ code \n declaring extra code that might be needed by your compiled function. This \n could be declarations of functions, classes, or structures. \n
              \n\n
              customize
              \n \n
              \noptional. base_info.custom_info object. An \n alternative way to specifiy support_code, headers, etc. needed by the \n function see the weave.base_info module for more details. (not sure \n this'll be used much). \n \n
              \n
              type_factories
              \n \n
              \noptional. list of type specification factories. These guys are what convert \nPython data types to C/C++ data types. If you'd like to use a different set of \ntype conversions than the default, specify them here. Look in the type \nconversions section of the main documentation for examples.\n
              \n
              auto_downcast
              \n \n
              \noptional. 0 or 1. default 1. This only affects functions that have Numeric \narrays as input variables. Setting this to 1 will cause all floating point \nvalues to be cast as float instead of double if all the Numeric arrays are of \ntype float. If even one of the arrays has type double or double complex, all \nvariables maintain there standard types.\n
              \n
              \n
              \n\n

              Distutils keywords:

              \n
              \ninline() also accepts a number of distutils keywords \nfor controlling how the code is compiled. The following descriptions have been \ncopied from Greg Ward's distutils.extension.Extension class doc-\nstrings for convenience:\n\n
              \n
              sources
              \n \n
              \n[string] list of source filenames, relative to the \n distribution root (where the setup script lives), in Unix form \n (slash-separated) for portability. Source files may be C, C++, SWIG (.i), \n platform-specific resource files, or whatever else is recognized by the \n \"build_ext\" command as source for a Python extension. Note: The module_path \n file is always appended to the front of this list \n
              \n\n
              include_dirs
              \n \n
              \n[string] list of directories to search for C/C++ \n header files (in Unix form for portability) \n
              \n\n
              define_macros
              \n \n
              \n[(name : string, value : string|None)] list of \n macros to define; each macro is defined using a 2-tuple, where 'value' is \n either the string to define it to or None to define it without a particular \n value (equivalent of \"#define FOO\" in source or -DFOO on Unix C compiler \n command line) \n
              \n
              undef_macros
              \n \n
              \n[string] list of macros to undefine explicitly \n
              \n
              library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at link time \n
              \n
              libraries
              \n
              \n[string] list of library names (not filenames or paths) to link against \n
              \n
              runtime_library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at run time (for \nshared extensions, this is when the extension is loaded) \n
              \n\n
              extra_objects
              \n \n
              \n[string] list of extra files to link with (eg. \n object files not implied by 'sources', static library that must be \n explicitly specified, binary resource files, etc.) \n
              \n\n
              extra_compile_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when compiling the source files in 'sources'. For \n platforms and compilers where \"command line\" makes sense, this is typically \n a list of command-line arguments, but for other platforms it could be \n anything. \n
              \n
              extra_link_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when linking object files together to create the \n extension (or to create a new static Python interpreter). Similar \n interpretation as for 'extra_compile_args'. \n
              \n
              export_symbols
              \n \n
              \n[string] list of symbols to be exported from a shared extension. Not used on \nall platforms, and not generally necessary for Python extensions, which \ntypically export exactly one symbol: \"init\" + extension_name. \n
              \n
              \n
              \n\n\n

              Keyword Option Examples

              \nWe'll walk through several examples here to demonstrate the behavior of \ninline and also how the various arguments are used.\n\nIn the simplest (most) cases, code and arg_names\nare the only arguments that need to be specified. Here's a simple example\nrun on Windows machine that has Microsoft VC++ installed.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'string'\n    >>> code = \"\"\"\n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));\n    ...        \"\"\"\n    >>> inline(code,['a'])\n     sc_86e98826b65b047ffd2cd5f479c627f12.cpp\n    Creating\n       library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f12.lib\n    and object C:\\DOCUME~ 1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ff\n    d2cd5f479c627f12.exp\n    6\n    >>> inline(code,['a'])\n    6\n
              \n \nWhen inline is first run, you'll notice that pause and some \ntrash printed to the screen. The \"trash\" is acutually part of the compilers\noutput that distutils does not supress. The name of the extension file, \nsc_bighonkingnumber.cpp, is generated from the md5 check sum\nof the C/C++ code fragment. On Unix or windows machines with only\ngcc installed, the trash will not appear. On the second call, the code \nfragment is not compiled since it already exists, and only the answer is \nreturned. Now kill the interpreter and restart, and run the same code with\na different string.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'a longer string' \n    >>> code = \"\"\" \n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));  \n    ...        \"\"\"\n    >>> inline(code,['a'])\n    15\n
              \n

              \nNotice this time, inline() did not recompile the code because it\nfound the compiled function in the persistent catalog of functions. There is\na short pause as it looks up and loads the function, but it is much shorter \nthan compiling would require.\n

              \nYou can specify the local and global dictionaries if you'd like (much like \nexec or eval() in Python), but if they aren't \nspecified, the \"expected\" ones are used -- i.e. the ones from the function that \ncalled inline() . This is accomplished through a little call \nframe trickery. Here is an example where the local_dict is specified using\nthe same code example from above:\n\n 

              \n    >>> a = 'a longer string'\n    >>> b = 'an even  longer string' \n    >>> my_dict = {'a':b}\n    >>> inline(code,['a'])\n    15\n    >>> inline(code,['a'],my_dict)\n    21\n
              \n \n

              \nEverytime, the code is changed, inline does a \nrecompile. However, changing any of the other options in inline does not\nforce a recompile. The force option was added so that one\ncould force a recompile when tinkering with other variables. In practice,\nit is just as easy to change the code by a single character\n(like adding a space some place) to force the recompile. Note: It also \nmight be nice to add some methods for purging the cache and on disk \ncatalogs.\n

              \nI use verbose sometimes for debugging. When set to 2, it'll \noutput all the information (including the name of the .cpp file) that you'd\nexpect from running a make file. This is nice if you need to examine the\ngenerated code to see where things are going haywire. Note that error\nmessages from failed compiles are printed to the screen even if verbose\n is set to 0.\n

              \nThe following example demonstrates using gcc instead of the standard msvc \ncompiler on windows using same code fragment as above. Because the example has \nalready been compiled, the force=1 flag is needed to make \ninline() ignore the previously compiled version and recompile \nusing gcc. The verbose flag is added to show what is printed out:\n\n 

              \n    >>>inline(code,['a'],compiler='gcc',verbose=2,force=1)\n    running build_ext    \n    building 'sc_86e98826b65b047ffd2cd5f479c627f13' extension \n    c:\\gcc-2.95.2\\bin\\g++.exe -mno-cygwin -mdll -O2 -w -Wstrict-prototypes -IC:\n    \\home\\ej\\wrk\\scipy\\weave -IC:\\Python21\\Include -c C:\\DOCUME~1\\eric\\LOCAL\n    S~1\\Temp\\python21_compiled\\sc_86e98826b65b047ffd2cd5f479c627f13.cpp -o C:\\D\n    OCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b04\n    7ffd2cd5f479c627f13.o    \n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxextensions.c (C:\\DOCUME~1\\eri\n    c\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxextensions.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxsupport.cxx (C:\\DOCUME~1\\eric\n    \\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxsupport.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\IndirectPythonInterface.cxx (C:\\\n    DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\indirectpythonin\n    terface.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxx_extensions.cxx (C:\\DOCUME~1\\\n    eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxx_extensions.o up-to-da\n    te)\n    writing C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86\n    e98826b65b047ffd2cd5f479c627f13.def\n    c:\\gcc-2.95.2\\bin\\dllwrap.exe --driver-name g++ -mno-cygwin -mdll -static -\n    -output-lib C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\l\n    ibsc_86e98826b65b047ffd2cd5f479c627f13.a --def C:\\DOCUME~1\\eric\\LOCALS~1\\Te\n    mp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f13.def \n    -s C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e9882\n    6b65b047ffd2cd5f479c627f13.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compil\n    ed\\temp\\Release\\cxxextensions.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\cxxsupport.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\indirectpythoninterface.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\n    \\python21_compiled\\temp\\Release\\cxx_extensions.o -LC:\\Python21\\libs -lpytho\n    n21 -o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\sc_86e98826b65b047f\n    fd2cd5f479c627f13.pyd\n    15\n
              \n\nThat's quite a bit of output. verbose=1 just prints the compile\ntime.\n\n 
              \n    >>>inline(code,['a'],compiler='gcc',verbose=1,force=1)\n    Compiling code...\n    finished compiling (sec):  6.00800001621\n    15\n
              \n\n

              \n Note: I've only used the compiler option for switching between 'msvc'\nand 'gcc' on windows. It may have use on Unix also, but I don't know yet.\n\n\n

              \nThe support_code argument is likely to be used a lot. It allows \nyou to specify extra code fragments such as function, structure or class \ndefinitions that you want to use in the code string. Note that \nchanges to support_code do not force a recompile. The \ncatalog only relies on code (for performance reasons) to determine \nwhether recompiling is necessary. So, if you make a change to support_code, \nyou'll need to alter code in some way or use the \nforce argument to get the code to recompile. I usually just add \nsome inocuous whitespace to the end of one of the lines in code \nsomewhere. Here's an example of defining a separate method for calculating\nthe string length:\n\n 

              \n    >>> from weave import inline\n    >>> a = 'a longer string'\n    >>> support_code = \"\"\"\n    ...                PyObject* length(Py::String a)\n    ...                {\n    ...                    int l = a.length();  \n    ...                    return Py::new_reference_to(Py::Int(l)); \n    ...                }\n    ...                \"\"\"        \n    >>> inline(\"return_val = length(a);\",['a'],\n    ...        support_code = support_code)\n    15\n
              \n

              \ncustomize is a left over from a previous way of specifying \ncompiler options. It is a custom_info object that can specify \nquite a bit of information about how a file is compiled. These \ninfo objects are the standard way of defining compile information \nfor type conversion classes. However, I don't think they are as handy here, \nespecially since we've exposed all the keyword arguments that distutils can \nhandle. Between these keywords, and the support_code option, I \nthink customize may be obsolete. We'll see if anyone cares to use \nit. If not, it'll get axed in the next version.\n

              \nThe type_factories variable is important to people who want to\ncustomize the way arguments are converted from Python to C. We'll talk about\nthis in the next chapter **xx** of this document when we discuss type\nconversions.\n

              \nauto_downcast handles one of the big type conversion issues that\nis common when using Numeric arrays in conjunction with Python scalar values.\nIf you have an array of single precision values and multiply that array by a \nPython scalar, the result is upcast to a double precision array because the\nscalar value is double precision. This is not usually the desired behavior\nbecause it can double your memory usage. auto_downcast goes\nsome distance towards changing the casting precedence of arrays and scalars.\nIf your only using single precision arrays, it will automatically downcast all\nscalar values from double to single precision when they are passed into the\nC++ code. This is the default behavior. If you want all values to keep there\ndefault type, set auto_downcast to 0.\n

              \n\n\n\n

              Returning Values

              \n\nPython variables in the local and global scope transfer seemlessly from Python \ninto the C++ snippets. And, if inline were to completely live up\nto its name, any modifications to variables in the C++ code would be reflected\nin the Python variables when control was passed back to Python. For example,\nthe desired behavior would be something like:\n\n 
              \n    # THIS DOES NOT WORK\n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    2\n
              \n\nInstead you get:\n\n 
              \n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    1\n
              \n \nVariables are passed into C++ as if you are calling a Python function. Python's \ncalling convention is sometimes called \"pass by assignment\". This means its as \nif a c_a = a assignment is made right before inline \ncall is made and the c_a variable is used within the C++ code. \nThus, any changes made to c_a are not reflected in Python's \na variable. Things do get a little more confusing, however, when \nlooking at variables with mutable types. Changes made in C++ to the contents \nof mutable types are reflected in the Python variables.\n\n 
              \n    >>> a= [1,2]\n    >>> weave.inline(\"PyList_SetItem(a.ptr(),0,PyInt_FromLong(3));\",['a'])\n    >>> print a\n    [3, 2]\n
              \n\nSo modifications to the contents of mutable types in C++ are seen when control\nis returned to Python. Modifications to immutable types such as tuples,\nstrings, and numbers do not alter the Python variables.\n\nIf you need to make changes to an immutable variable, you'll need to assign\nthe new value to the \"magic\" variable return_val in C++. This\nvalue is returned by the inline() function:\n\n 
              \n    >>> a = 1\n    >>> a = weave.inline(\"return_val = Py::new_reference_to(Py::Int(a+1));\",['a'])  \n    >>> a\n    2\n
              \n\nThe return_val variable can also be used to return newly created \nvalues. This is possible by returning a tuple. The following trivial example \nillustrates how this can be done:\n\n 
                     \n    # python version\n    def multi_return():\n        return 1, '2nd'\n    \n    # C version.\n    def c_multi_return():    \n        code =  \"\"\"\n     \t        Py::Tuple results(2);\n     \t        results[0] = Py::Int(1);\n     \t        results[1] = Py::String(\"2nd\");\n     \t        return_val = Py::new_reference_to(results); \t        \n                \"\"\"\n        return inline_tools.inline(code)\n
              \n

              \nThe example is available in examples/tuple_return.py. It also\nhas the dubious honor of demonstrating how much inline() can \nslow things down. The C version here is about 10 times slower than the Python\nversion. Of course, something so trivial has no reason to be written in\nC anyway.\n\n\n

              The issue with locals()

              \n

              \ninline passes the locals() and globals() \ndictionaries from Python into the C++ function from the calling function. It \nextracts the variables that are used in the C++ code from these dictionaries, \nconverts then to C++ variables, and then calculates using them. It seems like \nit would be trivial, then, after the calculations were finished to then insert \nthe new values back into the locals() and globals() \ndictionaries so that the modified values were reflected in Python. \nUnfortunately, as pointed out by the Python manual, the locals() dictionary is \nnot writable. \n

              \n\nI suspect locals() is not writable because there are some \noptimizations done to speed lookups of the local namespace. I'm guessing local \nlookups don't always look at a dictionary to find values. Can someone \"in the \nknow\" confirm or correct this? Another thing I'd like to know is whether there \nis a way to write to the local namespace of another stack frame from C/C++. If \nso, it would be possible to have some clean up code in compiled functions that \nwrote final values of variables in C++ back to the correct Python stack frame. \nI think this goes a long way toward making inline truely live up \nto its name. I don't think we'll get to the point of creating variables in \nPython for variables created in C -- although I suppose with a C/C++ parser you \ncould do that also.\n\n

              \n\n\n

              A quick look at the code

              \n\nweave generates a C++ file holding an extension function for \neach inline code snippet. These file names are generated using \nfrom the md5 signature of the code snippet and saved to a location specified by \nthe PYTHONCOMPILED environment variable (discussed later). The cpp files are \ngenerally about 200-400 lines long and include quite a few functions to support \ntype conversions, etc. However, the actual compiled function is pretty simple. \nBelow is the familiar printf example:\n\n 
              \n    >>> import weave    \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n\nAnd here is the extension function generated by inline:\n\n 
              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        // The Py_None needs an incref before returning\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n        \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try                              \n        {                                \n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n            /* Here is the inline code */            \n            printf(\"%d\\n\",a);\n            /* I would like to fill in changed locals and globals here... */\n        }                                       \n        catch( Py::Exception& e)           \n        {                                \n            return_val =  Py::Null();    \n            exception_occured = 1;       \n        }                                 \n        if(!return_val && !exception_occured)\n        {\n                                      \n            Py_INCREF(Py_None);              \n            return_val = Py_None;            \n        }\n        /* clean up code */\n        \n        /* return */                              \n        return return_val;           \n    }                                \n
              \n\nEvery inline function takes exactly two arguments -- the local and global\ndictionaries for the current scope. All variable values are looked up out\nof these dictionaries. The lookups, along with all inline code \nexecution, are done within a C++ try block. If the variables\naren't found, or there is an error converting a Python variable to the \nappropriate type in C++, an exception is raised. The C++ exception\nis automatically converted to a Python exception by CXX and returned to Python.\n\nThe py_to_int() function illustrates how the conversions and\nexception handling works. py_to_int first checks that the given PyObject*\npointer is not NULL and is a Python integer. If all is well, it calls the\nPython API to convert the value to an int. Otherwise, it calls\nhandle_bad_type() which gathers information about what went wrong\nand then raises a CXX TypeError which returns to Python as a TypeError.\n\n 
              \n    int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\n 
              \n    void handle_bad_type(PyObject* py_obj, char* good_type, char*  var_name)\n    {\n        char msg[500];\n        sprintf(msg,\"received '%s' type instead of '%s' for variable '%s'\",\n                find_type(py_obj),good_type,var_name);\n        throw Py::TypeError(msg);\n    }\n    \n    char* find_type(PyObject* py_obj)\n    {\n        if(py_obj == NULL) return \"C NULL value\";\n        if(PyCallable_Check(py_obj)) return \"callable\";\n        if(PyString_Check(py_obj)) return \"string\";\n        if(PyInt_Check(py_obj)) return \"int\";\n        if(PyFloat_Check(py_obj)) return \"float\";\n        if(PyDict_Check(py_obj)) return \"dict\";\n        if(PyList_Check(py_obj)) return \"list\";\n        if(PyTuple_Check(py_obj)) return \"tuple\";\n        if(PyFile_Check(py_obj)) return \"file\";\n        if(PyModule_Check(py_obj)) return \"module\";\n        \n        //should probably do more interagation (and thinking) on these.\n        if(PyCallable_Check(py_obj) && PyInstance_Check(py_obj)) return \"callable\";\n        if(PyInstance_Check(py_obj)) return \"instance\"; \n        if(PyCallable_Check(py_obj)) return \"callable\";\n        return \"unkown type\";\n    }\n
              \n\nSince the inline is also executed within the try/catch\nblock, you can use CXX exceptions within your code. It is usually a bad idea\nto directly return from your code, even if an error occurs. This\nskips the clean up section of the extension function. In this simple example,\nthere isn't any clean up code, but in more complicated examples, there may\nbe some reference counting that needs to be taken care of here on converted\nvariables. To avoid this, either uses exceptions or set \nreturn_val to NULL and use if/then's to skip code\nafter errors.\n\n\n

              Technical Details

              \n

              \nThere are several main steps to using C/C++ code withing Python:\n

                \n
              1. Type conversion \n
              2. Generating C/C++ code \n
              3. Compile the code to an extension module \n
              4. Catalog (and cache) the function for future use
                5. \n
              \n

              \nItems 1 and 2 above are related, but most easily discussed separately. Type \nconversions are customizable by the user if needed. Understanding them is \npretty important for anything beyond trivial uses of inline. \nGenerating the C/C++ code is handled by ext_function and \next_module classes and . For the most part, compiling the code is \nhandled by distutils. Some customizations were needed, but they were \nrelatively minor and do not require changes to distutils itself. Cataloging is \npretty simple in concept, but surprisingly required the most code to implement \n(and still likely needs some work). So, this section covers items 1 and 4 from \nthe list. Item 2 is covered later in the chapter covering the \next_tools module, and distutils is covered by a completely \nseparate document xxx.\n\n

              Passing Variables in/out of the C/C++ code

              \n\nNote: Passing variables into the C code is pretty straight forward, but there \nare subtlties to how variable modifications in C are returned to Python. see Returning Values for a more thorough discussion of \nthis issue.\n \n \n\n

              Type Conversions

              \n\n\nNote: Maybe xxx_converter instead of \nxxx_specification is a more descriptive name. Might change in \nfuture version?\n\n\n

              \nBy default, inline() makes the following type conversions between\nPython and C++ types.\n

              \n\n

              \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
              \n

              Default Data Type Conversions

              \n

              Python

              		\n

              C++

                 int   int
                 float   double
                 complex   std::complex
                 string   Py::String
                 list   Py::List
                 dict   Py::Dict
                 tuple   Py::Tuple
                 file   FILE*
                 callable   PyObject*
                 instance   PyObject*
                 Numeric.array   PyArrayObject*
                 wxXXX   wxXXX*
              \n
              \n

              \nThe Py:: namespace is defined by the \nCXX library which has C++ class\nequivalents for many Python types. std:: is the namespace of the\nstandard library in C++.\n

              \n\nNote: \n

                \n
              • I haven't figured out how to handle long int yet (I think they are currenlty converted \n to int - - check this). \n \n
              • \nHopefully VTK will be added to the list soon
                • \n
              \n\n

              \n\nPython to C++ conversions fill in code in several locations in the generated\ninline extension function. Below is the basic template for the\nfunction. This is actually the exact code that is generated by calling\nweave.inline(\"\").\n\n 

              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n    \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try\n        {\n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            /* argument conversion code */\n            /* inline code */\n            /*I would like to fill in changed locals and globals here...*/\n    \n        }\n        catch( Py::Exception& e)\n        {\n            return_val =  Py::Null();\n            exception_occured = 1;\n        }\n        /* cleanup code */\n        if(!return_val && !exception_occured)\n        {\n    \n            Py_INCREF(Py_None);\n            return_val = Py_None;\n        }\n    \n        return return_val;\n    }\n
              \n\nThe /* inline code */ section is filled with the code passed to\nthe inline() function call. The \n/*argument convserion code*/ and /* cleanup code */\nsections are filled with code that handles conversion from Python to C++\ntypes and code that deallocates memory or manipulates reference counts before\nthe function returns. The following sections demostrate how these two areas\nare filled in by the default conversion methods.\n\n \nNote: I'm not sure I have reference counting correct on a few of these. The \nonly thing I increase/decrease the ref count on is Numeric arrays. If you\nsee an issue, please let me know.\n\n\n\n

              Numeric Argument Conversion

              \n\nInteger, floating point, and complex arguments are handled in a very similar\nfashion. Consider the following inline function that has a single integer \nvariable passed in:\n\n 
              \n    >>> a = 1\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_int() has the following\nform:\n\n 
              \n    static int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\nSimilarly, the float and complex conversion routines look like:\n\n 
                  \n    static double py_to_float(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyFloat_Check(py_obj))\n            handle_bad_type(py_obj,\"float\", name);\n        return PyFloat_AsDouble(py_obj);\n    }\n    \n    static std::complex py_to_complex(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyComplex_Check(py_obj))\n            handle_bad_type(py_obj,\"complex\", name);\n        return std::complex(PyComplex_RealAsDouble(py_obj),\n                                    PyComplex_ImagAsDouble(py_obj));    \n    }\n
              \n\nNumeric conversions do not require any clean up code.\n\n\n

              String, List, Tuple, and Dictionary Conversion

              \n\nStrings, Lists, Tuples and Dictionary conversions are all converted to \nCXX types by default.\n\nFor the following code, \n\n 
              \n    >>> a = [1]\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    Py::List a = py_to_list (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_list() and its\nfriends has the following form:\n\n 
                  \n    static Py::List py_to_list(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyList_Check(py_obj))\n            handle_bad_type(py_obj,\"list\", name);\n        return Py::List(py_obj);\n    }\n    \n    static Py::String py_to_string(PyObject* py_obj,char* name)\n    {\n        if (!PyString_Check(py_obj))\n            handle_bad_type(py_obj,\"string\", name);\n        return Py::String(py_obj);\n    }\n\n    static Py::Dict py_to_dict(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyDict_Check(py_obj))\n            handle_bad_type(py_obj,\"dict\", name);\n        return Py::Dict(py_obj);\n    }\n    \n    static Py::Tuple py_to_tuple(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyTuple_Check(py_obj))\n            handle_bad_type(py_obj,\"tuple\", name);\n        return Py::Tuple(py_obj);\n    }\n
              \n\nCXX handles reference counts on for strings, lists, tuples, and dictionaries,\nso clean up code isn't necessary.\n\n\n

              File Conversion

              \n\nFor the following code, \n\n 
              \n    >>> a = open(\"bob\",'w')  \n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code is:\n\n 
              \n    /* argument conversion code */\n    PyObject* py_a = get_variable(\"a\",raw_locals,raw_globals);\n    FILE* a = py_to_file(py_a,\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_file() converts\nPyObject* to a FILE* and increments the reference count of the PyObject*:\n\n 
              \n    FILE* py_to_file(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"file\", name);\n    \n        Py_INCREF(py_obj);\n        return PyFile_AsFile(py_obj);\n    }\n
              \n\nBecause the PyObject* was incremented, the clean up code needs to decrement\nthe counter\n\n 
              \n    /* cleanup code */\n    Py_XDECREF(py_a);\n
              \n\nIts important to understand that file conversion only works on actual files --\ni.e. ones created using the open() command in Python. It does\nnot support converting arbitrary objects that support the file interface into\nC FILE* pointers. This can affect many things. For example, in\ninitial printf() examples, one might be tempted to solve the \nproblem of C and Python IDE's (PythonWin, PyCrust, etc.) writing to different\nstdout and stderr by using fprintf() and passing in \nsys.stdout and sys.stderr. For example, instead of\n\n 
              \n    >>> weave.inline('printf(\"hello\\\\n\");')\n
              \n \nYou might try:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n
              \n\nThis will work as expected from a standard python interpreter, but in PythonWin,\nthe following occurs:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n    Traceback (most recent call last):\n        File \"\", line 1, in ?\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 315, in inline\n            auto_downcast = auto_downcast,\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 386, in compile_function\n            type_factories = type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 197, in __init__\n            auto_downcast, type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 390, in assign_variable_types\n            raise TypeError, format_error_msg(errors)\n        TypeError: {'buf': \"Unable to convert variable 'buf' to a C++ type.\"}\n
              \n\nThe traceback tells us that inline() was unable to convert 'buf' to a\nC++ type (If instance conversion was implemented, the error would have occurred at \nruntime instead). Why is this? Let's look at what the buf object \nreally is:\n\n 
              \n    >>> buf\n    pywin.framework.interact.InteractiveView instance at 00EAD014\n
              \n\nPythonWin has reassigned sys.stdout to a special object that \nimplements the Python file interface. This works great in Python, but since \nthe special object doesn't have a FILE* pointer underlying it, fprintf doesn't \nknow what to do with it (well this will be the problem when instance conversion \nis implemented...).\n\n\n

              Callable, Instance, and Module Conversion

              \n\nNote: Need to look into how ref counts should be handled. Also,\nInstance and Module conversion are not currently implemented.\n\n\n 
              \n    >>> def a(): \n        pass\n    >>> inline(\"\",['a'])\n
              \n\nCallable and instance variables are converted to PyObject*. Nothing is done\nto there reference counts.\n\n 
              \n    /* argument conversion code */\n    PyObject* a = py_to_callable(get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. The py_to_callable() and\npy_to_instance() don't currently increment the ref count.\n\n 
                  \n    PyObject* py_to_callable(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyCallable_Check(py_obj))\n            handle_bad_type(py_obj,\"callable\", name);    \n        return py_obj;\n    }\n\n    PyObject* py_to_instance(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"instance\", name);    \n        return py_obj;\n    }\n
              \n \nThere is no cleanup code for callables, modules, or instances.\n\n\n

              Customizing Conversions

              \n

              \nConverting from Python to C++ types is handled by xxx_specification classes. A \ntype specification class actually serve in two related but different \nroles. The first is in determining whether a Python variable that needs to be \nconverted should be represented by the given class. The second is as a code \ngenerator that generate C++ code needed to convert from Python to C++ types for \na specific variable.\n

              \nWhen \n\n 

              \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\",a);',['a'])\n
              \n \nis called for the first time, the code snippet has to be compiled. In this \nprocess, the variable 'a' is tested against a list of type specifications (the \ndefault list is stored in weave/ext_tools.py). The first \nspecification in the list is used to represent the variable. \n\n

              \nExamples of xxx_specification are scattered throughout numerous \n\"xxx_spec.py\" files in the weave package. Closely related to \nthe xxx_specification classes are yyy_info classes. \nThese classes contain compiler, header, and support code information necessary \nfor including a certain set of capabilities (such as blitz++ or CXX support)\nin a compiled module. xxx_specification classes have one or more\nyyy_info classes associated with them.\n\nIf you'd like to define your own set of type specifications, the current best route\nis to examine some of the existing spec and info files. Maybe looking over\nsequence_spec.py and cxx_info.py are a good place to start. After defining \nspecification classes, you'll need to pass them into inline using the \ntype_factories argument. \n\nA lot of times you may just want to change how a specific variable type is \nrepresented. Say you'd rather have Python strings converted to \nstd::string or maybe char* instead of using the CXX \nstring object, but would like all other type conversions to have default \nbehavior. This requires that a new specification class that handles strings\nis written and then prepended to a list of the default type specifications. Since\nit is closer to the front of the list, it effectively overrides the default\nstring specification.\n\nThe following code demonstrates how this is done:\n\n...\n\n\n

              The Catalog

              \n

              \ncatalog.py has a class called catalog that helps keep \ntrack of previously compiled functions. This prevents inline() \nand related functions from having to compile functions everytime they are \ncalled. Instead, catalog will check an in memory cache to see if the function \nhas already been loaded into python. If it hasn't, then it starts searching \nthrough persisent catalogs on disk to see if it finds an entry for the given \nfunction. By saving information about compiled functions to disk, it isn't\nnecessary to re-compile functions everytime you stop and restart the interpreter.\nFunctions are compiled once and stored for future use.\n\n

              \nWhen inline(cpp_code) is called the following things happen:\n

                \n
              1. \n A fast local cache of functions is checked for the last function called for \n cpp_code. If an entry for cpp_code doesn't exist in the \n cache or the cached function call fails (perhaps because the function doesn't \n have compatible types) then the next step is to check the catalog. \n
              2. \n The catalog class also keeps an in-memory cache with a list of all the \n functions compiled for cpp_code. If cpp_code has\n ever been called, then this cache will be present (loaded from disk). If\n the cache isn't present, then it is loaded from disk.\n

                \n If the cache is present, each function in the cache is \n called until one is found that was compiled for the correct argument types. If \n none of the functions work, a new function is compiled with the given argument \n types. This function is written to the on-disk catalog as well as into the \n in-memory cache.

                \n
              3. \n When a lookup for cpp_code fails, the catalog looks through \n the on-disk function catalogs for the entries. The PYTHONCOMPILED variable \n determines where to search for these catalogs and in what order. If \n PYTHONCOMPILED is not present several platform dependent locations are \n searched. All functions found for cpp_code in the path are \n loaded into the in-memory cache with functions found earlier in the search \n path closer to the front of the call list.\n

                \n If the function isn't found in the on-disk catalog, \n then the function is compiled, written to the first writable directory in the \n PYTHONCOMPILED path, and also loaded into the in-memory cache.

                \n
                4. \n
              \n\n\n

              Function Storage: How functions are stored in caches and on disk

              \n

              \nFunction caches are stored as dictionaries where the key is the entire C++\ncode string and the value is either a single function (as in the \"level 1\"\ncache) or a list of functions (as in the main catalog cache). On disk\ncatalogs are stored in the same manor using standard Python shelves.\n

              \nEarly on, there was a question as to whether md5 check sums of the C++\ncode strings should be used instead of the actual code strings. I think this\nis the route inline Perl took. Some (admittedly quick) tests of the md5 vs.\nthe entire string showed that using the entire string was at least a\nfactor of 3 or 4 faster for Python. I think this is because it is more\ntime consuming to compute the md5 value than it is to do look-ups of long\nstrings in the dictionary. Look at the examples/md5_speed.py file for the\ntest run. \n\n\n

              Catalog search paths and the PYTHONCOMPILED variable

              \n

              \nThe default location for catalog files on Unix is is ~/.pythonXX_compiled where \nXX is version of Python being used. If this directory doesn't exist, it is \ncreated the first time a catalog is used. The directory must be writable. If, \nfor any reason it isn't, then the catalog attempts to create a directory based \non your user id in the /tmp directory. The directory permissions are set so \nthat only you have access to the directory. If this fails, I think you're out of \nluck. I don't think either of these should ever fail though. On Windows, a \ndirectory called pythonXX_compiled is created in the user's temporary \ndirectory. \n

              \nThe actual catalog file that lives in this directory is a Python shelve with\na platform specific name such as \"nt21compiled_catalog\" so that multiple OSes\ncan share the same file systems without trampling on each other. Along with\nthe catalog file, the .cpp and .so or .pyd files created by inline will live\nin this directory. The catalog file simply contains keys which are the C++\ncode strings with values that are lists of functions. The function lists point\nat functions within these compiled modules. Each function in the lists \nexecutes the same C++ code string, but compiled for different input variables.\n

              \nYou can use the PYTHONCOMPILED environment variable to specify alternative\nlocations for compiled functions. On Unix this is a colon (':') separated\nlist of directories. On windows, it is a (';') separated list of directories.\nThese directories will be searched prior to the default directory for a\ncompiled function catalog. Also, the first writable directory in the list\nis where all new compiled function catalogs, .cpp and .so or .pyd files are\nwritten. Relative directory paths ('.' and '..') should work fine in the\nPYTHONCOMPILED variable as should environement variables.\n

              \nThere is a \"special\" path variable called MODULE that can be placed in the \nPYTHONCOMPILED variable. It specifies that the compiled catalog should\nreside in the same directory as the module that called it. This is useful\nif an admin wants to build a lot of compiled functions during the build\nof a package and then install them in site-packages along with the package.\nUser's who specify MODULE in their PYTHONCOMPILED variable will have access\nto these compiled functions. Note, however, that if they call the function\nwith a set of argument types that it hasn't previously been built for, the\nnew function will be stored in their default directory (or some other writable\ndirectory in the PYTHONCOMPILED path) because the user will not have write\naccess to the site-packages directory.\n

              \nAn example of using the PYTHONCOMPILED path on bash follows:\n\n 

              \n    PYTHONCOMPILED=MODULE:/some/path;export PYTHONCOMPILED;\n
              \n\nIf you are using python21 on linux, and the module bob.py in site-packages\nhas a compiled function in it, then the catalog search order when calling that\nfunction for the first time in a python session would be:\n\n 
              \n    /usr/lib/python21/site-packages/linuxpython_compiled\n    /some/path/linuxpython_compiled\n    ~/.python21_compiled/linuxpython_compiled\n
              \n\nThe default location is always included in the search path.\n

              \n \nNote: hmmm. see a possible problem here. I should probably make a sub-\ndirectory such as /usr/lib/python21/site-\npackages/python21_compiled/linuxpython_compiled so that library files compiled \nwith python21 are tried to link with python22 files in some strange scenarios. \nNeed to check this.\n\n\n

              \nThe in-module cache (in weave.inline_tools reduces the overhead \nof calling inline functions by about a factor of 2. It can be reduced a little \nmore for type loop calls where the same function is called over and over again \nif the cache was a single value instead of a dictionary, but the benefit is \nvery small (less than 5%) and the utility is quite a bit less. So, we'll stick \nwith a dictionary as the cache.\n

              \n\n\n

              Blitz

              \n Note: most of this section is lifted from old documentation. It should be\npretty accurate, but there may be a few discrepancies.\n

              \nweave.blitz() compiles Numeric Python expressions for fast \nexecution. For most applications, compiled expressions should provide a \nfactor of 2-10 speed-up over Numeric arrays. Using compiled \nexpressions is meant to be as unobtrusive as possible and works much like \npythons exec statement. As an example, the following code fragment takes a 5 \npoint average of the 512x512 2d image, b, and stores it in array, a:\n\n 

              \n    from scipy import *  # or from Numeric import *\n    a = ones((512,512), Float64) \n    b = ones((512,512), Float64) \n    # ...do some stuff to fill in b...\n    # now average\n    a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] \\\n                   + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n
              \n \nTo compile the expression, convert the expression to a string by putting\nquotes around it and then use weave.blitz:\n\n 
              \n    import weave\n    expr = \"a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n                          \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n    weave.blitz(expr)\n
              \n\nThe first time weave.blitz is run for a given expression and \nset of arguements, C++ code that accomplishes the exact same task as the Python \nexpression is generated and compiled to an extension module. This can take up \nto a couple of minutes depending on the complexity of the function. Subsequent \ncalls to the function are very fast. Futher, the generated module is saved \nbetween program executions so that the compilation is only done once for a \ngiven expression and associated set of array types. If the given expression\nis executed with a new set of array types, the code most be compiled again. This\ndoes not overwrite the previously compiled function -- both of them are saved and\navailable for exectution. \n

              \nThe following table compares the run times for standard Numeric code and \ncompiled code for the 5 point averaging.\n

              \n

              \n\n\n\n\n\n
              Method Run Time (seconds)
              Standard Numeric 0.46349
              blitz (1st time compiling) 78.95526
              blitz (subsequent calls) 0.05843 (factor of 8 speedup)
              \n
              \n

              \nThese numbers are for a 512x512 double precision image run on a 400 MHz Celeron \nprocessor under RedHat Linux 6.2.\n

              \nBecause of the slow compile times, its probably most effective to develop \nalgorithms as you usually do using the capabilities of scipy or the Numeric \nmodule. Once the algorithm is perfected, put quotes around it and execute it \nusing weave.blitz. This provides the standard rapid \nprototyping strengths of Python and results in algorithms that run close to \nthat of hand coded C or Fortran.\n\n\n

              Requirements

              \n\nCurrently, the weave.blitz has only been tested under Linux \nwith gcc-2.95-3 and on Windows with Mingw32 (2.95.2). Its compiler \nrequirements are pretty heavy duty (see the \nblitz++ home page), so it won't \nwork with just any compiler. Particularly MSVC++ isn't up to snuff. A number \nof other compilers such as KAI++ will also work, but my suspicions are that gcc \nwill get the most use.\n\n\n

              Limitations

              \n
                \n
              1. \nCurrently, weave.blitz handles all standard mathematic \noperators except for the ** power operator. The built-in trigonmetric, log, \nfloor/ceil, and fabs functions might work (but haven't been tested). It also \nhandles all types of array indexing supported by the Numeric module. \n

                \nweave.blitz does not currently support operations that use \narray broadcasting, nor have any of the special purpose functions in Numeric \nsuch as take, compress, etc. been implemented. Note that there are no obvious \nreasons why most of this functionality cannot be added to scipy.weave, so it \nwill likely trickle into future versions. Using slice() objects \ndirectly instead of start:stop:step is also not supported.\n

                2. \n
              2. \nCurrently Python only works on expressions that include assignment such as\n \n 
                \n    >>> result = b + c + d\n
                \n\nThis means that the result array must exist before calling \nweave.blitz. Future versions will allow the following:\n\n 
                \n    >>> result = weave.blitz_eval(\"b + c + d\")\n
                \n
                3. \n
              3. \nweave.blitz works best when algorithms can be expressed in a \n\"vectorized\" form. Algorithms that have a large number of if/thens and other \nconditions are better hand written in C or Fortran. Further, the restrictions \nimposed by requiring vectorized expressions sometimes preclude the use of more \nefficient data structures or algorithms. For maximum speed in these cases, \nhand-coded C or Fortran code is the only way to go.\n
                4. \n
              4. \nOne other point deserves mention lest people be confused. \nweave.blitz is not a general purpose Python->C compiler. It \nonly works for expressions that contain Numeric arrays and/or \nPython scalar values. This focused scope concentrates effort on the \ncompuationally intensive regions of the program and sidesteps the difficult \nissues associated with a general purpose Python->C compiler.\n
                5. \n
              \n\n\n

              Numeric efficiency issues: What compilation buys you

              \n\nSome might wonder why compiling Numeric expressions to C++ is beneficial since \noperations on Numeric array operations are already executed within C loops. \nThe problem is that anything other than the simplest expression are executed in \nless than optimal fashion. Consider the following Numeric expression:\n\n 
              \n    a = 1.2 * b + c * d\n
              \n \nWhen Numeric calculates the value for the 2d array, a, it does \nthe following steps:\n\n 
              \n    temp1 = 1.2 * b\n    temp2 = c * d\n    a = temp1 + temp2\n
              \n \nTwo things to note. Since c is an (perhaps large) array, a large \ntemporary array must be created to store the results of 1.2 * b. \nThe same is true for temp2. Allocation is slow. The second thing \nis that we have 3 loops executing, one to calculate temp1, one for \ntemp2 and one for adding them up. A C loop for the same problem \nmight look like:\n\n 
              \n    for(int i = 0; i < M; i++)\n        for(int j = 0; j < N; j++)\n            a[i,j] = 1.2 * b[i,j] + c[i,j] * d[i,j]\n
              \n \nHere, the 3 loops have been fused into a single loop and there is no longer\na need for a temporary array. This provides a significant speed improvement\nover the above example (write me and tell me what you get). \n

              \nSo, converting Numeric expressions into C/C++ loops that fuse the loops and \neliminate temporary arrays can provide big gains. The goal then,is to convert \nNumeric expression to C/C++ loops, compile them in an extension module, and \nthen call the compiled extension function. The good news is that there is an \nobvious correspondence between the Numeric expression above and the C loop. The \nbad news is that Numeric is generally much more powerful than this simple \nexample illustrates and handling all possible indexing possibilities results in \nloops that are less than straight forward to write. (take a peak in Numeric for \nconfirmation). Luckily, there are several available tools that simplify the \nprocess.\n\n\n

              The Tools

              \n\nweave.blitz relies heavily on several remarkable tools. On the \nPython side, the main facilitators are Jermey Hylton's parser module and Jim \nHuginin's Numeric module. On the compiled language side, Todd Veldhuizen's \nblitz++ array library, written in C++ (shhhh. don't tell David Beazley), does \nthe heavy lifting. Don't assume that, because it's C++, it's much slower than C \nor Fortran. Blitz++ uses a jaw dropping array of template techniques \n(metaprogramming, template expression, etc) to convert innocent looking and \nreadable C++ expressions into to code that usually executes within a few \npercentage points of Fortran code for the same problem. This is good. \nUnfortunately all the template raz-ma-taz is very expensive to compile, so the \n200 line extension modules often take 2 or more minutes to compile. This isn't so \ngood. weave.blitz works to minimize this issue by remembering \nwhere compiled modules live and reusing them instead of re-compiling every time \na program is re-run.\n\n\n

              Parser

              \nTearing Numeric expressions apart, examining the pieces, and then rebuilding \nthem as C++ (blitz) expressions requires a parser of some sort. I can imagine \nsomeone attacking this problem with regular expressions, but it'd likely be \nugly and fragile. Amazingly, Python solves this problem for us. It actually \nexposes its parsing engine to the world through the parser module. \nThe following fragment creates an Abstract Syntax Tree (AST) object for the \nexpression and then converts to a (rather unpleasant looking) deeply nested list \nrepresentation of the tree. \n \n 
              \n    >>> import parser\n    >>> import scipy.weave.misc\n    >>> ast = parser.suite(\"a = b * c + d\")\n    >>> ast_list = ast.tolist()\n    >>> sym_list = scipy.weave.misc.translate_symbols(ast_list)\n    >>> pprint.pprint(sym_list)\n    ['file_input',\n     ['stmt',\n      ['simple_stmt',\n       ['small_stmt',\n        ['expr_stmt',\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'a']]]]]]]]]]]]]]],\n         ['EQUAL', '='],\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'b']]]],\n                    ['STAR', '*'],\n                    ['factor', ['power', ['atom', ['NAME', 'c']]]]],\n                   ['PLUS', '+'],\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'd']]]]]]]]]]]]]]]]],\n       ['NEWLINE', '']]],\n     ['ENDMARKER', '']]\n
              \n\nDespite its looks, with some tools developed by Jermey H., its possible\nto search these trees for specific patterns (sub-trees), extract the \nsub-tree, manipulate them converting python specific code fragments\nto blitz code fragments, and then re-insert it in the parse tree. The parser\nmodule documentation has some details on how to do this. Traversing the \nnew blitzified tree, writing out the terminal symbols as you go, creates\nour new blitz++ expression string.\n\n \n

              Blitz and Numeric

              \nThe other nice discovery in the project is that the data structure used\nfor Numeric arrays and blitz arrays is nearly identical. Numeric stores\n\"strides\" as byte offsets and blitz stores them as element offsets, but\nother than that, they are the same. Further, most of the concept and\ncapabilities of the two libraries are remarkably similar. It is satisfying \nthat two completely different implementations solved the problem with \nsimilar basic architectures. It is also fortitous. The work involved in \nconverting Numeric expressions to blitz expressions was greatly diminished.\nAs an example, consider the code for slicing an array in Python with a\nstride:\n\n 
              \n    >>> a = b[0:4:2] + c\n    >>> a\n    [0,2,4]\n
              \n\n\nIn Blitz it is as follows:\n\n 
              \n    Array<2,int> b(10);\n    Array<2,int> c(3);\n    // ...\n    Array<2,int> a = b(Range(0,3,2)) + c;\n
              \n\n\nHere the range object works exactly like Python slice objects with the exception\nthat the top index (3) is inclusive where as Python's (4) is exclusive. Other \ndifferences include the type declaraions in C++ and parentheses instead of \nbrackets for indexing arrays. Currently, weave.blitz handles the \ninclusive/exclusive issue by subtracting one from upper indices during the\ntranslation. An alternative that is likely more robust/maintainable in the \nlong run, is to write a PyRange class that behaves like Python's range. \nThis is likely very easy.\n

              \nThe stock blitz also doesn't handle negative indices in ranges. The current \nimplementation of the blitz() has a partial solution to this \nproblem. It calculates and index that starts with a '-' sign by subtracting it \nfrom the maximum index in the array so that:\n\n 

              \n                    upper index limit\n                        /-----\\\n    b[:-1] -> b(Range(0,Nb[0]-1-1))\n
              \n\nThis approach fails, however, when the top index is calculated from other \nvalues. In the following scenario, if i+j evaluates to a negative \nvalue, the compiled code will produce incorrect results and could even core-\ndump. Right now, all calculated indices are assumed to be positive.\n \n 
              \n    b[:i-j] -> b(Range(0,i+j))\n
              \n\nA solution is to calculate all indices up front using if/then to handle the\n+/- cases. This is a little work and results in more code, so it hasn't been\ndone. I'm holding out to see if blitz++ can be modified to handle negative\nindexing, but haven't looked into how much effort is involved yet. While it \nneeds fixin', I don't think there is a ton of code where this is an issue.\n

              \nThe actual translation of the Python expressions to blitz expressions is \ncurrently a two part process. First, all x:y:z slicing expression are removed\nfrom the AST, converted to slice(x,y,z) and re-inserted into the tree. Any\nmath needed on these expressions (subtracting from the \nmaximum index, etc.) are also preformed here. _beg and _end are used as special\nvariables that are defined as blitz::fromBegin and blitz::toEnd.\n\n 

              \n    a[i+j:i+j+1,:] = b[2:3,:] \n
              \n\nbecomes a more verbose:\n \n 
              \n    a[slice(i+j,i+j+1),slice(_beg,_end)] = b[slice(2,3),slice(_beg,_end)]\n
              \n \nThe second part does a simple string search/replace to convert to a blitz \nexpression with the following translations:\n\n 
              \n    slice(_beg,_end) -> _all  # not strictly needed, but cuts down on code.\n    slice            -> blitz::Range\n    [                -> (\n    ]                -> )\n    _stp             -> 1\n
              \n\n_all is defined in the compiled function as \nblitz::Range.all(). These translations could of course happen \ndirectly in the syntax tree. But the string replacement is slightly easier. \nNote that name spaces are maintained in the C++ code to lessen the likelyhood \nof name clashes. Currently no effort is made to detect name clashes. A good \nrule of thumb is don't use values that start with '_' or 'py_' in compiled \nexpressions and you'll be fine.\n\n \n

              Type definitions and coersion

              \n\nSo far we've glossed over the dynamic vs. static typing issue between Python \nand C++. In Python, the type of value that a variable holds can change\nthrough the course of program execution. C/C++, on the other hand, forces you\nto declare the type of value a variables will hold prior at compile time.\nweave.blitz handles this issue by examining the types of the\nvariables in the expression being executed, and compiling a function for those\nexplicit types. For example:\n\n 
              \n    a = ones((5,5),Float32)\n    b = ones((5,5),Float32)\n    weave.blitz(\"a = a + b\")\n
              \n\nWhen compiling this expression to C++, weave.blitz sees that the\nvalues for a and b in the local scope have type Float32, or 'float'\non a 32 bit architecture. As a result, it compiles the function using \nthe float type (no attempt has been made to deal with 64 bit issues).\nIt also goes one step further. If all arrays have the same type, a templated\nversion of the function is made and instantiated for float, double, \ncomplex, and complex arrays. Note: This feature has been \nremoved from the current version of the code. Each version will be compiled\nseparately \n

              \nWhat happens if you call a compiled function with array types that are \ndifferent than the ones for which it was originally compiled? No biggie, you'll \njust have to wait on it to compile a new version for your new types. This \ndoesn't overwrite the old functions, as they are still accessible. See the \ncatalog section in the inline() documentation to see how this is handled. \nSuffice to say, the mechanism is transparent to the user and behaves \nlike dynamic typing with the occasional wait for compiling newly typed \nfunctions.\n

              \nWhen working with combined scalar/array operations, the type of the array is \nalways used. This is similar to the savespace flag that was recently \nadded to Numeric. This prevents issues with the following expression perhaps \nunexpectedly being calculated at a higher (more expensive) precision that can \noccur in Python:\n\n 

              \n    >>> a = array((1,2,3),typecode = Float32)\n    >>> b = a * 2.1 # results in b being a Float64 array.\n
              \n \nIn this example, \n\n 
              \n    >>> a = ones((5,5),Float32)\n    >>> b = ones((5,5),Float32)\n    >>> weave.blitz(\"b = a * 2.1\")\n
              \n \nthe 2.1 is cast down to a float before carrying out \nthe operation. If you really want to force the calculation to be a \ndouble, define a and b as \ndouble arrays.\n

              \nOne other point of note. Currently, you must include both the right hand side \nand left hand side (assignment side) of your equation in the compiled \nexpression. Also, the array being assigned to must be created prior to calling \nweave.blitz. I'm pretty sure this is easily changed so that a \ncompiled_eval expression can be defined, but no effort has been made to \nallocate new arrays (and decern their type) on the fly.\n\n \n

              Cataloging Compiled Functions

              \n\nSee the Cataloging functions section in the \nweave.inline() documentation.\n\n \n

              Checking Array Sizes

              \n\nSurprisingly, one of the big initial problems with compiled code was making\nsure all the arrays in an operation were of compatible type. The following\ncase is trivially easy:\n\n 
              \n    a = b + c\n
              \n \nIt only requires that arrays a, b, and c \nhave the same shape. However, expressions like:\n\n 
              \n    a[i+j:i+j+1,:] = b[2:3,:] + c\n
              \n\nare not so trivial. Since slicing is involved, the size of the slices, not the \ninput arrays must be checked. Broadcasting complicates things further because \narrays and slices with different dimensions and shapes may be compatible for \nmath operations (broadcasting isn't yet supported by \nweave.blitz). Reductions have a similar effect as their \nresults are different shapes than their input operand. The binary operators in \nNumeric compare the shapes of their two operands just before they operate on \nthem. This is possible because Numeric treats each operation independently. \nThe intermediate (temporary) arrays created during sub-operations in an \nexpression are tested for the correct shape before they are combined by another \noperation. Because weave.blitz fuses all operations into a \nsingle loop, this isn't possible. The shape comparisons must be done and \nguaranteed compatible before evaluating the expression.\n

              \nThe solution chosen converts input arrays to \"dummy arrays\" that only represent \nthe dimensions of the arrays, not the data. Binary operations on dummy arrays \ncheck that input array sizes are comptible and return a dummy array with the \nsize correct size. Evaluating an expression of dummy arrays traces the \nchanging array sizes through all operations and fails if incompatible array \nsizes are ever found. \n

              \nThe machinery for this is housed in weave.size_check. It \nbasically involves writing a new class (dummy array) and overloading it math \noperators to calculate the new sizes correctly. All the code is in Python and \nthere is a fair amount of logic (mainly to handle indexing and slicing) so the \noperation does impose some overhead. For large arrays (ie. 50x50x50), the \noverhead is negligible compared to evaluating the actual expression. For small \narrays (ie. 16x16), the overhead imposed for checking the shapes with this \nmethod can cause the weave.blitz to be slower than evaluating \nthe expression in Python. \n

              \nWhat can be done to reduce the overhead? (1) The size checking code could be \nmoved into C. This would likely remove most of the overhead penalty compared \nto Numeric (although there is also some calling overhead), but no effort has \nbeen made to do this. (2) You can also call weave.blitz with\ncheck_size=0 and the size checking isn't done. However, if the \nsizes aren't compatible, it can cause a core-dump. So, foregoing size_checking\nisn't advisable until your code is well debugged.\n\n \n

              Creating the Extension Module

              \n\nweave.blitz uses the same machinery as \nweave.inline to build the extension module. The only difference\nis the code included in the function is automatically generated from the\nNumeric array expression instead of supplied by the user.\n\n\n

              Extension Modules

              \nweave.inline and weave.blitz are high level tools\nthat generate extension modules automatically. Under the covers, they use several\nclasses from weave.ext_tools to help generate the extension module.\nThe main two classes are ext_module and ext_function (I'd\nlike to add ext_class and ext_method also). These classes\nsimplify the process of generating extension modules by handling most of the \"boiler\nplate\" code automatically.\n\n\nNote: inline actually sub-classes weave.ext_tools.ext_function \nto generate slightly different code than the standard ext_function.\nThe main difference is that the standard class converts function arguments to\nC types, while inline always has two arguments, the local and global dicts, and\nthe grabs the variables that need to be convereted to C from these.\n\n\n\n

              A Simple Example

              \nThe following simple example demonstrates how to build an extension module within\na Python function:\n\n 
              \n    # examples/increment_example.py\n    from weave import ext_tools\n    \n    def build_increment_ext():\n        \"\"\" Build a simple extension with functions that increment numbers.\n            The extension will be built in the local directory.\n        \"\"\"        \n        mod = ext_tools.ext_module('increment_ext')\n    \n        a = 1 # effectively a type declaration for 'a' in the \n              # following functions.\n    \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n        mod.add_function(func)\n        \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+2));\"    \n        func = ext_tools.ext_function('increment_by_2',ext_code,['a'])\n        mod.add_function(func)\n                \n        mod.compile()\n
              \n\n\nThe function build_increment_ext() creates an extension module \nnamed increment_ext and compiles it to a shared library (.so or \n.pyd) that can be loaded into Python.. increment_ext contains two \nfunctions, increment and increment_by_2. \n\nThe first line of build_increment_ext(),\n\n 
              \n        mod = ext_tools.ext_module('increment_ext') \n
              \n\ncreates an ext_module instance that is ready to have \next_function instances added to it. ext_function \ninstances are created much with a calling convention similar to \nweave.inline(). The most common call includes a C/C++ code \nsnippet and a list of the arguments for the function. The following\n\n 
              \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n
              \n \ncreates a C/C++ extension function that is equivalent to the following Python\nfunction:\n\n 
              \n        def increment(a):\n            return a + 1\n
              \n\nA second method is also added to the module and then,\n\n 
              \n        mod.compile()\n
              \n\nis called to build the extension module. By default, the module is created\nin the current working directory.\n\nThis example is available in the examples/increment_example.py file\nfound in the weave directory. At the bottom of the file in the\nmodule's \"main\" program, an attempt to import increment_ext without\nbuilding it is made. If this fails (the module doesn't exist in the PYTHONPATH), \nthe module is built by calling build_increment_ext(). This approach\nonly takes the time consuming ( a few seconds for this example) process of building\nthe module if it hasn't been built before.\n\n 
              \n    if __name__ == \"__main__\":\n        try:\n            import increment_ext\n        except ImportError:\n            build_increment_ext()\n            import increment_ext\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\n\nNote: If we were willing to always pay the penalty of building the C++ code for \na module, we could store the md5 checksum of the C++ code along with some \ninformation about the compiler, platform, etc. Then, \next_module.compile() could try importing the module before it actually\ncompiles it, check the md5 checksum and other meta-data in the imported module\nwith the meta-data of the code it just produced and only compile the code if\nthe module didn't exist or the meta-data didn't match. This would reduce the\nabove code to:\n\n 
              \n    if __name__ == \"__main__\":\n        build_increment_ext()\n\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\nNote: There would always be the overhead of building the C++ code, but it would only actually compile the code once. You pay a little in overhead and get cleaner\n\"import\" code. Needs some thought.\n\n

              \n\nIf you run increment_example.py from the command line, you get\nthe following:\n\n 

              \n    [eric@n0]$ python increment_example.py\n    a, a+1: 1 2\n    a, a+2: 1 3\n
              \n\nIf the module didn't exist before it was run, the module is created. If it did\nexist, it is just imported and used.\n\n\n

              Fibonacci Example

              \nexamples/fibonacci.py provides a little more complex example of \nhow to use ext_tools. Fibonacci numbers are a series of numbers \nwhere each number in the series is the sum of the previous two: 1, 1, 2, 3, 5, \n8, etc. Here, the first two numbers in the series are taken to be 1. One \napproach to calculating Fibonacci numbers uses recursive function calls. In \nPython, it might be written as:\n\n 
              \n    def fib(a):\n        if a <= 2:\n            return 1\n        else:\n            return fib(a-2) + fib(a-1)\n
              \n\nIn C, the same function would look something like this:\n\n 
              \n     int fib(int a)\n     {                   \n         if(a <= 2)\n             return 1;\n         else\n             return fib(a-2) + fib(a-1);  \n     }                      \n
              \n\nRecursion is much faster in C than in Python, so it would be beneficial\nto use the C version for fibonacci number calculations instead of the\nPython version. We need an extension function that calls this C function\nto do this. This is possible by including the above code snippet as \n\"support code\" and then calling it from the extension function. Support \ncode snippets (usually structure definitions, helper functions and the like)\nare inserted into the extension module C/C++ file before the extension\nfunction code. Here is how to build the C version of the fibonacci number\ngenerator:\n\n 
              \ndef build_fibonacci():\n    \"\"\" Builds an extension module with fibonacci calculators.\n    \"\"\"\n    mod = ext_tools.ext_module('fibonacci_ext')\n    a = 1 # this is effectively a type declaration\n    \n    # recursive fibonacci in C \n    fib_code = \"\"\"\n                   int fib1(int a)\n                   {                   \n                       if(a <= 2)\n                           return 1;\n                       else\n                           return fib1(a-2) + fib1(a-1);  \n                   }                         \n               \"\"\"\n    ext_code = \"\"\"\n                   int val = fib1(a);\n                   return_val = Py::new_reference_to(Py::Int(val));\n               \"\"\"    \n    fib = ext_tools.ext_function('fib',ext_code,['a'])\n    fib.customize.add_support_code(fib_code)\n    mod.add_function(fib)\n\n    mod.compile()\n\n
              \n\nXXX More about custom_info, and what xxx_info instances are good for.\n\n

              \n\nNote: recursion is not the fastest way to calculate fibonacci numbers, but this \napproach serves nicely for this example.\n\n

              \n\n

              Customizing Type Conversions -- Type Factories

              \nnot written\n\n

              Things I wish weave did

              \n\nIt is possible to get name clashes if you uses a variable name that is already defined\nin a header automatically included (such as stdio.h) For instance, if you\ntry to pass in a variable named stdout, you'll get a cryptic error report\ndue to the fact that stdio.h also defines the name. weave\nshould probably try and handle this in some way.\n\nOther things...", "methods": [], "methods_before": [], "changed_methods": [], "nloc": null, "complexity": null, "token_count": null, "diff_parsed": { "added": [ "
              Benchmarks", " maybe some others will work, but I haven't tried. My advice is to use", "", "

              Benchmarks

              ", "This section has a few benchmarks -- thats all people want to see anyway right?", "These are mostly taken from running files in the weave/example", "directory and also from the test scripts. Without more information about what", "the test actually do, their value is limited. Still, their here for the", "curious. Look at the example scripts for more specifics about what problem was", "actually solved by each run. These examples are run under windows 2000 using", "Microsoft Visual C++ and python2.1 on a 850 MHz PIII laptop with 320 MB of RAM.", "

              ", "

              ", "", "", " ", " ", " ", " ", " ", " ", " ", " ", "", " ", " ", " ", " ", " ", "
              ", "

              inline and ext_tools

              Algorithm

              Speed up

              binary search   1.50
              fibonacci (recursive)  82.10
              fibonacci (loop)   9.17
              return None   0.14
              map   1.20
              dictionary sort   2.54
              vector quantization  37.40
              ", "

              blitz -- double precision

              Algorithm

              Speed up

              a = b + c 512x512   3.05
              a = b + c + d 512x512   4.59
              5 pt avg. filter, 2D Image 512x512   9.01
              Electromagnetics (FDTD) 100x100x100   8.61
              ", "
              ", "

              " ], "deleted": [ " maybe some others will work, but I haven't tried. My advise is to use" ] } } ] }, { "hash": "0ebec761d9cd9d48f68d8f5442519c828bcd0a2a", "msg": "added comment about single vs. double precision speed results", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-04T20:57:18+00:00", "author_timezone": 0, "committer_date": "2002-01-04T20:57:18+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "223f42b6e3201935e7e9304fddf798f1115de9eb" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 0, "insertions": 10, "lines": 10, "files": 1, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": "weave/doc/tutorial.html", "new_path": "weave/doc/tutorial.html", "filename": "tutorial.html", "extension": "html", "change_type": "MODIFY", "diff": "@@ -345,6 +345,9 @@

              Benchmarks

              \n curious. Look at the example scripts for more specifics about what problem was \n actually solved by each run. These examples are run under windows 2000 using \n Microsoft Visual C++ and python2.1 on a 850 MHz PIII laptop with 320 MB of RAM.\n+Speed up is the improvement (degredation) factor of weave compared to \n+conventional Python functions. The blitz() comparisons are shown\n+compared to Numeric.\n

              \n

              \n \n@@ -365,6 +368,13 @@

              Benchmarks

              \n \n \n \n+ \n+The benchmarks shown blitz in the best possible light. Numeric \n+(at least on my machine) is significantly worse for double precision than it is \n+for single precision calculations. If your interested in single precision \n+results, you can pretty much divide the double precision speed up by 3 and you'll\n+be close.\n+\n
              a = b + c + d 512x512   4.59
              5 pt avg. filter, 2D Image 512x512   9.01
              Electromagnetics (FDTD) 100x100x100   8.61
              \n
              \n

              \n", "added_lines": 10, "deleted_lines": 0, "source_code": "\n

              Weave Documentation

              \n

              \nBy Eric Jones eric@enthought.com\n

              \n

              Outline

              \n
              \n
              Introduction\n
              Requirements\n
              Installation\n
              Testing\n
              Benchmarks\n
              Inline\n
              \n
              More with printf\n
              \n More examples\n
              \n
              Binary search\n
              Dictionary sort\n
              Numeric -- cast/copy/transpose\n
              wxPython
              \n
              \n
              Keyword options\n
              Returning values\n
              \n
              \n The issue with locals()
              \n
              \n
              A quick look at the code\n
              \n Technical Details\n
              \n
              Converting Types\n
              \n
              \n Numeric Argument Conversion\n
              \n String, List, Tuple, and Dictionary Conversion\n
              File Conversion \n
              \n Callable, Instance, and Module Conversion \n
              Customizing Conversions\n
              \n
              Compiling Code\n
              \"Cataloging\" functions\n
              \n
              Function Storage\n
              The PYTHONCOMPILED evnironment variable
              \n
              \n
              \n
              \n
              \n
              \n
              Blitz\n
              \n
              Requirements\n
              Limitations\n
              Numeric Efficiency Issues\n
              The Tools \n
              \n
              Parser\n
              Blitz and Numeric\n
              \n
              Type defintions and coersion\n
              Cataloging Compiled Functions\n
              Checking Array Sizes\n
              Creating the Extension Module\n
              \n
              Extension Modules\n
              \n
              A Simple Example\n
              Fibonacci Example\n
              \n
              Customizing Type Conversions -- Type Factories (not written)\n
              \n
              Type Specifications\n
              Type Information\n
              The Conversion Process \n
              \n
              \n\n

              Introduction

              \n\n

              \nThe weave package provides tools for including C/C++ code within\nin Python code. This offers both another level of optimization to those who need \nit, and an easy way to modify and extend any supported extension libraries such \nas wxPython and hopefully VTK soon. Inlining C/C++ code within Python generally\nresults in speed ups of 1.5x to 30x speed-up over algorithms written in pure\nPython (However, it is also possible to slow things down...). Generally \nalgorithms that require a large number of calls to the Python API don't benefit\nas much from the conversion to C/C++ as algorithms that have inner loops \ncompletely convertable to C.\n

              \nThere are three basic ways to use weave. The \nweave.inline() function executes C code directly within Python, \nand weave.blitz() translates Python Numeric expressions to C++ \nfor fast execution. blitz() was the original reason \nweave was built. For those interested in building extension\nlibraries, the ext_tools module provides classes for building \nextension modules within Python. \n

              \nMost of weave's functionality should work on Windows and Unix, \nalthough some of its functionality requires gcc or a similarly \nmodern C++ compiler that handles templates well. Up to now, most testing has \nbeen done on Windows 2000 with Microsoft's C++ compiler (MSVC) and with gcc \n(mingw32 2.95.2 and 2.95.3-6). All tests also pass on Linux (RH 7.1 \nwith gcc 2.96), and I've had reports that it works on Debian also (thanks \nPearu).\n

              \nThe inline and blitz provide new functionality to \nPython (although I've recently learned about the PyInline project which may offer \nsimilar functionality to inline). On the other hand, tools for \nbuilding Python extension modules already exists (SWIG, SIP, pycpp, CXX, and \nothers). As of yet, I'm not sure where weave fits in this \nspectrum. It is closest in flavor to CXX in that it makes creating new C/C++ \nextension modules pretty easy. However, if you're wrapping a gaggle of legacy \nfunctions or classes, SWIG and friends are definitely the better choice. \nweave is set up so that you can customize how Python types are \nconverted to C types in weave. This is great for \ninline(), but, for wrapping legacy code, it is more flexible to \nspecify things the other way around -- that is how C types map to Python types. \nThis weave does not do. I guess it would be possible to build \nsuch a tool on top of weave, but with good tools like SWIG around, \nI'm not sure the effort produces any new capabilities. Things like function \noverloading are probably easily implemented in weave and it might \nbe easier to mix Python/C code in function calls, but nothing beyond this comes \nto mind. So, if you're developing new extension modules or optimizing Python \nfunctions in C, weave.ext_tools() might be the tool \nfor you. If you're wrapping legacy code, stick with SWIG.\n

              \nThe next several sections give the basics of how to use weave.\nWe'll discuss what's happening under the covers in more detail later \non. Serious users will need to at least look at the type conversion section to \nunderstand how Python variables map to C/C++ types and how to customize this \nbehavior. One other note. If you don't know C or C++ then these docs are \nprobably of very little help to you. Further, it'd be helpful if you know \nsomething about writing Python extensions. weave does quite a \nbit for you, but for anything complex, you'll need to do some conversions, \nreference counting, etc.\n

              \n\nNote: weave is actually part of the SciPy package. However, it works fine as a \nstandalone package. The examples here are given as if it is used as a stand \nalone package. If you are using from within scipy, you can use from \nscipy import weave and the examples will work identically.\n\n\n

              Requirements

              \n
                \n
              • Python\n

                \n I use 2.1.1. Probably 2.0 or higher should work.\n

                \n

                • \n \n
              • C++ compiler\n

                \n weave uses distutils to actually build \n extension modules, so it uses whatever compiler was originally used to \n build Python. weave itself requires a C++ compiler. If \n you used a C++ compiler to build Python, your probably fine.\n

                \n On Unix gcc is the preferred choice because I've done a little \n testing with it. All testing has been done with gcc, but I expect the \n majority of compilers should work for inline and \n ext_tools. The one issue I'm not sure about is that I've \n hard coded things so that compilations are linked with the \n stdc++ library. Is this standard across \n Unix compilers, or is this a gcc-ism?\n

                \n For blitz(), you'll need a reasonably recent version of \n gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n versions are likely to work. Its likely that KAI's C++ compiler and \n maybe some others will work, but I haven't tried. My advice is to use \n gcc for now unless your willing to tinker with the code some.\n

                \n On Windows, either MSVC or gcc (www.mingw.org\" > mingw32) should work. Again, \n you'll need gcc for blitz() as the\n MSVC compiler doesn't handle templates well.\n

                \n I have not tried Cygwin, so please report success if it works for you.\n

                \n

                • \n\n
              • Numeric (optional)\n

                \n The python Numeric module from here. is required for \n blitz() to work. Be sure and get NumPy, not NumArray\n which is the \"next generation\" implementation. This is not\n required for using inline() or ext_tools.\n

                \n

                • \n
              • scipy_distutils and scipy_test (packaged with weave)\n

                \n These two modules are packaged with weave in both\n the windows installer and the source distributions. If you are using\n CVS, however, you'll need to download these separately (also available\n through CVS at SciPy).\n

                \n

                • \n
              \n

              \n\n\n

              Installation

              \n

              \nThere are currently two ways to get weave. Fist, \nweave is part of SciPy and installed automatically (as a sub-\npackage) whenever SciPy is installed (although the latest version isn't in \nSciPy yet, so use this one for now). Second, since weave is \nuseful outside of the scientific community, it has been setup so that it can be\nused as a stand-alone module. \n\n

              \nThe stand-alone version can be downloaded from here. Unix users should grab the \ntar ball (.tgz file) and install it using the following commands.\n\n 

              \n    tar -xzvf weave-0.2.tar.gz\n    cd weave-0.2\n    python setup.py install\n
              \n\nThis will also install two other packages, scipy_distutils and \nscipy_test. The first is needed by the setup process itself and \nboth are used in the unit-testing process. Numeric is required if you want to \nuse blitz(), but isn't necessary for inline() or \next_tools\n

              \nFor Windows users, it's even easier. You can download the click-install .exe \nfile and run it for automatic installation. There is also a .zip file of the\nsource for those interested. It also includes a setup.py file to simplify\ninstallation. \n

              \nIf you're using the CVS version, you'll need to install \nscipy_distutils and scipy_test packages (also \navailable from CVS) on your own.\n

              \n \nNote: The dependency issue here is a little sticky. I hate to make people \ndownload more than one file (and so I haven't), but distutils doesn't have a \nway to do conditional installation -- at least that I know about. This can \nlead to undesired clobbering of the scipy_test and scipy_distutils modules. \nWhat to do, what to do... Right now it is a very minor issue.\n\n

              \n\n

              Testing

              \nOnce weave is installed, fire up python and run its unit tests.\n\n 
              \n    >>> import weave\n    >>> weave.test()\n    runs long time... spews tons of output and a few warnings\n    .\n    .\n    .\n    ..............................................................\n    ................................................................\n    ..................................................\n    ----------------------------------------------------------------------\n    Ran 184 tests in 158.418s\n\n    OK\n    \n    >>> \n
              \n\nThis takes a loooong time. On windows, it is usually several minutes. On Unix \nwith remote file systems, I've had it take 15 or so minutes. In the end, it \nshould run about 180 tests and spew some speed results along the way. If you \nget errors, they'll be reported at the end of the output. Please let me know\nwhat if this occurs.\n\nIf you don't have Numeric installed, you'll get some module import errors \nduring the test setup phase for modules that are Numeric specific (blitz_spec, \nblitz_tools, size_check, standard_array_spec, ast_tools), but all test should\npass (about 100 and they should complete in several minutes).\n

              \nIf you only want to test a single module of the package, you can do this by\nrunning test() for that specific module.\n\n 

              \n    >>> import weave.scalar_spec\n    >>> weave.scalar_spec.test()\n    .......\n    ----------------------------------------------------------------------\n    Ran 7 tests in 23.284s\n
              \n\nTesting Notes:\n
                \n
              • \n Windows 1\n

                \n I've had some test fail on windows machines where I have msvc, gcc-2.95.2 \n (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My \n environment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the \n path. The test process runs very smoothly until the end where several test \n using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') \n before running tests, I get gcc-2.95.3-6. If I check after running tests \n (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] \n still has c:\\gcc first in it and is not corrupted (msvc/distutils messes \n with the environment variables, so we have to undo its work in some \n places). If anyone else sees this, let me know - - it may just be an quirk \n on my machine (unlikely). Testing with the gcc- 2.95.2 installation always \n works.\n

                \n

                • \n
              • \n Windows 2\n

                \n If you run the tests from PythonWin or some other GUI tool, you'll get a\n ton of DOS windows popping up periodically as weave spawns\n the compiler multiple times. Very annoying. Anyone know how to fix this?\n

                \n

                • \n
              • \n wxPython\n

                \n wxPython tests are not enabled by default because importing wxPython on a \n Unix machine without access to a X-term will cause the program to exit. \n Anyone know of a safe way to detect whether wxPython can be imported and \n whether a display exists on a machine? \n

                \n

                • \n                \n\n

                \n

              \n\n\n

              Benchmarks

              \nThis section has a few benchmarks -- thats all people want to see anyway right? \nThese are mostly taken from running files in the weave/example \ndirectory and also from the test scripts. Without more information about what \nthe test actually do, their value is limited. Still, their here for the \ncurious. Look at the example scripts for more specifics about what problem was \nactually solved by each run. These examples are run under windows 2000 using \nMicrosoft Visual C++ and python2.1 on a 850 MHz PIII laptop with 320 MB of RAM.\nSpeed up is the improvement (degredation) factor of weave compared to \nconventional Python functions. The blitz() comparisons are shown\ncompared to Numeric.\n

              \n

              \n\n\n \n \n \n \n \n \n \n \n\n \n \n \n \n \n \nThe benchmarks shown blitz in the best possible light. Numeric \n(at least on my machine) is significantly worse for double precision than it is \nfor single precision calculations. If your interested in single precision \nresults, you can pretty much divide the double precision speed up by 3 and you'll\nbe close.\n\n
              \n

              inline and ext_tools

              Algorithm

              Speed up

              binary search   1.50
              fibonacci (recursive)  82.10
              fibonacci (loop)   9.17
              return None   0.14
              map   1.20
              dictionary sort   2.54
              vector quantization  37.40
              \n

              blitz -- double precision

              Algorithm

              Speed up

              a = b + c 512x512   3.05
              a = b + c + d 512x512   4.59
              5 pt avg. filter, 2D Image 512x512   9.01
              Electromagnetics (FDTD) 100x100x100   8.61
              \n
              \n

              \n\n

              Inline

              \n

              \ninline() compiles and executes C/C++ code on the fly. Variables \nin the local and global Python scope are also available in the C/C++ code. \nValues are passed to the C/C++ code by assignment much like variables \nare passed into a standard Python function. Values are returned from the C/C++ \ncode through a special argument called return_val. Also, the contents of \nmutable objects can be changed within the C/C++ code and the changes remain \nafter the C code exits and returns to Python. (more on this later)\n

              \nHere's a trivial printf example using inline():\n\n 

              \n    >>> import weave    \n    >>> a  = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n

              \nIn this, its most basic form, inline(c_code, var_list) requires two \narguments. c_code is a string of valid C/C++ code. \nvar_list is a list of variable names that are passed from \nPython into C/C++. Here we have a simple printf statement that \nwrites the Python variable a to the screen. The first time you run \nthis, there will be a pause while the code is written to a .cpp file, compiled \ninto an extension module, loaded into Python, cataloged for future use, and \nexecuted. On windows (850 MHz PIII), this takes about 1.5 seconds when using \nMicrosoft's C++ compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). \nAll subsequent executions of the code will happen very quickly because the code \nonly needs to be compiled once. If you kill and restart the interpreter and then \nexecute the same code fragment again, there will be a much shorter delay in the \nfractions of seconds range. This is because weave stores a \ncatalog of all previously compiled functions in an on disk cache. When it sees \na string that has been compiled, it loads the already compiled module and \nexecutes the appropriate function. \n

              \n\nNote: If you try the printf example in a GUI shell such as IDLE, \nPythonWin, PyShell, etc., you're unlikely to see the output. This is because the \nC code is writing to stdout, instead of to the GUI window. This doesn't mean \nthat inline doesn't work in these environments -- it only means that standard \nout in C is not the same as the standard out for Python in these cases. Non \ninput/output functions will work as expected.\n\n

              \nAlthough effort has been made to reduce the overhead associated with calling \ninline, it is still less efficient for simple code snippets than using \nequivalent Python code. The simple printf example is actually \nslower by 30% or so than using Python print statement. And, it is \nnot difficult to create code fragments that are 8-10 times slower using inline \nthan equivalent Python. However, for more complicated algorithms, \nthe speed up can be worth while -- anywhwere from 1.5- 30 times faster. \nAlgorithms that have to manipulate Python objects (sorting a list) usually only \nsee a factor of 2 or so improvement. Algorithms that are highly computational \nor manipulate Numeric arrays can see much larger improvements. The \nexamples/vq.py file shows a factor of 30 or more improvement on the vector \nquantization algorithm that is used heavily in information theory and \nclassification problems.\n

              \n\n\n

              More with printf

              \n

              \nMSVC users will actually see a bit of compiler output that distutils does not\nsupress the first time the code executes:\n\n 

                  \n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    sc_e013937dbc8c647ac62438874e5795131.cpp\n       Creating library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\n       \\Release\\sc_e013937dbc8c647ac62438874e5795131.lib and object C:\\DOCUME\n       ~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_e013937dbc8c64\n       7ac62438874e5795131.exp\n    1\n
              \n

              \nNothing bad is happening, its just a bit annoying. Anyone know how to \nturn this off? \n

              \nThis example also demonstrates using 'raw strings'. The r \npreceeding the code string in the last example denotes that this is a 'raw \nstring'. In raw strings, the backslash character is not interpreted as an \nescape character, and so it isn't necessary to use a double backslash to \nindicate that the '\\n' is meant to be interpreted in the C printf \nstatement instead of by Python. If your C code contains a lot\nof strings and control characters, raw strings might make things easier.\nMost of the time, however, standard strings work just as well.\n\n

              \nThe printf statement in these examples is formatted to print \nout integers. What happens if a is a string? inline\nwill happily, compile a new version of the code to accept strings as input,\nand execute the code. The result?\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    32956972\n
              \n

              \nIn this case, the result is non-sensical, but also non-fatal. In other \nsituations, it might produce a compile time error because a is \nrequired to be an integer at some point in the code, or it could produce a \nsegmentation fault. Its possible to protect against passing \ninline arguments of the wrong data type by using asserts in \nPython.\n\n 

                  \n    >>> a = 'string'\n    >>> def protected_printf(a):    \n    ...     assert(type(a) == type(1))\n    ...     weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    >>> protected_printf(1)\n     1\n    >>> protected_printf('string')\n    AssertError...\n
              \n\n

              \nFor printing strings, the format statement needs to be changed.\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%s\\n\",a);',['a'])\n    string\n
              \n\n

              \nAs in this case, C/C++ code fragments often have to change to accept different \ntypes. For the given printing task, however, C++ streams provide a way of a \nsingle statement that works for integers and strings. By default, the stream \nobjects live in the std (standard) namespace and thus require the use of \nstd::.\n\n 

                  \n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    1    \n    >>> a = 'string'\n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    string\n
              \n \n

              \nExamples using printf and cout are included in \nexamples/print_example.py.\n\n\n

              More examples

              \n\nThis section shows several more advanced uses of inline. It \nincludes a few algorithms from the Python Cookbook \nthat have been re-written in inline C to improve speed as well as a couple \nexamples using Numeric and wxPython.\n\n\n

              Binary search

              \nLets look at the example of searching a sorted list of integers for a value. \nFor inspiration, we'll use Kalle Svensson's \nbinary_search() algorithm from the Python Cookbook. His recipe follows:\n\n 
              \n    def binary_search(seq, t):\n        min = 0; max = len(seq) - 1\n        while 1:\n            if max < min:\n                return -1\n            m = (min  + max)  / 2\n            if seq[m] < t: \n                min = m  + 1 \n            elif seq[m] > t: \n                max = m  - 1 \n            else:\n                return m    \n
              \n\nThis Python version works for arbitrary Python data types. The C version below is \nspecialized to handle integer values. There is a little type checking done in \nPython to assure that we're working with the correct data types before heading \ninto C. The variables seq and t don't need to be \ndeclared beacuse weave handles converting and declaring them in \nthe C code. All other temporary variables such as min, max, etc. \nmust be declared -- it is C after all. Here's the new mixed Python/C function:\n\n 
                  \n    def c_int_binary_search(seq,t):\n        # do a little type checking in Python\n        assert(type(t) == type(1))\n        assert(type(seq) == type([]))\n        \n        # now the C code\n        code = \"\"\"\n               #line 29 \"binary_search.py\"\n               int val, m, min = 0;  \n               int max = seq.length() - 1;\n               PyObject *py_val; \n               for(;;)\n               {\n                   if (max < min  ) \n                   { \n                       return_val =  Py::new_reference_to(Py::Int(-1)); \n                       break;\n                   } \n                   m =  (min + max) /2;\n                   val =    py_to_int(PyList_GetItem(seq.ptr(),m),\"val\"); \n                   if (val  < t) \n                       min = m  + 1;\n                   else if (val >  t)\n                       max = m - 1;\n                   else\n                   {\n                       return_val = Py::new_reference_to(Py::Int(m));\n                       break;\n                   }\n               }\n               \"\"\"\n        return inline(code,['seq','t'])\n
              \n

              \nWe have two variables seq and t passed in. \nt is guaranteed (by the assert) to be an integer. \nPython integers are converted to C int types in the transition from Python to \nC. seq is a Python list. By default, it is translated to a CXX \nlist object. Full documentation for the CXX library can be found at its website. The basics are that the CXX \nprovides C++ class equivalents for Python objects that simplify, or at \nleast object orientify, working with Python objects in C/C++. For example, \nseq.length() returns the length of the list. A little more about\nCXX and its class methods, etc. is in the ** type conversions ** section.\n

              \n\nNote: CXX uses templates and therefore may be a little less portable than \nanother alternative by Gordan McMillan called SCXX which was inspired by\nCXX. It doesn't use templates so it should compile faster and be more portable.\nSCXX has a few less features, but it appears to me that it would mesh with\nthe needs of weave quite well. Hopefully xxx_spec files will be written\nfor SCXX in the future, and we'll be able to compare on a more empirical\nbasis. Both sets of spec files will probably stick around, it just a question\nof which becomes the default.\n\n

              \nMost of the algorithm above looks similar in C to the original Python code. \nThere are two main differences. The first is the setting of \nreturn_val instead of directly returning from the C code with a \nreturn statement. return_val is an automatically \ndefined variable of type PyObject* that is returned from the C \ncode back to Python. You'll have to handle reference counting issues when \nsetting this variable. In this example, CXX classes and functions handle the \ndirty work. All CXX functions and classes live in the namespace \nPy::. The following code converts the integer m to a \nCXX Int() object and then to a PyObject* with an \nincremented reference count using Py::new_reference_to().\n\n 

                 \n    return_val = Py::new_reference_to(Py::Int(m));\n
              \n

              \nThe second big differences shows up in the retrieval of integer values from the \nPython list. The simple Python seq[i] call balloons into a C \nPython API call to grab the value out of the list and then a separate call to \npy_to_int() that converts the PyObject* to an integer. \npy_to_int() includes both a NULL cheack and a \nPyInt_Check() call as well as the conversion call. If either of \nthe checks fail, an exception is raised. The entire C++ code block is executed \nwith in a try/catch block that handles exceptions much like Python \ndoes. This removes the need for most error checking code.\n

              \nIt is worth note that CXX lists do have indexing operators that result \nin code that looks much like Python. However, the overhead in using them \nappears to be relatively high, so the standard Python API was used on the \nseq.ptr() which is the underlying PyObject* of the \nList object.\n

              \nThe #line directive that is the first line of the C code \nblock isn't necessary, but it's nice for debugging. If the compilation fails \nbecause of the syntax error in the code, the error will be reported as an error \nin the Python file \"binary_search.py\" with an offset from the given line number \n(29 here).\n

              \nSo what was all our effort worth in terms of efficiency? Well not a lot in \nthis case. The examples/binary_search.py file runs both Python and C versions \nof the functions As well as using the standard bisect module. If \nwe run it on a 1 million element list and run the search 3000 times (for 0-\n2999), here are the results we get:\n\n 

                 \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python binary_search.py\n    Binary search for 3000 items in 1000000 length list of integers:\n     speed in python: 0.159999966621\n     speed of bisect: 0.121000051498\n     speed up: 1.32\n     speed in c: 0.110000014305\n     speed up: 1.45\n     speed in c(no asserts): 0.0900000333786\n     speed up: 1.78\n
              \n

              \nSo, we get roughly a 50-75% improvement depending on whether we use the Python \nasserts in our C version. If we move down to searching a 10000 element list, \nthe advantage evaporates. Even smaller lists might result in the Python \nversion being faster. I'd like to say that moving to Numeric lists (and \ngetting rid of the GetItem() call) offers a substantial speed up, but my \npreliminary efforts didn't produce one. I think the log(N) algorithm is to \nblame. Because the algorithm is nice, there just isn't much time spent \ncomputing things, so moving to C isn't that big of a win. If there are ways to \nreduce conversion overhead of values, this may improve the C/Python speed \nup. Anyone have other explanations or faster code, please let me know.\n\n\n

              Dictionary Sort

              \n

              \nThe demo in examples/dict_sort.py is another example from the Python CookBook. \nThis \nsubmission, by Alex Martelli, demonstrates how to return the values from a \ndictionary sorted by their keys:\n\n 

                     \n    def sortedDictValues3(adict):\n        keys = adict.keys()\n        keys.sort()\n        return map(adict.get, keys)\n
              \n

              \nAlex provides 3 algorithms and this is the 3rd and fastest of the set. The C \nversion of this same algorithm follows:\n\n 

                     \n    def c_sort(adict):\n        assert(type(adict) == type({}))\n        code = \"\"\"     \n        #line 21 \"dict_sort.py\"  \n        Py::List keys = adict.keys();\n        Py::List items(keys.length()); keys.sort();     \n        PyObject* item = NULL; \n        for(int i = 0;  i < keys.length();i++)\n        {\n            item = PyList_GET_ITEM(keys.ptr(),i);\n            item = PyDict_GetItem(adict.ptr(),item);\n            Py_XINCREF(item);\n            PyList_SetItem(items.ptr(),i,item);              \n        }           \n        return_val = Py::new_reference_to(items);\n        \"\"\"   \n        return inline_tools.inline(code,['adict'],verbose=1)\n
              \n

              \nLike the original Python function, the C++ version can handle any Python \ndictionary regardless of the key/value pair types. It uses CXX objects for the \nmost part to declare python types in C++, but uses Python API calls to manipulate \ntheir contents. Again, this choice is made for speed. The C++ version, while\nmore complicated, is about a factor of 2 faster than Python.\n\n 

                     \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python dict_sort.py\n    Dict sort of 1000 items for 300 iterations:\n     speed in python: 0.319999933243\n    [0, 1, 2, 3, 4]\n     speed in c: 0.151000022888\n     speed up: 2.12\n    [0, 1, 2, 3, 4]\n
              \n

              \n\n

              Numeric -- cast/copy/transpose

              \n\nCastCopyTranspose is a function called quite heavily by Linear Algebra routines\nin the Numeric library. Its needed in part because of the row-major memory layout\nof multi-demensional Python (and C) arrays vs. the col-major order of the underlying\nFortran algorithms. For small matrices (say 100x100 or less), a significant\nportion of the common routines such as LU decompisition or singular value decompostion\nare spent in this setup routine. This shouldn't happen. Here is the Python\nversion of the function using standard Numeric operations.\n\n 
                     \n    def _castCopyAndTranspose(type, array):\n        if a.typecode() == type:\n            cast_array = copy.copy(Numeric.transpose(a))\n        else:\n            cast_array = copy.copy(Numeric.transpose(a).astype(type))\n        return cast_array\n
              \n\nAnd the following is a inline C version of the same function:\n\n 
              \n    from weave.blitz_tools import blitz_type_factories\n    from weave import scalar_spec\n    from weave import inline\n    def _cast_copy_transpose(type,a_2d):\n        assert(len(shape(a_2d)) == 2)\n        new_array = zeros(shape(a_2d),type)\n        numeric_type = scalar_spec.numeric_to_blitz_type_mapping[type]\n        code = \\\n        \"\"\"  \n        for(int i = 0;i < _Na_2d[0]; i++)  \n            for(int j = 0;  j < _Na_2d[1]; j++)\n                new_array(i,j) = (%s) a_2d(j,i);\n        \"\"\" % numeric_type\n        inline(code,['new_array','a_2d'],\n               type_factories = blitz_type_factories,compiler='gcc')\n        return new_array\n
              \n\nThis example uses blitz++ arrays instead of the standard representation of \nNumeric arrays so that indexing is simplier to write. This is accomplished by \npassing in the blitz++ \"type factories\" to override the standard Python to C++ \ntype conversions. Blitz++ arrays allow you to write clean, fast code, but they \nalso are sloooow to compile (20 seconds or more for this snippet). This is why \nthey aren't the default type used for Numeric arrays (and also because most \ncompilers can't compile blitz arrays...). inline() is also forced \nto use 'gcc' as the compiler because the default compiler on Windows (MSVC) \nwill not compile blitz code. 'gcc' I think will use the standard compiler \non Unix machine instead of explicitly forcing gcc (check this) \n\nComparisons of the Python vs inline C++ code show a factor of 3 speed up. Also \nshown are the results of an \"inplace\" transpose routine that can be used if the \noutput of the linear algebra routine can overwrite the original matrix (this is \noften appropriate). This provides another factor of 2 improvement.\n\n 
              \n     #C:\\home\\ej\\wrk\\scipy\\weave\\examples> python cast_copy_transpose.py\n    # Cast/Copy/Transposing (150,150)array 1 times\n    #  speed in python: 0.870999932289\n    #  speed in c: 0.25\n    #  speed up: 3.48\n    #  inplace transpose c: 0.129999995232\n    #  speed up: 6.70\n
              \n\n\n

              wxPython

              \n\ninline knows how to handle wxPython objects. Thats nice in and of\nitself, but it also demonstrates that the type conversion mechanism is reasonably \nflexible. Chances are, it won't take a ton of effort to support special types\nyou might have. The examples/wx_example.py borrows the scrolled window\nexample from the wxPython demo, accept that it mixes inline C code in the middle\nof the drawing function.\n\n 
              \n    def DoDrawing(self, dc):\n        \n        red = wxNamedColour(\"RED\");\n        blue = wxNamedColour(\"BLUE\");\n        grey_brush = wxLIGHT_GREY_BRUSH;\n        code = \\\n        \"\"\"\n        #line 108 \"wx_example.py\" \n        dc->BeginDrawing();\n        dc->SetPen(wxPen(*red,4,wxSOLID));\n        dc->DrawRectangle(5,5,50,50);\n        dc->SetBrush(*grey_brush);\n        dc->SetPen(wxPen(*blue,4,wxSOLID));\n        dc->DrawRectangle(15, 15, 50, 50);\n        \"\"\"\n        inline(code,['dc','red','blue','grey_brush'])\n        \n        dc.SetFont(wxFont(14, wxSWISS, wxNORMAL, wxNORMAL))\n        dc.SetTextForeground(wxColour(0xFF, 0x20, 0xFF))\n        te = dc.GetTextExtent(\"Hello World\")\n        dc.DrawText(\"Hello World\", 60, 65)\n\n        dc.SetPen(wxPen(wxNamedColour('VIOLET'), 4))\n        dc.DrawLine(5, 65+te[1], 60+te[0], 65+te[1])\n        ...\n
              \n\nHere, some of the Python calls to wx objects were just converted to C++ calls. There\nisn't any benefit, it just demonstrates the capabilities. You might want to use this\nif you have a computationally intensive loop in your drawing code that you want to \nspeed up.\n\nOn windows, you'll have to use the MSVC compiler if you use the standard wxPython\nDLLs distributed by Robin Dunn. Thats because MSVC and gcc, while binary\ncompatible in C, are not binary compatible for C++. In fact, its probably best, no \nmatter what platform you're on, to specify that inline use the same\ncompiler that was used to build wxPython to be on the safe side. There isn't currently\na way to learn this info from the library -- you just have to know. Also, at least\non the windows platform, you'll need to install the wxWindows libraries and link to \nthem. I think there is a way around this, but I haven't found it yet -- I get some\nlinking errors dealing with wxString. One final note. You'll probably have to\ntweak weave/wx_spec.py or weave/wx_info.py for your machine's configuration to\npoint at the correct directories etc. There. That should sufficiently scare people\ninto not even looking at this... :)\n\n              \n

              Keyword Options

              \n

              \nThe basic definition of the inline() function has a slew of \noptional variables. It also takes keyword arguments that are passed to \ndistutils as compiler options. The following is a formatted \ncut/paste of the argument section of inline's doc-string. It \nexplains all of the variables. Some examples using various options will \nfollow.\n\n 

                     \n    def inline(code,arg_names,local_dict = None, global_dict = None, \n               force = 0, \n               compiler='',\n               verbose = 0, \n               support_code = None,\n               customize=None, \n               type_factories = None, \n               auto_downcast=1,\n               **kw):\n
              \n\n \ninline has quite \na few options as listed below. Also, the keyword arguments for distutils \nextension modules are accepted to specify extra information needed for \ncompiling. \n
              \n

              inline Arguments:

              \n
              \n
              \n
              code
              \n \n
              \nstring. A string of valid C++ code. It should not \n specify a return statement. Instead it should assign results that need to be \n returned to Python in the return_val. \n
              \n\n
              arg_names
              \n \n
              \nlist of strings. A list of Python variable names \n that should be transferred from Python into the C/C++ code. \n
              \n\n
              local_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the local scope for the C/C++ \n code. If local_dict is not specified the local dictionary of the calling \n function is used. \n
              \n\n
              global_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the global scope for the C/C++ \n code. If global_dict is not specified the global dictionary of the calling \n function is used. \n
              \n\n
              force
              \n \n
              \noptional. 0 or 1. default 0. If 1, the C++ code is \n compiled every time inline is called. This is really only useful for \n debugging, and probably only useful if you're editing support_code a lot. \n
              \n\n
              compiler
              \n \n
              \noptional. string. The name of compiler to use when compiling. On windows, it \nunderstands 'msvc' and 'gcc' as well as all the compiler names understood by \ndistutils. On Unix, it'll only understand the values understoof by distutils. \n(I should add 'gcc' though to this).\n

              \nOn windows, the compiler defaults to the Microsoft C++ compiler. If this isn't \navailable, it looks for mingw32 (the gcc compiler).\n

              \nOn Unix, it'll probably use the same compiler that was used when compiling \nPython. Cygwin's behavior should be similar.

              \n
              \n\n
              verbose
              \n \n
              \noptional. 0,1, or 2. defualt 0. Speficies how much \n much information is printed during the compile phase of inlining code. 0 is \n silent (except on windows with msvc where it still prints some garbage). 1 \n informs you when compiling starts, finishes, and how long it took. 2 prints \n out the command lines for the compilation process and can be useful if you're \n having problems getting code to work. Its handy for finding the name of the \n .cpp file if you need to examine it. verbose has no affect if the \n compilation isn't necessary. \n
              \n\n
              support_code
              \n \n
              \noptional. string. A string of valid C++ code \n declaring extra code that might be needed by your compiled function. This \n could be declarations of functions, classes, or structures. \n
              \n\n
              customize
              \n \n
              \noptional. base_info.custom_info object. An \n alternative way to specifiy support_code, headers, etc. needed by the \n function see the weave.base_info module for more details. (not sure \n this'll be used much). \n \n
              \n
              type_factories
              \n \n
              \noptional. list of type specification factories. These guys are what convert \nPython data types to C/C++ data types. If you'd like to use a different set of \ntype conversions than the default, specify them here. Look in the type \nconversions section of the main documentation for examples.\n
              \n
              auto_downcast
              \n \n
              \noptional. 0 or 1. default 1. This only affects functions that have Numeric \narrays as input variables. Setting this to 1 will cause all floating point \nvalues to be cast as float instead of double if all the Numeric arrays are of \ntype float. If even one of the arrays has type double or double complex, all \nvariables maintain there standard types.\n
              \n
              \n
              \n\n

              Distutils keywords:

              \n
              \ninline() also accepts a number of distutils keywords \nfor controlling how the code is compiled. The following descriptions have been \ncopied from Greg Ward's distutils.extension.Extension class doc-\nstrings for convenience:\n\n
              \n
              sources
              \n \n
              \n[string] list of source filenames, relative to the \n distribution root (where the setup script lives), in Unix form \n (slash-separated) for portability. Source files may be C, C++, SWIG (.i), \n platform-specific resource files, or whatever else is recognized by the \n \"build_ext\" command as source for a Python extension. Note: The module_path \n file is always appended to the front of this list \n
              \n\n
              include_dirs
              \n \n
              \n[string] list of directories to search for C/C++ \n header files (in Unix form for portability) \n
              \n\n
              define_macros
              \n \n
              \n[(name : string, value : string|None)] list of \n macros to define; each macro is defined using a 2-tuple, where 'value' is \n either the string to define it to or None to define it without a particular \n value (equivalent of \"#define FOO\" in source or -DFOO on Unix C compiler \n command line) \n
              \n
              undef_macros
              \n \n
              \n[string] list of macros to undefine explicitly \n
              \n
              library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at link time \n
              \n
              libraries
              \n
              \n[string] list of library names (not filenames or paths) to link against \n
              \n
              runtime_library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at run time (for \nshared extensions, this is when the extension is loaded) \n
              \n\n
              extra_objects
              \n \n
              \n[string] list of extra files to link with (eg. \n object files not implied by 'sources', static library that must be \n explicitly specified, binary resource files, etc.) \n
              \n\n
              extra_compile_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when compiling the source files in 'sources'. For \n platforms and compilers where \"command line\" makes sense, this is typically \n a list of command-line arguments, but for other platforms it could be \n anything. \n
              \n
              extra_link_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when linking object files together to create the \n extension (or to create a new static Python interpreter). Similar \n interpretation as for 'extra_compile_args'. \n
              \n
              export_symbols
              \n \n
              \n[string] list of symbols to be exported from a shared extension. Not used on \nall platforms, and not generally necessary for Python extensions, which \ntypically export exactly one symbol: \"init\" + extension_name. \n
              \n
              \n
              \n\n\n

              Keyword Option Examples

              \nWe'll walk through several examples here to demonstrate the behavior of \ninline and also how the various arguments are used.\n\nIn the simplest (most) cases, code and arg_names\nare the only arguments that need to be specified. Here's a simple example\nrun on Windows machine that has Microsoft VC++ installed.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'string'\n    >>> code = \"\"\"\n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));\n    ...        \"\"\"\n    >>> inline(code,['a'])\n     sc_86e98826b65b047ffd2cd5f479c627f12.cpp\n    Creating\n       library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f12.lib\n    and object C:\\DOCUME~ 1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ff\n    d2cd5f479c627f12.exp\n    6\n    >>> inline(code,['a'])\n    6\n
              \n \nWhen inline is first run, you'll notice that pause and some \ntrash printed to the screen. The \"trash\" is acutually part of the compilers\noutput that distutils does not supress. The name of the extension file, \nsc_bighonkingnumber.cpp, is generated from the md5 check sum\nof the C/C++ code fragment. On Unix or windows machines with only\ngcc installed, the trash will not appear. On the second call, the code \nfragment is not compiled since it already exists, and only the answer is \nreturned. Now kill the interpreter and restart, and run the same code with\na different string.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'a longer string' \n    >>> code = \"\"\" \n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));  \n    ...        \"\"\"\n    >>> inline(code,['a'])\n    15\n
              \n

              \nNotice this time, inline() did not recompile the code because it\nfound the compiled function in the persistent catalog of functions. There is\na short pause as it looks up and loads the function, but it is much shorter \nthan compiling would require.\n

              \nYou can specify the local and global dictionaries if you'd like (much like \nexec or eval() in Python), but if they aren't \nspecified, the \"expected\" ones are used -- i.e. the ones from the function that \ncalled inline() . This is accomplished through a little call \nframe trickery. Here is an example where the local_dict is specified using\nthe same code example from above:\n\n 

              \n    >>> a = 'a longer string'\n    >>> b = 'an even  longer string' \n    >>> my_dict = {'a':b}\n    >>> inline(code,['a'])\n    15\n    >>> inline(code,['a'],my_dict)\n    21\n
              \n \n

              \nEverytime, the code is changed, inline does a \nrecompile. However, changing any of the other options in inline does not\nforce a recompile. The force option was added so that one\ncould force a recompile when tinkering with other variables. In practice,\nit is just as easy to change the code by a single character\n(like adding a space some place) to force the recompile. Note: It also \nmight be nice to add some methods for purging the cache and on disk \ncatalogs.\n

              \nI use verbose sometimes for debugging. When set to 2, it'll \noutput all the information (including the name of the .cpp file) that you'd\nexpect from running a make file. This is nice if you need to examine the\ngenerated code to see where things are going haywire. Note that error\nmessages from failed compiles are printed to the screen even if verbose\n is set to 0.\n

              \nThe following example demonstrates using gcc instead of the standard msvc \ncompiler on windows using same code fragment as above. Because the example has \nalready been compiled, the force=1 flag is needed to make \ninline() ignore the previously compiled version and recompile \nusing gcc. The verbose flag is added to show what is printed out:\n\n 

              \n    >>>inline(code,['a'],compiler='gcc',verbose=2,force=1)\n    running build_ext    \n    building 'sc_86e98826b65b047ffd2cd5f479c627f13' extension \n    c:\\gcc-2.95.2\\bin\\g++.exe -mno-cygwin -mdll -O2 -w -Wstrict-prototypes -IC:\n    \\home\\ej\\wrk\\scipy\\weave -IC:\\Python21\\Include -c C:\\DOCUME~1\\eric\\LOCAL\n    S~1\\Temp\\python21_compiled\\sc_86e98826b65b047ffd2cd5f479c627f13.cpp -o C:\\D\n    OCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b04\n    7ffd2cd5f479c627f13.o    \n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxextensions.c (C:\\DOCUME~1\\eri\n    c\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxextensions.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxsupport.cxx (C:\\DOCUME~1\\eric\n    \\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxsupport.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\IndirectPythonInterface.cxx (C:\\\n    DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\indirectpythonin\n    terface.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxx_extensions.cxx (C:\\DOCUME~1\\\n    eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxx_extensions.o up-to-da\n    te)\n    writing C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86\n    e98826b65b047ffd2cd5f479c627f13.def\n    c:\\gcc-2.95.2\\bin\\dllwrap.exe --driver-name g++ -mno-cygwin -mdll -static -\n    -output-lib C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\l\n    ibsc_86e98826b65b047ffd2cd5f479c627f13.a --def C:\\DOCUME~1\\eric\\LOCALS~1\\Te\n    mp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f13.def \n    -s C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e9882\n    6b65b047ffd2cd5f479c627f13.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compil\n    ed\\temp\\Release\\cxxextensions.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\cxxsupport.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\indirectpythoninterface.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\n    \\python21_compiled\\temp\\Release\\cxx_extensions.o -LC:\\Python21\\libs -lpytho\n    n21 -o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\sc_86e98826b65b047f\n    fd2cd5f479c627f13.pyd\n    15\n
              \n\nThat's quite a bit of output. verbose=1 just prints the compile\ntime.\n\n 
              \n    >>>inline(code,['a'],compiler='gcc',verbose=1,force=1)\n    Compiling code...\n    finished compiling (sec):  6.00800001621\n    15\n
              \n\n

              \n Note: I've only used the compiler option for switching between 'msvc'\nand 'gcc' on windows. It may have use on Unix also, but I don't know yet.\n\n\n

              \nThe support_code argument is likely to be used a lot. It allows \nyou to specify extra code fragments such as function, structure or class \ndefinitions that you want to use in the code string. Note that \nchanges to support_code do not force a recompile. The \ncatalog only relies on code (for performance reasons) to determine \nwhether recompiling is necessary. So, if you make a change to support_code, \nyou'll need to alter code in some way or use the \nforce argument to get the code to recompile. I usually just add \nsome inocuous whitespace to the end of one of the lines in code \nsomewhere. Here's an example of defining a separate method for calculating\nthe string length:\n\n 

              \n    >>> from weave import inline\n    >>> a = 'a longer string'\n    >>> support_code = \"\"\"\n    ...                PyObject* length(Py::String a)\n    ...                {\n    ...                    int l = a.length();  \n    ...                    return Py::new_reference_to(Py::Int(l)); \n    ...                }\n    ...                \"\"\"        \n    >>> inline(\"return_val = length(a);\",['a'],\n    ...        support_code = support_code)\n    15\n
              \n

              \ncustomize is a left over from a previous way of specifying \ncompiler options. It is a custom_info object that can specify \nquite a bit of information about how a file is compiled. These \ninfo objects are the standard way of defining compile information \nfor type conversion classes. However, I don't think they are as handy here, \nespecially since we've exposed all the keyword arguments that distutils can \nhandle. Between these keywords, and the support_code option, I \nthink customize may be obsolete. We'll see if anyone cares to use \nit. If not, it'll get axed in the next version.\n

              \nThe type_factories variable is important to people who want to\ncustomize the way arguments are converted from Python to C. We'll talk about\nthis in the next chapter **xx** of this document when we discuss type\nconversions.\n

              \nauto_downcast handles one of the big type conversion issues that\nis common when using Numeric arrays in conjunction with Python scalar values.\nIf you have an array of single precision values and multiply that array by a \nPython scalar, the result is upcast to a double precision array because the\nscalar value is double precision. This is not usually the desired behavior\nbecause it can double your memory usage. auto_downcast goes\nsome distance towards changing the casting precedence of arrays and scalars.\nIf your only using single precision arrays, it will automatically downcast all\nscalar values from double to single precision when they are passed into the\nC++ code. This is the default behavior. If you want all values to keep there\ndefault type, set auto_downcast to 0.\n

              \n\n\n\n

              Returning Values

              \n\nPython variables in the local and global scope transfer seemlessly from Python \ninto the C++ snippets. And, if inline were to completely live up\nto its name, any modifications to variables in the C++ code would be reflected\nin the Python variables when control was passed back to Python. For example,\nthe desired behavior would be something like:\n\n 
              \n    # THIS DOES NOT WORK\n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    2\n
              \n\nInstead you get:\n\n 
              \n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    1\n
              \n \nVariables are passed into C++ as if you are calling a Python function. Python's \ncalling convention is sometimes called \"pass by assignment\". This means its as \nif a c_a = a assignment is made right before inline \ncall is made and the c_a variable is used within the C++ code. \nThus, any changes made to c_a are not reflected in Python's \na variable. Things do get a little more confusing, however, when \nlooking at variables with mutable types. Changes made in C++ to the contents \nof mutable types are reflected in the Python variables.\n\n 
              \n    >>> a= [1,2]\n    >>> weave.inline(\"PyList_SetItem(a.ptr(),0,PyInt_FromLong(3));\",['a'])\n    >>> print a\n    [3, 2]\n
              \n\nSo modifications to the contents of mutable types in C++ are seen when control\nis returned to Python. Modifications to immutable types such as tuples,\nstrings, and numbers do not alter the Python variables.\n\nIf you need to make changes to an immutable variable, you'll need to assign\nthe new value to the \"magic\" variable return_val in C++. This\nvalue is returned by the inline() function:\n\n 
              \n    >>> a = 1\n    >>> a = weave.inline(\"return_val = Py::new_reference_to(Py::Int(a+1));\",['a'])  \n    >>> a\n    2\n
              \n\nThe return_val variable can also be used to return newly created \nvalues. This is possible by returning a tuple. The following trivial example \nillustrates how this can be done:\n\n 
                     \n    # python version\n    def multi_return():\n        return 1, '2nd'\n    \n    # C version.\n    def c_multi_return():    \n        code =  \"\"\"\n     \t        Py::Tuple results(2);\n     \t        results[0] = Py::Int(1);\n     \t        results[1] = Py::String(\"2nd\");\n     \t        return_val = Py::new_reference_to(results); \t        \n                \"\"\"\n        return inline_tools.inline(code)\n
              \n

              \nThe example is available in examples/tuple_return.py. It also\nhas the dubious honor of demonstrating how much inline() can \nslow things down. The C version here is about 10 times slower than the Python\nversion. Of course, something so trivial has no reason to be written in\nC anyway.\n\n\n

              The issue with locals()

              \n

              \ninline passes the locals() and globals() \ndictionaries from Python into the C++ function from the calling function. It \nextracts the variables that are used in the C++ code from these dictionaries, \nconverts then to C++ variables, and then calculates using them. It seems like \nit would be trivial, then, after the calculations were finished to then insert \nthe new values back into the locals() and globals() \ndictionaries so that the modified values were reflected in Python. \nUnfortunately, as pointed out by the Python manual, the locals() dictionary is \nnot writable. \n

              \n\nI suspect locals() is not writable because there are some \noptimizations done to speed lookups of the local namespace. I'm guessing local \nlookups don't always look at a dictionary to find values. Can someone \"in the \nknow\" confirm or correct this? Another thing I'd like to know is whether there \nis a way to write to the local namespace of another stack frame from C/C++. If \nso, it would be possible to have some clean up code in compiled functions that \nwrote final values of variables in C++ back to the correct Python stack frame. \nI think this goes a long way toward making inline truely live up \nto its name. I don't think we'll get to the point of creating variables in \nPython for variables created in C -- although I suppose with a C/C++ parser you \ncould do that also.\n\n

              \n\n\n

              A quick look at the code

              \n\nweave generates a C++ file holding an extension function for \neach inline code snippet. These file names are generated using \nfrom the md5 signature of the code snippet and saved to a location specified by \nthe PYTHONCOMPILED environment variable (discussed later). The cpp files are \ngenerally about 200-400 lines long and include quite a few functions to support \ntype conversions, etc. However, the actual compiled function is pretty simple. \nBelow is the familiar printf example:\n\n 
              \n    >>> import weave    \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n\nAnd here is the extension function generated by inline:\n\n 
              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        // The Py_None needs an incref before returning\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n        \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try                              \n        {                                \n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n            /* Here is the inline code */            \n            printf(\"%d\\n\",a);\n            /* I would like to fill in changed locals and globals here... */\n        }                                       \n        catch( Py::Exception& e)           \n        {                                \n            return_val =  Py::Null();    \n            exception_occured = 1;       \n        }                                 \n        if(!return_val && !exception_occured)\n        {\n                                      \n            Py_INCREF(Py_None);              \n            return_val = Py_None;            \n        }\n        /* clean up code */\n        \n        /* return */                              \n        return return_val;           \n    }                                \n
              \n\nEvery inline function takes exactly two arguments -- the local and global\ndictionaries for the current scope. All variable values are looked up out\nof these dictionaries. The lookups, along with all inline code \nexecution, are done within a C++ try block. If the variables\naren't found, or there is an error converting a Python variable to the \nappropriate type in C++, an exception is raised. The C++ exception\nis automatically converted to a Python exception by CXX and returned to Python.\n\nThe py_to_int() function illustrates how the conversions and\nexception handling works. py_to_int first checks that the given PyObject*\npointer is not NULL and is a Python integer. If all is well, it calls the\nPython API to convert the value to an int. Otherwise, it calls\nhandle_bad_type() which gathers information about what went wrong\nand then raises a CXX TypeError which returns to Python as a TypeError.\n\n 
              \n    int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\n 
              \n    void handle_bad_type(PyObject* py_obj, char* good_type, char*  var_name)\n    {\n        char msg[500];\n        sprintf(msg,\"received '%s' type instead of '%s' for variable '%s'\",\n                find_type(py_obj),good_type,var_name);\n        throw Py::TypeError(msg);\n    }\n    \n    char* find_type(PyObject* py_obj)\n    {\n        if(py_obj == NULL) return \"C NULL value\";\n        if(PyCallable_Check(py_obj)) return \"callable\";\n        if(PyString_Check(py_obj)) return \"string\";\n        if(PyInt_Check(py_obj)) return \"int\";\n        if(PyFloat_Check(py_obj)) return \"float\";\n        if(PyDict_Check(py_obj)) return \"dict\";\n        if(PyList_Check(py_obj)) return \"list\";\n        if(PyTuple_Check(py_obj)) return \"tuple\";\n        if(PyFile_Check(py_obj)) return \"file\";\n        if(PyModule_Check(py_obj)) return \"module\";\n        \n        //should probably do more interagation (and thinking) on these.\n        if(PyCallable_Check(py_obj) && PyInstance_Check(py_obj)) return \"callable\";\n        if(PyInstance_Check(py_obj)) return \"instance\"; \n        if(PyCallable_Check(py_obj)) return \"callable\";\n        return \"unkown type\";\n    }\n
              \n\nSince the inline is also executed within the try/catch\nblock, you can use CXX exceptions within your code. It is usually a bad idea\nto directly return from your code, even if an error occurs. This\nskips the clean up section of the extension function. In this simple example,\nthere isn't any clean up code, but in more complicated examples, there may\nbe some reference counting that needs to be taken care of here on converted\nvariables. To avoid this, either uses exceptions or set \nreturn_val to NULL and use if/then's to skip code\nafter errors.\n\n\n

              Technical Details

              \n

              \nThere are several main steps to using C/C++ code withing Python:\n

                \n
              1. Type conversion \n
              2. Generating C/C++ code \n
              3. Compile the code to an extension module \n
              4. Catalog (and cache) the function for future use
                5. \n
              \n

              \nItems 1 and 2 above are related, but most easily discussed separately. Type \nconversions are customizable by the user if needed. Understanding them is \npretty important for anything beyond trivial uses of inline. \nGenerating the C/C++ code is handled by ext_function and \next_module classes and . For the most part, compiling the code is \nhandled by distutils. Some customizations were needed, but they were \nrelatively minor and do not require changes to distutils itself. Cataloging is \npretty simple in concept, but surprisingly required the most code to implement \n(and still likely needs some work). So, this section covers items 1 and 4 from \nthe list. Item 2 is covered later in the chapter covering the \next_tools module, and distutils is covered by a completely \nseparate document xxx.\n\n

              Passing Variables in/out of the C/C++ code

              \n\nNote: Passing variables into the C code is pretty straight forward, but there \nare subtlties to how variable modifications in C are returned to Python. see Returning Values for a more thorough discussion of \nthis issue.\n \n \n\n

              Type Conversions

              \n\n\nNote: Maybe xxx_converter instead of \nxxx_specification is a more descriptive name. Might change in \nfuture version?\n\n\n

              \nBy default, inline() makes the following type conversions between\nPython and C++ types.\n

              \n\n

              \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
              \n

              Default Data Type Conversions

              \n

              Python

              		\n

              C++

                 int   int
                 float   double
                 complex   std::complex
                 string   Py::String
                 list   Py::List
                 dict   Py::Dict
                 tuple   Py::Tuple
                 file   FILE*
                 callable   PyObject*
                 instance   PyObject*
                 Numeric.array   PyArrayObject*
                 wxXXX   wxXXX*
              \n
              \n

              \nThe Py:: namespace is defined by the \nCXX library which has C++ class\nequivalents for many Python types. std:: is the namespace of the\nstandard library in C++.\n

              \n\nNote: \n

                \n
              • I haven't figured out how to handle long int yet (I think they are currenlty converted \n to int - - check this). \n \n
              • \nHopefully VTK will be added to the list soon
                • \n
              \n\n

              \n\nPython to C++ conversions fill in code in several locations in the generated\ninline extension function. Below is the basic template for the\nfunction. This is actually the exact code that is generated by calling\nweave.inline(\"\").\n\n 

              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n    \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try\n        {\n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            /* argument conversion code */\n            /* inline code */\n            /*I would like to fill in changed locals and globals here...*/\n    \n        }\n        catch( Py::Exception& e)\n        {\n            return_val =  Py::Null();\n            exception_occured = 1;\n        }\n        /* cleanup code */\n        if(!return_val && !exception_occured)\n        {\n    \n            Py_INCREF(Py_None);\n            return_val = Py_None;\n        }\n    \n        return return_val;\n    }\n
              \n\nThe /* inline code */ section is filled with the code passed to\nthe inline() function call. The \n/*argument convserion code*/ and /* cleanup code */\nsections are filled with code that handles conversion from Python to C++\ntypes and code that deallocates memory or manipulates reference counts before\nthe function returns. The following sections demostrate how these two areas\nare filled in by the default conversion methods.\n\n \nNote: I'm not sure I have reference counting correct on a few of these. The \nonly thing I increase/decrease the ref count on is Numeric arrays. If you\nsee an issue, please let me know.\n\n\n\n

              Numeric Argument Conversion

              \n\nInteger, floating point, and complex arguments are handled in a very similar\nfashion. Consider the following inline function that has a single integer \nvariable passed in:\n\n 
              \n    >>> a = 1\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_int() has the following\nform:\n\n 
              \n    static int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\nSimilarly, the float and complex conversion routines look like:\n\n 
                  \n    static double py_to_float(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyFloat_Check(py_obj))\n            handle_bad_type(py_obj,\"float\", name);\n        return PyFloat_AsDouble(py_obj);\n    }\n    \n    static std::complex py_to_complex(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyComplex_Check(py_obj))\n            handle_bad_type(py_obj,\"complex\", name);\n        return std::complex(PyComplex_RealAsDouble(py_obj),\n                                    PyComplex_ImagAsDouble(py_obj));    \n    }\n
              \n\nNumeric conversions do not require any clean up code.\n\n\n

              String, List, Tuple, and Dictionary Conversion

              \n\nStrings, Lists, Tuples and Dictionary conversions are all converted to \nCXX types by default.\n\nFor the following code, \n\n 
              \n    >>> a = [1]\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    Py::List a = py_to_list (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_list() and its\nfriends has the following form:\n\n 
                  \n    static Py::List py_to_list(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyList_Check(py_obj))\n            handle_bad_type(py_obj,\"list\", name);\n        return Py::List(py_obj);\n    }\n    \n    static Py::String py_to_string(PyObject* py_obj,char* name)\n    {\n        if (!PyString_Check(py_obj))\n            handle_bad_type(py_obj,\"string\", name);\n        return Py::String(py_obj);\n    }\n\n    static Py::Dict py_to_dict(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyDict_Check(py_obj))\n            handle_bad_type(py_obj,\"dict\", name);\n        return Py::Dict(py_obj);\n    }\n    \n    static Py::Tuple py_to_tuple(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyTuple_Check(py_obj))\n            handle_bad_type(py_obj,\"tuple\", name);\n        return Py::Tuple(py_obj);\n    }\n
              \n\nCXX handles reference counts on for strings, lists, tuples, and dictionaries,\nso clean up code isn't necessary.\n\n\n

              File Conversion

              \n\nFor the following code, \n\n 
              \n    >>> a = open(\"bob\",'w')  \n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code is:\n\n 
              \n    /* argument conversion code */\n    PyObject* py_a = get_variable(\"a\",raw_locals,raw_globals);\n    FILE* a = py_to_file(py_a,\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_file() converts\nPyObject* to a FILE* and increments the reference count of the PyObject*:\n\n 
              \n    FILE* py_to_file(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"file\", name);\n    \n        Py_INCREF(py_obj);\n        return PyFile_AsFile(py_obj);\n    }\n
              \n\nBecause the PyObject* was incremented, the clean up code needs to decrement\nthe counter\n\n 
              \n    /* cleanup code */\n    Py_XDECREF(py_a);\n
              \n\nIts important to understand that file conversion only works on actual files --\ni.e. ones created using the open() command in Python. It does\nnot support converting arbitrary objects that support the file interface into\nC FILE* pointers. This can affect many things. For example, in\ninitial printf() examples, one might be tempted to solve the \nproblem of C and Python IDE's (PythonWin, PyCrust, etc.) writing to different\nstdout and stderr by using fprintf() and passing in \nsys.stdout and sys.stderr. For example, instead of\n\n 
              \n    >>> weave.inline('printf(\"hello\\\\n\");')\n
              \n \nYou might try:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n
              \n\nThis will work as expected from a standard python interpreter, but in PythonWin,\nthe following occurs:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n    Traceback (most recent call last):\n        File \"\", line 1, in ?\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 315, in inline\n            auto_downcast = auto_downcast,\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 386, in compile_function\n            type_factories = type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 197, in __init__\n            auto_downcast, type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 390, in assign_variable_types\n            raise TypeError, format_error_msg(errors)\n        TypeError: {'buf': \"Unable to convert variable 'buf' to a C++ type.\"}\n
              \n\nThe traceback tells us that inline() was unable to convert 'buf' to a\nC++ type (If instance conversion was implemented, the error would have occurred at \nruntime instead). Why is this? Let's look at what the buf object \nreally is:\n\n 
              \n    >>> buf\n    pywin.framework.interact.InteractiveView instance at 00EAD014\n
              \n\nPythonWin has reassigned sys.stdout to a special object that \nimplements the Python file interface. This works great in Python, but since \nthe special object doesn't have a FILE* pointer underlying it, fprintf doesn't \nknow what to do with it (well this will be the problem when instance conversion \nis implemented...).\n\n\n

              Callable, Instance, and Module Conversion

              \n\nNote: Need to look into how ref counts should be handled. Also,\nInstance and Module conversion are not currently implemented.\n\n\n 
              \n    >>> def a(): \n        pass\n    >>> inline(\"\",['a'])\n
              \n\nCallable and instance variables are converted to PyObject*. Nothing is done\nto there reference counts.\n\n 
              \n    /* argument conversion code */\n    PyObject* a = py_to_callable(get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. The py_to_callable() and\npy_to_instance() don't currently increment the ref count.\n\n 
                  \n    PyObject* py_to_callable(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyCallable_Check(py_obj))\n            handle_bad_type(py_obj,\"callable\", name);    \n        return py_obj;\n    }\n\n    PyObject* py_to_instance(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"instance\", name);    \n        return py_obj;\n    }\n
              \n \nThere is no cleanup code for callables, modules, or instances.\n\n\n

              Customizing Conversions

              \n

              \nConverting from Python to C++ types is handled by xxx_specification classes. A \ntype specification class actually serve in two related but different \nroles. The first is in determining whether a Python variable that needs to be \nconverted should be represented by the given class. The second is as a code \ngenerator that generate C++ code needed to convert from Python to C++ types for \na specific variable.\n

              \nWhen \n\n 

              \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\",a);',['a'])\n
              \n \nis called for the first time, the code snippet has to be compiled. In this \nprocess, the variable 'a' is tested against a list of type specifications (the \ndefault list is stored in weave/ext_tools.py). The first \nspecification in the list is used to represent the variable. \n\n

              \nExamples of xxx_specification are scattered throughout numerous \n\"xxx_spec.py\" files in the weave package. Closely related to \nthe xxx_specification classes are yyy_info classes. \nThese classes contain compiler, header, and support code information necessary \nfor including a certain set of capabilities (such as blitz++ or CXX support)\nin a compiled module. xxx_specification classes have one or more\nyyy_info classes associated with them.\n\nIf you'd like to define your own set of type specifications, the current best route\nis to examine some of the existing spec and info files. Maybe looking over\nsequence_spec.py and cxx_info.py are a good place to start. After defining \nspecification classes, you'll need to pass them into inline using the \ntype_factories argument. \n\nA lot of times you may just want to change how a specific variable type is \nrepresented. Say you'd rather have Python strings converted to \nstd::string or maybe char* instead of using the CXX \nstring object, but would like all other type conversions to have default \nbehavior. This requires that a new specification class that handles strings\nis written and then prepended to a list of the default type specifications. Since\nit is closer to the front of the list, it effectively overrides the default\nstring specification.\n\nThe following code demonstrates how this is done:\n\n...\n\n\n

              The Catalog

              \n

              \ncatalog.py has a class called catalog that helps keep \ntrack of previously compiled functions. This prevents inline() \nand related functions from having to compile functions everytime they are \ncalled. Instead, catalog will check an in memory cache to see if the function \nhas already been loaded into python. If it hasn't, then it starts searching \nthrough persisent catalogs on disk to see if it finds an entry for the given \nfunction. By saving information about compiled functions to disk, it isn't\nnecessary to re-compile functions everytime you stop and restart the interpreter.\nFunctions are compiled once and stored for future use.\n\n

              \nWhen inline(cpp_code) is called the following things happen:\n

                \n
              1. \n A fast local cache of functions is checked for the last function called for \n cpp_code. If an entry for cpp_code doesn't exist in the \n cache or the cached function call fails (perhaps because the function doesn't \n have compatible types) then the next step is to check the catalog. \n
              2. \n The catalog class also keeps an in-memory cache with a list of all the \n functions compiled for cpp_code. If cpp_code has\n ever been called, then this cache will be present (loaded from disk). If\n the cache isn't present, then it is loaded from disk.\n

                \n If the cache is present, each function in the cache is \n called until one is found that was compiled for the correct argument types. If \n none of the functions work, a new function is compiled with the given argument \n types. This function is written to the on-disk catalog as well as into the \n in-memory cache.

                \n
              3. \n When a lookup for cpp_code fails, the catalog looks through \n the on-disk function catalogs for the entries. The PYTHONCOMPILED variable \n determines where to search for these catalogs and in what order. If \n PYTHONCOMPILED is not present several platform dependent locations are \n searched. All functions found for cpp_code in the path are \n loaded into the in-memory cache with functions found earlier in the search \n path closer to the front of the call list.\n

                \n If the function isn't found in the on-disk catalog, \n then the function is compiled, written to the first writable directory in the \n PYTHONCOMPILED path, and also loaded into the in-memory cache.

                \n
                4. \n
              \n\n\n

              Function Storage: How functions are stored in caches and on disk

              \n

              \nFunction caches are stored as dictionaries where the key is the entire C++\ncode string and the value is either a single function (as in the \"level 1\"\ncache) or a list of functions (as in the main catalog cache). On disk\ncatalogs are stored in the same manor using standard Python shelves.\n

              \nEarly on, there was a question as to whether md5 check sums of the C++\ncode strings should be used instead of the actual code strings. I think this\nis the route inline Perl took. Some (admittedly quick) tests of the md5 vs.\nthe entire string showed that using the entire string was at least a\nfactor of 3 or 4 faster for Python. I think this is because it is more\ntime consuming to compute the md5 value than it is to do look-ups of long\nstrings in the dictionary. Look at the examples/md5_speed.py file for the\ntest run. \n\n\n

              Catalog search paths and the PYTHONCOMPILED variable

              \n

              \nThe default location for catalog files on Unix is is ~/.pythonXX_compiled where \nXX is version of Python being used. If this directory doesn't exist, it is \ncreated the first time a catalog is used. The directory must be writable. If, \nfor any reason it isn't, then the catalog attempts to create a directory based \non your user id in the /tmp directory. The directory permissions are set so \nthat only you have access to the directory. If this fails, I think you're out of \nluck. I don't think either of these should ever fail though. On Windows, a \ndirectory called pythonXX_compiled is created in the user's temporary \ndirectory. \n

              \nThe actual catalog file that lives in this directory is a Python shelve with\na platform specific name such as \"nt21compiled_catalog\" so that multiple OSes\ncan share the same file systems without trampling on each other. Along with\nthe catalog file, the .cpp and .so or .pyd files created by inline will live\nin this directory. The catalog file simply contains keys which are the C++\ncode strings with values that are lists of functions. The function lists point\nat functions within these compiled modules. Each function in the lists \nexecutes the same C++ code string, but compiled for different input variables.\n

              \nYou can use the PYTHONCOMPILED environment variable to specify alternative\nlocations for compiled functions. On Unix this is a colon (':') separated\nlist of directories. On windows, it is a (';') separated list of directories.\nThese directories will be searched prior to the default directory for a\ncompiled function catalog. Also, the first writable directory in the list\nis where all new compiled function catalogs, .cpp and .so or .pyd files are\nwritten. Relative directory paths ('.' and '..') should work fine in the\nPYTHONCOMPILED variable as should environement variables.\n

              \nThere is a \"special\" path variable called MODULE that can be placed in the \nPYTHONCOMPILED variable. It specifies that the compiled catalog should\nreside in the same directory as the module that called it. This is useful\nif an admin wants to build a lot of compiled functions during the build\nof a package and then install them in site-packages along with the package.\nUser's who specify MODULE in their PYTHONCOMPILED variable will have access\nto these compiled functions. Note, however, that if they call the function\nwith a set of argument types that it hasn't previously been built for, the\nnew function will be stored in their default directory (or some other writable\ndirectory in the PYTHONCOMPILED path) because the user will not have write\naccess to the site-packages directory.\n

              \nAn example of using the PYTHONCOMPILED path on bash follows:\n\n 

              \n    PYTHONCOMPILED=MODULE:/some/path;export PYTHONCOMPILED;\n
              \n\nIf you are using python21 on linux, and the module bob.py in site-packages\nhas a compiled function in it, then the catalog search order when calling that\nfunction for the first time in a python session would be:\n\n 
              \n    /usr/lib/python21/site-packages/linuxpython_compiled\n    /some/path/linuxpython_compiled\n    ~/.python21_compiled/linuxpython_compiled\n
              \n\nThe default location is always included in the search path.\n

              \n \nNote: hmmm. see a possible problem here. I should probably make a sub-\ndirectory such as /usr/lib/python21/site-\npackages/python21_compiled/linuxpython_compiled so that library files compiled \nwith python21 are tried to link with python22 files in some strange scenarios. \nNeed to check this.\n\n\n

              \nThe in-module cache (in weave.inline_tools reduces the overhead \nof calling inline functions by about a factor of 2. It can be reduced a little \nmore for type loop calls where the same function is called over and over again \nif the cache was a single value instead of a dictionary, but the benefit is \nvery small (less than 5%) and the utility is quite a bit less. So, we'll stick \nwith a dictionary as the cache.\n

              \n\n\n

              Blitz

              \n Note: most of this section is lifted from old documentation. It should be\npretty accurate, but there may be a few discrepancies.\n

              \nweave.blitz() compiles Numeric Python expressions for fast \nexecution. For most applications, compiled expressions should provide a \nfactor of 2-10 speed-up over Numeric arrays. Using compiled \nexpressions is meant to be as unobtrusive as possible and works much like \npythons exec statement. As an example, the following code fragment takes a 5 \npoint average of the 512x512 2d image, b, and stores it in array, a:\n\n 

              \n    from scipy import *  # or from Numeric import *\n    a = ones((512,512), Float64) \n    b = ones((512,512), Float64) \n    # ...do some stuff to fill in b...\n    # now average\n    a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] \\\n                   + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n
              \n \nTo compile the expression, convert the expression to a string by putting\nquotes around it and then use weave.blitz:\n\n 
              \n    import weave\n    expr = \"a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n                          \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n    weave.blitz(expr)\n
              \n\nThe first time weave.blitz is run for a given expression and \nset of arguements, C++ code that accomplishes the exact same task as the Python \nexpression is generated and compiled to an extension module. This can take up \nto a couple of minutes depending on the complexity of the function. Subsequent \ncalls to the function are very fast. Futher, the generated module is saved \nbetween program executions so that the compilation is only done once for a \ngiven expression and associated set of array types. If the given expression\nis executed with a new set of array types, the code most be compiled again. This\ndoes not overwrite the previously compiled function -- both of them are saved and\navailable for exectution. \n

              \nThe following table compares the run times for standard Numeric code and \ncompiled code for the 5 point averaging.\n

              \n

              \n\n\n\n\n\n
              Method Run Time (seconds)
              Standard Numeric 0.46349
              blitz (1st time compiling) 78.95526
              blitz (subsequent calls) 0.05843 (factor of 8 speedup)
              \n
              \n

              \nThese numbers are for a 512x512 double precision image run on a 400 MHz Celeron \nprocessor under RedHat Linux 6.2.\n

              \nBecause of the slow compile times, its probably most effective to develop \nalgorithms as you usually do using the capabilities of scipy or the Numeric \nmodule. Once the algorithm is perfected, put quotes around it and execute it \nusing weave.blitz. This provides the standard rapid \nprototyping strengths of Python and results in algorithms that run close to \nthat of hand coded C or Fortran.\n\n\n

              Requirements

              \n\nCurrently, the weave.blitz has only been tested under Linux \nwith gcc-2.95-3 and on Windows with Mingw32 (2.95.2). Its compiler \nrequirements are pretty heavy duty (see the \nblitz++ home page), so it won't \nwork with just any compiler. Particularly MSVC++ isn't up to snuff. A number \nof other compilers such as KAI++ will also work, but my suspicions are that gcc \nwill get the most use.\n\n\n

              Limitations

              \n
                \n
              1. \nCurrently, weave.blitz handles all standard mathematic \noperators except for the ** power operator. The built-in trigonmetric, log, \nfloor/ceil, and fabs functions might work (but haven't been tested). It also \nhandles all types of array indexing supported by the Numeric module. \n

                \nweave.blitz does not currently support operations that use \narray broadcasting, nor have any of the special purpose functions in Numeric \nsuch as take, compress, etc. been implemented. Note that there are no obvious \nreasons why most of this functionality cannot be added to scipy.weave, so it \nwill likely trickle into future versions. Using slice() objects \ndirectly instead of start:stop:step is also not supported.\n

                2. \n
              2. \nCurrently Python only works on expressions that include assignment such as\n \n 
                \n    >>> result = b + c + d\n
                \n\nThis means that the result array must exist before calling \nweave.blitz. Future versions will allow the following:\n\n 
                \n    >>> result = weave.blitz_eval(\"b + c + d\")\n
                \n
                3. \n
              3. \nweave.blitz works best when algorithms can be expressed in a \n\"vectorized\" form. Algorithms that have a large number of if/thens and other \nconditions are better hand written in C or Fortran. Further, the restrictions \nimposed by requiring vectorized expressions sometimes preclude the use of more \nefficient data structures or algorithms. For maximum speed in these cases, \nhand-coded C or Fortran code is the only way to go.\n
                4. \n
              4. \nOne other point deserves mention lest people be confused. \nweave.blitz is not a general purpose Python->C compiler. It \nonly works for expressions that contain Numeric arrays and/or \nPython scalar values. This focused scope concentrates effort on the \ncompuationally intensive regions of the program and sidesteps the difficult \nissues associated with a general purpose Python->C compiler.\n
                5. \n
              \n\n\n

              Numeric efficiency issues: What compilation buys you

              \n\nSome might wonder why compiling Numeric expressions to C++ is beneficial since \noperations on Numeric array operations are already executed within C loops. \nThe problem is that anything other than the simplest expression are executed in \nless than optimal fashion. Consider the following Numeric expression:\n\n 
              \n    a = 1.2 * b + c * d\n
              \n \nWhen Numeric calculates the value for the 2d array, a, it does \nthe following steps:\n\n 
              \n    temp1 = 1.2 * b\n    temp2 = c * d\n    a = temp1 + temp2\n
              \n \nTwo things to note. Since c is an (perhaps large) array, a large \ntemporary array must be created to store the results of 1.2 * b. \nThe same is true for temp2. Allocation is slow. The second thing \nis that we have 3 loops executing, one to calculate temp1, one for \ntemp2 and one for adding them up. A C loop for the same problem \nmight look like:\n\n 
              \n    for(int i = 0; i < M; i++)\n        for(int j = 0; j < N; j++)\n            a[i,j] = 1.2 * b[i,j] + c[i,j] * d[i,j]\n
              \n \nHere, the 3 loops have been fused into a single loop and there is no longer\na need for a temporary array. This provides a significant speed improvement\nover the above example (write me and tell me what you get). \n

              \nSo, converting Numeric expressions into C/C++ loops that fuse the loops and \neliminate temporary arrays can provide big gains. The goal then,is to convert \nNumeric expression to C/C++ loops, compile them in an extension module, and \nthen call the compiled extension function. The good news is that there is an \nobvious correspondence between the Numeric expression above and the C loop. The \nbad news is that Numeric is generally much more powerful than this simple \nexample illustrates and handling all possible indexing possibilities results in \nloops that are less than straight forward to write. (take a peak in Numeric for \nconfirmation). Luckily, there are several available tools that simplify the \nprocess.\n\n\n

              The Tools

              \n\nweave.blitz relies heavily on several remarkable tools. On the \nPython side, the main facilitators are Jermey Hylton's parser module and Jim \nHuginin's Numeric module. On the compiled language side, Todd Veldhuizen's \nblitz++ array library, written in C++ (shhhh. don't tell David Beazley), does \nthe heavy lifting. Don't assume that, because it's C++, it's much slower than C \nor Fortran. Blitz++ uses a jaw dropping array of template techniques \n(metaprogramming, template expression, etc) to convert innocent looking and \nreadable C++ expressions into to code that usually executes within a few \npercentage points of Fortran code for the same problem. This is good. \nUnfortunately all the template raz-ma-taz is very expensive to compile, so the \n200 line extension modules often take 2 or more minutes to compile. This isn't so \ngood. weave.blitz works to minimize this issue by remembering \nwhere compiled modules live and reusing them instead of re-compiling every time \na program is re-run.\n\n\n

              Parser

              \nTearing Numeric expressions apart, examining the pieces, and then rebuilding \nthem as C++ (blitz) expressions requires a parser of some sort. I can imagine \nsomeone attacking this problem with regular expressions, but it'd likely be \nugly and fragile. Amazingly, Python solves this problem for us. It actually \nexposes its parsing engine to the world through the parser module. \nThe following fragment creates an Abstract Syntax Tree (AST) object for the \nexpression and then converts to a (rather unpleasant looking) deeply nested list \nrepresentation of the tree. \n \n 
              \n    >>> import parser\n    >>> import scipy.weave.misc\n    >>> ast = parser.suite(\"a = b * c + d\")\n    >>> ast_list = ast.tolist()\n    >>> sym_list = scipy.weave.misc.translate_symbols(ast_list)\n    >>> pprint.pprint(sym_list)\n    ['file_input',\n     ['stmt',\n      ['simple_stmt',\n       ['small_stmt',\n        ['expr_stmt',\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'a']]]]]]]]]]]]]]],\n         ['EQUAL', '='],\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'b']]]],\n                    ['STAR', '*'],\n                    ['factor', ['power', ['atom', ['NAME', 'c']]]]],\n                   ['PLUS', '+'],\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'd']]]]]]]]]]]]]]]]],\n       ['NEWLINE', '']]],\n     ['ENDMARKER', '']]\n
              \n\nDespite its looks, with some tools developed by Jermey H., its possible\nto search these trees for specific patterns (sub-trees), extract the \nsub-tree, manipulate them converting python specific code fragments\nto blitz code fragments, and then re-insert it in the parse tree. The parser\nmodule documentation has some details on how to do this. Traversing the \nnew blitzified tree, writing out the terminal symbols as you go, creates\nour new blitz++ expression string.\n\n \n

              Blitz and Numeric

              \nThe other nice discovery in the project is that the data structure used\nfor Numeric arrays and blitz arrays is nearly identical. Numeric stores\n\"strides\" as byte offsets and blitz stores them as element offsets, but\nother than that, they are the same. Further, most of the concept and\ncapabilities of the two libraries are remarkably similar. It is satisfying \nthat two completely different implementations solved the problem with \nsimilar basic architectures. It is also fortitous. The work involved in \nconverting Numeric expressions to blitz expressions was greatly diminished.\nAs an example, consider the code for slicing an array in Python with a\nstride:\n\n 
              \n    >>> a = b[0:4:2] + c\n    >>> a\n    [0,2,4]\n
              \n\n\nIn Blitz it is as follows:\n\n 
              \n    Array<2,int> b(10);\n    Array<2,int> c(3);\n    // ...\n    Array<2,int> a = b(Range(0,3,2)) + c;\n
              \n\n\nHere the range object works exactly like Python slice objects with the exception\nthat the top index (3) is inclusive where as Python's (4) is exclusive. Other \ndifferences include the type declaraions in C++ and parentheses instead of \nbrackets for indexing arrays. Currently, weave.blitz handles the \ninclusive/exclusive issue by subtracting one from upper indices during the\ntranslation. An alternative that is likely more robust/maintainable in the \nlong run, is to write a PyRange class that behaves like Python's range. \nThis is likely very easy.\n

              \nThe stock blitz also doesn't handle negative indices in ranges. The current \nimplementation of the blitz() has a partial solution to this \nproblem. It calculates and index that starts with a '-' sign by subtracting it \nfrom the maximum index in the array so that:\n\n 

              \n                    upper index limit\n                        /-----\\\n    b[:-1] -> b(Range(0,Nb[0]-1-1))\n
              \n\nThis approach fails, however, when the top index is calculated from other \nvalues. In the following scenario, if i+j evaluates to a negative \nvalue, the compiled code will produce incorrect results and could even core-\ndump. Right now, all calculated indices are assumed to be positive.\n \n 
              \n    b[:i-j] -> b(Range(0,i+j))\n
              \n\nA solution is to calculate all indices up front using if/then to handle the\n+/- cases. This is a little work and results in more code, so it hasn't been\ndone. I'm holding out to see if blitz++ can be modified to handle negative\nindexing, but haven't looked into how much effort is involved yet. While it \nneeds fixin', I don't think there is a ton of code where this is an issue.\n

              \nThe actual translation of the Python expressions to blitz expressions is \ncurrently a two part process. First, all x:y:z slicing expression are removed\nfrom the AST, converted to slice(x,y,z) and re-inserted into the tree. Any\nmath needed on these expressions (subtracting from the \nmaximum index, etc.) are also preformed here. _beg and _end are used as special\nvariables that are defined as blitz::fromBegin and blitz::toEnd.\n\n 

              \n    a[i+j:i+j+1,:] = b[2:3,:] \n
              \n\nbecomes a more verbose:\n \n 
              \n    a[slice(i+j,i+j+1),slice(_beg,_end)] = b[slice(2,3),slice(_beg,_end)]\n
              \n \nThe second part does a simple string search/replace to convert to a blitz \nexpression with the following translations:\n\n 
              \n    slice(_beg,_end) -> _all  # not strictly needed, but cuts down on code.\n    slice            -> blitz::Range\n    [                -> (\n    ]                -> )\n    _stp             -> 1\n
              \n\n_all is defined in the compiled function as \nblitz::Range.all(). These translations could of course happen \ndirectly in the syntax tree. But the string replacement is slightly easier. \nNote that name spaces are maintained in the C++ code to lessen the likelyhood \nof name clashes. Currently no effort is made to detect name clashes. A good \nrule of thumb is don't use values that start with '_' or 'py_' in compiled \nexpressions and you'll be fine.\n\n \n

              Type definitions and coersion

              \n\nSo far we've glossed over the dynamic vs. static typing issue between Python \nand C++. In Python, the type of value that a variable holds can change\nthrough the course of program execution. C/C++, on the other hand, forces you\nto declare the type of value a variables will hold prior at compile time.\nweave.blitz handles this issue by examining the types of the\nvariables in the expression being executed, and compiling a function for those\nexplicit types. For example:\n\n 
              \n    a = ones((5,5),Float32)\n    b = ones((5,5),Float32)\n    weave.blitz(\"a = a + b\")\n
              \n\nWhen compiling this expression to C++, weave.blitz sees that the\nvalues for a and b in the local scope have type Float32, or 'float'\non a 32 bit architecture. As a result, it compiles the function using \nthe float type (no attempt has been made to deal with 64 bit issues).\nIt also goes one step further. If all arrays have the same type, a templated\nversion of the function is made and instantiated for float, double, \ncomplex, and complex arrays. Note: This feature has been \nremoved from the current version of the code. Each version will be compiled\nseparately \n

              \nWhat happens if you call a compiled function with array types that are \ndifferent than the ones for which it was originally compiled? No biggie, you'll \njust have to wait on it to compile a new version for your new types. This \ndoesn't overwrite the old functions, as they are still accessible. See the \ncatalog section in the inline() documentation to see how this is handled. \nSuffice to say, the mechanism is transparent to the user and behaves \nlike dynamic typing with the occasional wait for compiling newly typed \nfunctions.\n

              \nWhen working with combined scalar/array operations, the type of the array is \nalways used. This is similar to the savespace flag that was recently \nadded to Numeric. This prevents issues with the following expression perhaps \nunexpectedly being calculated at a higher (more expensive) precision that can \noccur in Python:\n\n 

              \n    >>> a = array((1,2,3),typecode = Float32)\n    >>> b = a * 2.1 # results in b being a Float64 array.\n
              \n \nIn this example, \n\n 
              \n    >>> a = ones((5,5),Float32)\n    >>> b = ones((5,5),Float32)\n    >>> weave.blitz(\"b = a * 2.1\")\n
              \n \nthe 2.1 is cast down to a float before carrying out \nthe operation. If you really want to force the calculation to be a \ndouble, define a and b as \ndouble arrays.\n

              \nOne other point of note. Currently, you must include both the right hand side \nand left hand side (assignment side) of your equation in the compiled \nexpression. Also, the array being assigned to must be created prior to calling \nweave.blitz. I'm pretty sure this is easily changed so that a \ncompiled_eval expression can be defined, but no effort has been made to \nallocate new arrays (and decern their type) on the fly.\n\n \n

              Cataloging Compiled Functions

              \n\nSee the Cataloging functions section in the \nweave.inline() documentation.\n\n \n

              Checking Array Sizes

              \n\nSurprisingly, one of the big initial problems with compiled code was making\nsure all the arrays in an operation were of compatible type. The following\ncase is trivially easy:\n\n 
              \n    a = b + c\n
              \n \nIt only requires that arrays a, b, and c \nhave the same shape. However, expressions like:\n\n 
              \n    a[i+j:i+j+1,:] = b[2:3,:] + c\n
              \n\nare not so trivial. Since slicing is involved, the size of the slices, not the \ninput arrays must be checked. Broadcasting complicates things further because \narrays and slices with different dimensions and shapes may be compatible for \nmath operations (broadcasting isn't yet supported by \nweave.blitz). Reductions have a similar effect as their \nresults are different shapes than their input operand. The binary operators in \nNumeric compare the shapes of their two operands just before they operate on \nthem. This is possible because Numeric treats each operation independently. \nThe intermediate (temporary) arrays created during sub-operations in an \nexpression are tested for the correct shape before they are combined by another \noperation. Because weave.blitz fuses all operations into a \nsingle loop, this isn't possible. The shape comparisons must be done and \nguaranteed compatible before evaluating the expression.\n

              \nThe solution chosen converts input arrays to \"dummy arrays\" that only represent \nthe dimensions of the arrays, not the data. Binary operations on dummy arrays \ncheck that input array sizes are comptible and return a dummy array with the \nsize correct size. Evaluating an expression of dummy arrays traces the \nchanging array sizes through all operations and fails if incompatible array \nsizes are ever found. \n

              \nThe machinery for this is housed in weave.size_check. It \nbasically involves writing a new class (dummy array) and overloading it math \noperators to calculate the new sizes correctly. All the code is in Python and \nthere is a fair amount of logic (mainly to handle indexing and slicing) so the \noperation does impose some overhead. For large arrays (ie. 50x50x50), the \noverhead is negligible compared to evaluating the actual expression. For small \narrays (ie. 16x16), the overhead imposed for checking the shapes with this \nmethod can cause the weave.blitz to be slower than evaluating \nthe expression in Python. \n

              \nWhat can be done to reduce the overhead? (1) The size checking code could be \nmoved into C. This would likely remove most of the overhead penalty compared \nto Numeric (although there is also some calling overhead), but no effort has \nbeen made to do this. (2) You can also call weave.blitz with\ncheck_size=0 and the size checking isn't done. However, if the \nsizes aren't compatible, it can cause a core-dump. So, foregoing size_checking\nisn't advisable until your code is well debugged.\n\n \n

              Creating the Extension Module

              \n\nweave.blitz uses the same machinery as \nweave.inline to build the extension module. The only difference\nis the code included in the function is automatically generated from the\nNumeric array expression instead of supplied by the user.\n\n\n

              Extension Modules

              \nweave.inline and weave.blitz are high level tools\nthat generate extension modules automatically. Under the covers, they use several\nclasses from weave.ext_tools to help generate the extension module.\nThe main two classes are ext_module and ext_function (I'd\nlike to add ext_class and ext_method also). These classes\nsimplify the process of generating extension modules by handling most of the \"boiler\nplate\" code automatically.\n\n\nNote: inline actually sub-classes weave.ext_tools.ext_function \nto generate slightly different code than the standard ext_function.\nThe main difference is that the standard class converts function arguments to\nC types, while inline always has two arguments, the local and global dicts, and\nthe grabs the variables that need to be convereted to C from these.\n\n\n\n

              A Simple Example

              \nThe following simple example demonstrates how to build an extension module within\na Python function:\n\n 
              \n    # examples/increment_example.py\n    from weave import ext_tools\n    \n    def build_increment_ext():\n        \"\"\" Build a simple extension with functions that increment numbers.\n            The extension will be built in the local directory.\n        \"\"\"        \n        mod = ext_tools.ext_module('increment_ext')\n    \n        a = 1 # effectively a type declaration for 'a' in the \n              # following functions.\n    \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n        mod.add_function(func)\n        \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+2));\"    \n        func = ext_tools.ext_function('increment_by_2',ext_code,['a'])\n        mod.add_function(func)\n                \n        mod.compile()\n
              \n\n\nThe function build_increment_ext() creates an extension module \nnamed increment_ext and compiles it to a shared library (.so or \n.pyd) that can be loaded into Python.. increment_ext contains two \nfunctions, increment and increment_by_2. \n\nThe first line of build_increment_ext(),\n\n 
              \n        mod = ext_tools.ext_module('increment_ext') \n
              \n\ncreates an ext_module instance that is ready to have \next_function instances added to it. ext_function \ninstances are created much with a calling convention similar to \nweave.inline(). The most common call includes a C/C++ code \nsnippet and a list of the arguments for the function. The following\n\n 
              \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n
              \n \ncreates a C/C++ extension function that is equivalent to the following Python\nfunction:\n\n 
              \n        def increment(a):\n            return a + 1\n
              \n\nA second method is also added to the module and then,\n\n 
              \n        mod.compile()\n
              \n\nis called to build the extension module. By default, the module is created\nin the current working directory.\n\nThis example is available in the examples/increment_example.py file\nfound in the weave directory. At the bottom of the file in the\nmodule's \"main\" program, an attempt to import increment_ext without\nbuilding it is made. If this fails (the module doesn't exist in the PYTHONPATH), \nthe module is built by calling build_increment_ext(). This approach\nonly takes the time consuming ( a few seconds for this example) process of building\nthe module if it hasn't been built before.\n\n 
              \n    if __name__ == \"__main__\":\n        try:\n            import increment_ext\n        except ImportError:\n            build_increment_ext()\n            import increment_ext\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\n\nNote: If we were willing to always pay the penalty of building the C++ code for \na module, we could store the md5 checksum of the C++ code along with some \ninformation about the compiler, platform, etc. Then, \next_module.compile() could try importing the module before it actually\ncompiles it, check the md5 checksum and other meta-data in the imported module\nwith the meta-data of the code it just produced and only compile the code if\nthe module didn't exist or the meta-data didn't match. This would reduce the\nabove code to:\n\n 
              \n    if __name__ == \"__main__\":\n        build_increment_ext()\n\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\nNote: There would always be the overhead of building the C++ code, but it would only actually compile the code once. You pay a little in overhead and get cleaner\n\"import\" code. Needs some thought.\n\n

              \n\nIf you run increment_example.py from the command line, you get\nthe following:\n\n 

              \n    [eric@n0]$ python increment_example.py\n    a, a+1: 1 2\n    a, a+2: 1 3\n
              \n\nIf the module didn't exist before it was run, the module is created. If it did\nexist, it is just imported and used.\n\n\n

              Fibonacci Example

              \nexamples/fibonacci.py provides a little more complex example of \nhow to use ext_tools. Fibonacci numbers are a series of numbers \nwhere each number in the series is the sum of the previous two: 1, 1, 2, 3, 5, \n8, etc. Here, the first two numbers in the series are taken to be 1. One \napproach to calculating Fibonacci numbers uses recursive function calls. In \nPython, it might be written as:\n\n 
              \n    def fib(a):\n        if a <= 2:\n            return 1\n        else:\n            return fib(a-2) + fib(a-1)\n
              \n\nIn C, the same function would look something like this:\n\n 
              \n     int fib(int a)\n     {                   \n         if(a <= 2)\n             return 1;\n         else\n             return fib(a-2) + fib(a-1);  \n     }                      \n
              \n\nRecursion is much faster in C than in Python, so it would be beneficial\nto use the C version for fibonacci number calculations instead of the\nPython version. We need an extension function that calls this C function\nto do this. This is possible by including the above code snippet as \n\"support code\" and then calling it from the extension function. Support \ncode snippets (usually structure definitions, helper functions and the like)\nare inserted into the extension module C/C++ file before the extension\nfunction code. Here is how to build the C version of the fibonacci number\ngenerator:\n\n 
              \ndef build_fibonacci():\n    \"\"\" Builds an extension module with fibonacci calculators.\n    \"\"\"\n    mod = ext_tools.ext_module('fibonacci_ext')\n    a = 1 # this is effectively a type declaration\n    \n    # recursive fibonacci in C \n    fib_code = \"\"\"\n                   int fib1(int a)\n                   {                   \n                       if(a <= 2)\n                           return 1;\n                       else\n                           return fib1(a-2) + fib1(a-1);  \n                   }                         \n               \"\"\"\n    ext_code = \"\"\"\n                   int val = fib1(a);\n                   return_val = Py::new_reference_to(Py::Int(val));\n               \"\"\"    \n    fib = ext_tools.ext_function('fib',ext_code,['a'])\n    fib.customize.add_support_code(fib_code)\n    mod.add_function(fib)\n\n    mod.compile()\n\n
              \n\nXXX More about custom_info, and what xxx_info instances are good for.\n\n

              \n\nNote: recursion is not the fastest way to calculate fibonacci numbers, but this \napproach serves nicely for this example.\n\n

              \n\n

              Customizing Type Conversions -- Type Factories

              \nnot written\n\n

              Things I wish weave did

              \n\nIt is possible to get name clashes if you uses a variable name that is already defined\nin a header automatically included (such as stdio.h) For instance, if you\ntry to pass in a variable named stdout, you'll get a cryptic error report\ndue to the fact that stdio.h also defines the name. weave\nshould probably try and handle this in some way.\n\nOther things...", "source_code_before": "\n

              Weave Documentation

              \n

              \nBy Eric Jones eric@enthought.com\n

              \n

              Outline

              \n
              \n
              Introduction\n
              Requirements\n
              Installation\n
              Testing\n
              Benchmarks\n
              Inline\n
              \n
              More with printf\n
              \n More examples\n
              \n
              Binary search\n
              Dictionary sort\n
              Numeric -- cast/copy/transpose\n
              wxPython
              \n
              \n
              Keyword options\n
              Returning values\n
              \n
              \n The issue with locals()
              \n
              \n
              A quick look at the code\n
              \n Technical Details\n
              \n
              Converting Types\n
              \n
              \n Numeric Argument Conversion\n
              \n String, List, Tuple, and Dictionary Conversion\n
              File Conversion \n
              \n Callable, Instance, and Module Conversion \n
              Customizing Conversions\n
              \n
              Compiling Code\n
              \"Cataloging\" functions\n
              \n
              Function Storage\n
              The PYTHONCOMPILED evnironment variable
              \n
              \n
              \n
              \n
              \n
              \n
              Blitz\n
              \n
              Requirements\n
              Limitations\n
              Numeric Efficiency Issues\n
              The Tools \n
              \n
              Parser\n
              Blitz and Numeric\n
              \n
              Type defintions and coersion\n
              Cataloging Compiled Functions\n
              Checking Array Sizes\n
              Creating the Extension Module\n
              \n
              Extension Modules\n
              \n
              A Simple Example\n
              Fibonacci Example\n
              \n
              Customizing Type Conversions -- Type Factories (not written)\n
              \n
              Type Specifications\n
              Type Information\n
              The Conversion Process \n
              \n
              \n\n

              Introduction

              \n\n

              \nThe weave package provides tools for including C/C++ code within\nin Python code. This offers both another level of optimization to those who need \nit, and an easy way to modify and extend any supported extension libraries such \nas wxPython and hopefully VTK soon. Inlining C/C++ code within Python generally\nresults in speed ups of 1.5x to 30x speed-up over algorithms written in pure\nPython (However, it is also possible to slow things down...). Generally \nalgorithms that require a large number of calls to the Python API don't benefit\nas much from the conversion to C/C++ as algorithms that have inner loops \ncompletely convertable to C.\n

              \nThere are three basic ways to use weave. The \nweave.inline() function executes C code directly within Python, \nand weave.blitz() translates Python Numeric expressions to C++ \nfor fast execution. blitz() was the original reason \nweave was built. For those interested in building extension\nlibraries, the ext_tools module provides classes for building \nextension modules within Python. \n

              \nMost of weave's functionality should work on Windows and Unix, \nalthough some of its functionality requires gcc or a similarly \nmodern C++ compiler that handles templates well. Up to now, most testing has \nbeen done on Windows 2000 with Microsoft's C++ compiler (MSVC) and with gcc \n(mingw32 2.95.2 and 2.95.3-6). All tests also pass on Linux (RH 7.1 \nwith gcc 2.96), and I've had reports that it works on Debian also (thanks \nPearu).\n

              \nThe inline and blitz provide new functionality to \nPython (although I've recently learned about the PyInline project which may offer \nsimilar functionality to inline). On the other hand, tools for \nbuilding Python extension modules already exists (SWIG, SIP, pycpp, CXX, and \nothers). As of yet, I'm not sure where weave fits in this \nspectrum. It is closest in flavor to CXX in that it makes creating new C/C++ \nextension modules pretty easy. However, if you're wrapping a gaggle of legacy \nfunctions or classes, SWIG and friends are definitely the better choice. \nweave is set up so that you can customize how Python types are \nconverted to C types in weave. This is great for \ninline(), but, for wrapping legacy code, it is more flexible to \nspecify things the other way around -- that is how C types map to Python types. \nThis weave does not do. I guess it would be possible to build \nsuch a tool on top of weave, but with good tools like SWIG around, \nI'm not sure the effort produces any new capabilities. Things like function \noverloading are probably easily implemented in weave and it might \nbe easier to mix Python/C code in function calls, but nothing beyond this comes \nto mind. So, if you're developing new extension modules or optimizing Python \nfunctions in C, weave.ext_tools() might be the tool \nfor you. If you're wrapping legacy code, stick with SWIG.\n

              \nThe next several sections give the basics of how to use weave.\nWe'll discuss what's happening under the covers in more detail later \non. Serious users will need to at least look at the type conversion section to \nunderstand how Python variables map to C/C++ types and how to customize this \nbehavior. One other note. If you don't know C or C++ then these docs are \nprobably of very little help to you. Further, it'd be helpful if you know \nsomething about writing Python extensions. weave does quite a \nbit for you, but for anything complex, you'll need to do some conversions, \nreference counting, etc.\n

              \n\nNote: weave is actually part of the SciPy package. However, it works fine as a \nstandalone package. The examples here are given as if it is used as a stand \nalone package. If you are using from within scipy, you can use from \nscipy import weave and the examples will work identically.\n\n\n

              Requirements

              \n
                \n
              • Python\n

                \n I use 2.1.1. Probably 2.0 or higher should work.\n

                \n

                • \n \n
              • C++ compiler\n

                \n weave uses distutils to actually build \n extension modules, so it uses whatever compiler was originally used to \n build Python. weave itself requires a C++ compiler. If \n you used a C++ compiler to build Python, your probably fine.\n

                \n On Unix gcc is the preferred choice because I've done a little \n testing with it. All testing has been done with gcc, but I expect the \n majority of compilers should work for inline and \n ext_tools. The one issue I'm not sure about is that I've \n hard coded things so that compilations are linked with the \n stdc++ library. Is this standard across \n Unix compilers, or is this a gcc-ism?\n

                \n For blitz(), you'll need a reasonably recent version of \n gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n versions are likely to work. Its likely that KAI's C++ compiler and \n maybe some others will work, but I haven't tried. My advice is to use \n gcc for now unless your willing to tinker with the code some.\n

                \n On Windows, either MSVC or gcc (www.mingw.org\" > mingw32) should work. Again, \n you'll need gcc for blitz() as the\n MSVC compiler doesn't handle templates well.\n

                \n I have not tried Cygwin, so please report success if it works for you.\n

                \n

                • \n\n
              • Numeric (optional)\n

                \n The python Numeric module from here. is required for \n blitz() to work. Be sure and get NumPy, not NumArray\n which is the \"next generation\" implementation. This is not\n required for using inline() or ext_tools.\n

                \n

                • \n
              • scipy_distutils and scipy_test (packaged with weave)\n

                \n These two modules are packaged with weave in both\n the windows installer and the source distributions. If you are using\n CVS, however, you'll need to download these separately (also available\n through CVS at SciPy).\n

                \n

                • \n
              \n

              \n\n\n

              Installation

              \n

              \nThere are currently two ways to get weave. Fist, \nweave is part of SciPy and installed automatically (as a sub-\npackage) whenever SciPy is installed (although the latest version isn't in \nSciPy yet, so use this one for now). Second, since weave is \nuseful outside of the scientific community, it has been setup so that it can be\nused as a stand-alone module. \n\n

              \nThe stand-alone version can be downloaded from here. Unix users should grab the \ntar ball (.tgz file) and install it using the following commands.\n\n 

              \n    tar -xzvf weave-0.2.tar.gz\n    cd weave-0.2\n    python setup.py install\n
              \n\nThis will also install two other packages, scipy_distutils and \nscipy_test. The first is needed by the setup process itself and \nboth are used in the unit-testing process. Numeric is required if you want to \nuse blitz(), but isn't necessary for inline() or \next_tools\n

              \nFor Windows users, it's even easier. You can download the click-install .exe \nfile and run it for automatic installation. There is also a .zip file of the\nsource for those interested. It also includes a setup.py file to simplify\ninstallation. \n

              \nIf you're using the CVS version, you'll need to install \nscipy_distutils and scipy_test packages (also \navailable from CVS) on your own.\n

              \n \nNote: The dependency issue here is a little sticky. I hate to make people \ndownload more than one file (and so I haven't), but distutils doesn't have a \nway to do conditional installation -- at least that I know about. This can \nlead to undesired clobbering of the scipy_test and scipy_distutils modules. \nWhat to do, what to do... Right now it is a very minor issue.\n\n

              \n\n

              Testing

              \nOnce weave is installed, fire up python and run its unit tests.\n\n 
              \n    >>> import weave\n    >>> weave.test()\n    runs long time... spews tons of output and a few warnings\n    .\n    .\n    .\n    ..............................................................\n    ................................................................\n    ..................................................\n    ----------------------------------------------------------------------\n    Ran 184 tests in 158.418s\n\n    OK\n    \n    >>> \n
              \n\nThis takes a loooong time. On windows, it is usually several minutes. On Unix \nwith remote file systems, I've had it take 15 or so minutes. In the end, it \nshould run about 180 tests and spew some speed results along the way. If you \nget errors, they'll be reported at the end of the output. Please let me know\nwhat if this occurs.\n\nIf you don't have Numeric installed, you'll get some module import errors \nduring the test setup phase for modules that are Numeric specific (blitz_spec, \nblitz_tools, size_check, standard_array_spec, ast_tools), but all test should\npass (about 100 and they should complete in several minutes).\n

              \nIf you only want to test a single module of the package, you can do this by\nrunning test() for that specific module.\n\n 

              \n    >>> import weave.scalar_spec\n    >>> weave.scalar_spec.test()\n    .......\n    ----------------------------------------------------------------------\n    Ran 7 tests in 23.284s\n
              \n\nTesting Notes:\n
                \n
              • \n Windows 1\n

                \n I've had some test fail on windows machines where I have msvc, gcc-2.95.2 \n (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My \n environment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the \n path. The test process runs very smoothly until the end where several test \n using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') \n before running tests, I get gcc-2.95.3-6. If I check after running tests \n (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] \n still has c:\\gcc first in it and is not corrupted (msvc/distutils messes \n with the environment variables, so we have to undo its work in some \n places). If anyone else sees this, let me know - - it may just be an quirk \n on my machine (unlikely). Testing with the gcc- 2.95.2 installation always \n works.\n

                \n

                • \n
              • \n Windows 2\n

                \n If you run the tests from PythonWin or some other GUI tool, you'll get a\n ton of DOS windows popping up periodically as weave spawns\n the compiler multiple times. Very annoying. Anyone know how to fix this?\n

                \n

                • \n
              • \n wxPython\n

                \n wxPython tests are not enabled by default because importing wxPython on a \n Unix machine without access to a X-term will cause the program to exit. \n Anyone know of a safe way to detect whether wxPython can be imported and \n whether a display exists on a machine? \n

                \n

                • \n                \n\n

                \n

              \n\n\n

              Benchmarks

              \nThis section has a few benchmarks -- thats all people want to see anyway right? \nThese are mostly taken from running files in the weave/example \ndirectory and also from the test scripts. Without more information about what \nthe test actually do, their value is limited. Still, their here for the \ncurious. Look at the example scripts for more specifics about what problem was \nactually solved by each run. These examples are run under windows 2000 using \nMicrosoft Visual C++ and python2.1 on a 850 MHz PIII laptop with 320 MB of RAM.\n

              \n

              \n\n\n \n \n \n \n \n \n \n \n\n \n \n \n \n \n
              \n

              inline and ext_tools

              Algorithm

              Speed up

              binary search   1.50
              fibonacci (recursive)  82.10
              fibonacci (loop)   9.17
              return None   0.14
              map   1.20
              dictionary sort   2.54
              vector quantization  37.40
              \n

              blitz -- double precision

              Algorithm

              Speed up

              a = b + c 512x512   3.05
              a = b + c + d 512x512   4.59
              5 pt avg. filter, 2D Image 512x512   9.01
              Electromagnetics (FDTD) 100x100x100   8.61
              \n
              \n

              \n\n

              Inline

              \n

              \ninline() compiles and executes C/C++ code on the fly. Variables \nin the local and global Python scope are also available in the C/C++ code. \nValues are passed to the C/C++ code by assignment much like variables \nare passed into a standard Python function. Values are returned from the C/C++ \ncode through a special argument called return_val. Also, the contents of \nmutable objects can be changed within the C/C++ code and the changes remain \nafter the C code exits and returns to Python. (more on this later)\n

              \nHere's a trivial printf example using inline():\n\n 

              \n    >>> import weave    \n    >>> a  = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n

              \nIn this, its most basic form, inline(c_code, var_list) requires two \narguments. c_code is a string of valid C/C++ code. \nvar_list is a list of variable names that are passed from \nPython into C/C++. Here we have a simple printf statement that \nwrites the Python variable a to the screen. The first time you run \nthis, there will be a pause while the code is written to a .cpp file, compiled \ninto an extension module, loaded into Python, cataloged for future use, and \nexecuted. On windows (850 MHz PIII), this takes about 1.5 seconds when using \nMicrosoft's C++ compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). \nAll subsequent executions of the code will happen very quickly because the code \nonly needs to be compiled once. If you kill and restart the interpreter and then \nexecute the same code fragment again, there will be a much shorter delay in the \nfractions of seconds range. This is because weave stores a \ncatalog of all previously compiled functions in an on disk cache. When it sees \na string that has been compiled, it loads the already compiled module and \nexecutes the appropriate function. \n

              \n\nNote: If you try the printf example in a GUI shell such as IDLE, \nPythonWin, PyShell, etc., you're unlikely to see the output. This is because the \nC code is writing to stdout, instead of to the GUI window. This doesn't mean \nthat inline doesn't work in these environments -- it only means that standard \nout in C is not the same as the standard out for Python in these cases. Non \ninput/output functions will work as expected.\n\n

              \nAlthough effort has been made to reduce the overhead associated with calling \ninline, it is still less efficient for simple code snippets than using \nequivalent Python code. The simple printf example is actually \nslower by 30% or so than using Python print statement. And, it is \nnot difficult to create code fragments that are 8-10 times slower using inline \nthan equivalent Python. However, for more complicated algorithms, \nthe speed up can be worth while -- anywhwere from 1.5- 30 times faster. \nAlgorithms that have to manipulate Python objects (sorting a list) usually only \nsee a factor of 2 or so improvement. Algorithms that are highly computational \nor manipulate Numeric arrays can see much larger improvements. The \nexamples/vq.py file shows a factor of 30 or more improvement on the vector \nquantization algorithm that is used heavily in information theory and \nclassification problems.\n

              \n\n\n

              More with printf

              \n

              \nMSVC users will actually see a bit of compiler output that distutils does not\nsupress the first time the code executes:\n\n 

                  \n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    sc_e013937dbc8c647ac62438874e5795131.cpp\n       Creating library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\n       \\Release\\sc_e013937dbc8c647ac62438874e5795131.lib and object C:\\DOCUME\n       ~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_e013937dbc8c64\n       7ac62438874e5795131.exp\n    1\n
              \n

              \nNothing bad is happening, its just a bit annoying. Anyone know how to \nturn this off? \n

              \nThis example also demonstrates using 'raw strings'. The r \npreceeding the code string in the last example denotes that this is a 'raw \nstring'. In raw strings, the backslash character is not interpreted as an \nescape character, and so it isn't necessary to use a double backslash to \nindicate that the '\\n' is meant to be interpreted in the C printf \nstatement instead of by Python. If your C code contains a lot\nof strings and control characters, raw strings might make things easier.\nMost of the time, however, standard strings work just as well.\n\n

              \nThe printf statement in these examples is formatted to print \nout integers. What happens if a is a string? inline\nwill happily, compile a new version of the code to accept strings as input,\nand execute the code. The result?\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    32956972\n
              \n

              \nIn this case, the result is non-sensical, but also non-fatal. In other \nsituations, it might produce a compile time error because a is \nrequired to be an integer at some point in the code, or it could produce a \nsegmentation fault. Its possible to protect against passing \ninline arguments of the wrong data type by using asserts in \nPython.\n\n 

                  \n    >>> a = 'string'\n    >>> def protected_printf(a):    \n    ...     assert(type(a) == type(1))\n    ...     weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    >>> protected_printf(1)\n     1\n    >>> protected_printf('string')\n    AssertError...\n
              \n\n

              \nFor printing strings, the format statement needs to be changed.\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%s\\n\",a);',['a'])\n    string\n
              \n\n

              \nAs in this case, C/C++ code fragments often have to change to accept different \ntypes. For the given printing task, however, C++ streams provide a way of a \nsingle statement that works for integers and strings. By default, the stream \nobjects live in the std (standard) namespace and thus require the use of \nstd::.\n\n 

                  \n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    1    \n    >>> a = 'string'\n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    string\n
              \n \n

              \nExamples using printf and cout are included in \nexamples/print_example.py.\n\n\n

              More examples

              \n\nThis section shows several more advanced uses of inline. It \nincludes a few algorithms from the Python Cookbook \nthat have been re-written in inline C to improve speed as well as a couple \nexamples using Numeric and wxPython.\n\n\n

              Binary search

              \nLets look at the example of searching a sorted list of integers for a value. \nFor inspiration, we'll use Kalle Svensson's \nbinary_search() algorithm from the Python Cookbook. His recipe follows:\n\n 
              \n    def binary_search(seq, t):\n        min = 0; max = len(seq) - 1\n        while 1:\n            if max < min:\n                return -1\n            m = (min  + max)  / 2\n            if seq[m] < t: \n                min = m  + 1 \n            elif seq[m] > t: \n                max = m  - 1 \n            else:\n                return m    \n
              \n\nThis Python version works for arbitrary Python data types. The C version below is \nspecialized to handle integer values. There is a little type checking done in \nPython to assure that we're working with the correct data types before heading \ninto C. The variables seq and t don't need to be \ndeclared beacuse weave handles converting and declaring them in \nthe C code. All other temporary variables such as min, max, etc. \nmust be declared -- it is C after all. Here's the new mixed Python/C function:\n\n 
                  \n    def c_int_binary_search(seq,t):\n        # do a little type checking in Python\n        assert(type(t) == type(1))\n        assert(type(seq) == type([]))\n        \n        # now the C code\n        code = \"\"\"\n               #line 29 \"binary_search.py\"\n               int val, m, min = 0;  \n               int max = seq.length() - 1;\n               PyObject *py_val; \n               for(;;)\n               {\n                   if (max < min  ) \n                   { \n                       return_val =  Py::new_reference_to(Py::Int(-1)); \n                       break;\n                   } \n                   m =  (min + max) /2;\n                   val =    py_to_int(PyList_GetItem(seq.ptr(),m),\"val\"); \n                   if (val  < t) \n                       min = m  + 1;\n                   else if (val >  t)\n                       max = m - 1;\n                   else\n                   {\n                       return_val = Py::new_reference_to(Py::Int(m));\n                       break;\n                   }\n               }\n               \"\"\"\n        return inline(code,['seq','t'])\n
              \n

              \nWe have two variables seq and t passed in. \nt is guaranteed (by the assert) to be an integer. \nPython integers are converted to C int types in the transition from Python to \nC. seq is a Python list. By default, it is translated to a CXX \nlist object. Full documentation for the CXX library can be found at its website. The basics are that the CXX \nprovides C++ class equivalents for Python objects that simplify, or at \nleast object orientify, working with Python objects in C/C++. For example, \nseq.length() returns the length of the list. A little more about\nCXX and its class methods, etc. is in the ** type conversions ** section.\n

              \n\nNote: CXX uses templates and therefore may be a little less portable than \nanother alternative by Gordan McMillan called SCXX which was inspired by\nCXX. It doesn't use templates so it should compile faster and be more portable.\nSCXX has a few less features, but it appears to me that it would mesh with\nthe needs of weave quite well. Hopefully xxx_spec files will be written\nfor SCXX in the future, and we'll be able to compare on a more empirical\nbasis. Both sets of spec files will probably stick around, it just a question\nof which becomes the default.\n\n

              \nMost of the algorithm above looks similar in C to the original Python code. \nThere are two main differences. The first is the setting of \nreturn_val instead of directly returning from the C code with a \nreturn statement. return_val is an automatically \ndefined variable of type PyObject* that is returned from the C \ncode back to Python. You'll have to handle reference counting issues when \nsetting this variable. In this example, CXX classes and functions handle the \ndirty work. All CXX functions and classes live in the namespace \nPy::. The following code converts the integer m to a \nCXX Int() object and then to a PyObject* with an \nincremented reference count using Py::new_reference_to().\n\n 

                 \n    return_val = Py::new_reference_to(Py::Int(m));\n
              \n

              \nThe second big differences shows up in the retrieval of integer values from the \nPython list. The simple Python seq[i] call balloons into a C \nPython API call to grab the value out of the list and then a separate call to \npy_to_int() that converts the PyObject* to an integer. \npy_to_int() includes both a NULL cheack and a \nPyInt_Check() call as well as the conversion call. If either of \nthe checks fail, an exception is raised. The entire C++ code block is executed \nwith in a try/catch block that handles exceptions much like Python \ndoes. This removes the need for most error checking code.\n

              \nIt is worth note that CXX lists do have indexing operators that result \nin code that looks much like Python. However, the overhead in using them \nappears to be relatively high, so the standard Python API was used on the \nseq.ptr() which is the underlying PyObject* of the \nList object.\n

              \nThe #line directive that is the first line of the C code \nblock isn't necessary, but it's nice for debugging. If the compilation fails \nbecause of the syntax error in the code, the error will be reported as an error \nin the Python file \"binary_search.py\" with an offset from the given line number \n(29 here).\n

              \nSo what was all our effort worth in terms of efficiency? Well not a lot in \nthis case. The examples/binary_search.py file runs both Python and C versions \nof the functions As well as using the standard bisect module. If \nwe run it on a 1 million element list and run the search 3000 times (for 0-\n2999), here are the results we get:\n\n 

                 \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python binary_search.py\n    Binary search for 3000 items in 1000000 length list of integers:\n     speed in python: 0.159999966621\n     speed of bisect: 0.121000051498\n     speed up: 1.32\n     speed in c: 0.110000014305\n     speed up: 1.45\n     speed in c(no asserts): 0.0900000333786\n     speed up: 1.78\n
              \n

              \nSo, we get roughly a 50-75% improvement depending on whether we use the Python \nasserts in our C version. If we move down to searching a 10000 element list, \nthe advantage evaporates. Even smaller lists might result in the Python \nversion being faster. I'd like to say that moving to Numeric lists (and \ngetting rid of the GetItem() call) offers a substantial speed up, but my \npreliminary efforts didn't produce one. I think the log(N) algorithm is to \nblame. Because the algorithm is nice, there just isn't much time spent \ncomputing things, so moving to C isn't that big of a win. If there are ways to \nreduce conversion overhead of values, this may improve the C/Python speed \nup. Anyone have other explanations or faster code, please let me know.\n\n\n

              Dictionary Sort

              \n

              \nThe demo in examples/dict_sort.py is another example from the Python CookBook. \nThis \nsubmission, by Alex Martelli, demonstrates how to return the values from a \ndictionary sorted by their keys:\n\n 

                     \n    def sortedDictValues3(adict):\n        keys = adict.keys()\n        keys.sort()\n        return map(adict.get, keys)\n
              \n

              \nAlex provides 3 algorithms and this is the 3rd and fastest of the set. The C \nversion of this same algorithm follows:\n\n 

                     \n    def c_sort(adict):\n        assert(type(adict) == type({}))\n        code = \"\"\"     \n        #line 21 \"dict_sort.py\"  \n        Py::List keys = adict.keys();\n        Py::List items(keys.length()); keys.sort();     \n        PyObject* item = NULL; \n        for(int i = 0;  i < keys.length();i++)\n        {\n            item = PyList_GET_ITEM(keys.ptr(),i);\n            item = PyDict_GetItem(adict.ptr(),item);\n            Py_XINCREF(item);\n            PyList_SetItem(items.ptr(),i,item);              \n        }           \n        return_val = Py::new_reference_to(items);\n        \"\"\"   \n        return inline_tools.inline(code,['adict'],verbose=1)\n
              \n

              \nLike the original Python function, the C++ version can handle any Python \ndictionary regardless of the key/value pair types. It uses CXX objects for the \nmost part to declare python types in C++, but uses Python API calls to manipulate \ntheir contents. Again, this choice is made for speed. The C++ version, while\nmore complicated, is about a factor of 2 faster than Python.\n\n 

                     \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python dict_sort.py\n    Dict sort of 1000 items for 300 iterations:\n     speed in python: 0.319999933243\n    [0, 1, 2, 3, 4]\n     speed in c: 0.151000022888\n     speed up: 2.12\n    [0, 1, 2, 3, 4]\n
              \n

              \n\n

              Numeric -- cast/copy/transpose

              \n\nCastCopyTranspose is a function called quite heavily by Linear Algebra routines\nin the Numeric library. Its needed in part because of the row-major memory layout\nof multi-demensional Python (and C) arrays vs. the col-major order of the underlying\nFortran algorithms. For small matrices (say 100x100 or less), a significant\nportion of the common routines such as LU decompisition or singular value decompostion\nare spent in this setup routine. This shouldn't happen. Here is the Python\nversion of the function using standard Numeric operations.\n\n 
                     \n    def _castCopyAndTranspose(type, array):\n        if a.typecode() == type:\n            cast_array = copy.copy(Numeric.transpose(a))\n        else:\n            cast_array = copy.copy(Numeric.transpose(a).astype(type))\n        return cast_array\n
              \n\nAnd the following is a inline C version of the same function:\n\n 
              \n    from weave.blitz_tools import blitz_type_factories\n    from weave import scalar_spec\n    from weave import inline\n    def _cast_copy_transpose(type,a_2d):\n        assert(len(shape(a_2d)) == 2)\n        new_array = zeros(shape(a_2d),type)\n        numeric_type = scalar_spec.numeric_to_blitz_type_mapping[type]\n        code = \\\n        \"\"\"  \n        for(int i = 0;i < _Na_2d[0]; i++)  \n            for(int j = 0;  j < _Na_2d[1]; j++)\n                new_array(i,j) = (%s) a_2d(j,i);\n        \"\"\" % numeric_type\n        inline(code,['new_array','a_2d'],\n               type_factories = blitz_type_factories,compiler='gcc')\n        return new_array\n
              \n\nThis example uses blitz++ arrays instead of the standard representation of \nNumeric arrays so that indexing is simplier to write. This is accomplished by \npassing in the blitz++ \"type factories\" to override the standard Python to C++ \ntype conversions. Blitz++ arrays allow you to write clean, fast code, but they \nalso are sloooow to compile (20 seconds or more for this snippet). This is why \nthey aren't the default type used for Numeric arrays (and also because most \ncompilers can't compile blitz arrays...). inline() is also forced \nto use 'gcc' as the compiler because the default compiler on Windows (MSVC) \nwill not compile blitz code. 'gcc' I think will use the standard compiler \non Unix machine instead of explicitly forcing gcc (check this) \n\nComparisons of the Python vs inline C++ code show a factor of 3 speed up. Also \nshown are the results of an \"inplace\" transpose routine that can be used if the \noutput of the linear algebra routine can overwrite the original matrix (this is \noften appropriate). This provides another factor of 2 improvement.\n\n 
              \n     #C:\\home\\ej\\wrk\\scipy\\weave\\examples> python cast_copy_transpose.py\n    # Cast/Copy/Transposing (150,150)array 1 times\n    #  speed in python: 0.870999932289\n    #  speed in c: 0.25\n    #  speed up: 3.48\n    #  inplace transpose c: 0.129999995232\n    #  speed up: 6.70\n
              \n\n\n

              wxPython

              \n\ninline knows how to handle wxPython objects. Thats nice in and of\nitself, but it also demonstrates that the type conversion mechanism is reasonably \nflexible. Chances are, it won't take a ton of effort to support special types\nyou might have. The examples/wx_example.py borrows the scrolled window\nexample from the wxPython demo, accept that it mixes inline C code in the middle\nof the drawing function.\n\n 
              \n    def DoDrawing(self, dc):\n        \n        red = wxNamedColour(\"RED\");\n        blue = wxNamedColour(\"BLUE\");\n        grey_brush = wxLIGHT_GREY_BRUSH;\n        code = \\\n        \"\"\"\n        #line 108 \"wx_example.py\" \n        dc->BeginDrawing();\n        dc->SetPen(wxPen(*red,4,wxSOLID));\n        dc->DrawRectangle(5,5,50,50);\n        dc->SetBrush(*grey_brush);\n        dc->SetPen(wxPen(*blue,4,wxSOLID));\n        dc->DrawRectangle(15, 15, 50, 50);\n        \"\"\"\n        inline(code,['dc','red','blue','grey_brush'])\n        \n        dc.SetFont(wxFont(14, wxSWISS, wxNORMAL, wxNORMAL))\n        dc.SetTextForeground(wxColour(0xFF, 0x20, 0xFF))\n        te = dc.GetTextExtent(\"Hello World\")\n        dc.DrawText(\"Hello World\", 60, 65)\n\n        dc.SetPen(wxPen(wxNamedColour('VIOLET'), 4))\n        dc.DrawLine(5, 65+te[1], 60+te[0], 65+te[1])\n        ...\n
              \n\nHere, some of the Python calls to wx objects were just converted to C++ calls. There\nisn't any benefit, it just demonstrates the capabilities. You might want to use this\nif you have a computationally intensive loop in your drawing code that you want to \nspeed up.\n\nOn windows, you'll have to use the MSVC compiler if you use the standard wxPython\nDLLs distributed by Robin Dunn. Thats because MSVC and gcc, while binary\ncompatible in C, are not binary compatible for C++. In fact, its probably best, no \nmatter what platform you're on, to specify that inline use the same\ncompiler that was used to build wxPython to be on the safe side. There isn't currently\na way to learn this info from the library -- you just have to know. Also, at least\non the windows platform, you'll need to install the wxWindows libraries and link to \nthem. I think there is a way around this, but I haven't found it yet -- I get some\nlinking errors dealing with wxString. One final note. You'll probably have to\ntweak weave/wx_spec.py or weave/wx_info.py for your machine's configuration to\npoint at the correct directories etc. There. That should sufficiently scare people\ninto not even looking at this... :)\n\n              \n

              Keyword Options

              \n

              \nThe basic definition of the inline() function has a slew of \noptional variables. It also takes keyword arguments that are passed to \ndistutils as compiler options. The following is a formatted \ncut/paste of the argument section of inline's doc-string. It \nexplains all of the variables. Some examples using various options will \nfollow.\n\n 

                     \n    def inline(code,arg_names,local_dict = None, global_dict = None, \n               force = 0, \n               compiler='',\n               verbose = 0, \n               support_code = None,\n               customize=None, \n               type_factories = None, \n               auto_downcast=1,\n               **kw):\n
              \n\n \ninline has quite \na few options as listed below. Also, the keyword arguments for distutils \nextension modules are accepted to specify extra information needed for \ncompiling. \n
              \n

              inline Arguments:

              \n
              \n
              \n
              code
              \n \n
              \nstring. A string of valid C++ code. It should not \n specify a return statement. Instead it should assign results that need to be \n returned to Python in the return_val. \n
              \n\n
              arg_names
              \n \n
              \nlist of strings. A list of Python variable names \n that should be transferred from Python into the C/C++ code. \n
              \n\n
              local_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the local scope for the C/C++ \n code. If local_dict is not specified the local dictionary of the calling \n function is used. \n
              \n\n
              global_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the global scope for the C/C++ \n code. If global_dict is not specified the global dictionary of the calling \n function is used. \n
              \n\n
              force
              \n \n
              \noptional. 0 or 1. default 0. If 1, the C++ code is \n compiled every time inline is called. This is really only useful for \n debugging, and probably only useful if you're editing support_code a lot. \n
              \n\n
              compiler
              \n \n
              \noptional. string. The name of compiler to use when compiling. On windows, it \nunderstands 'msvc' and 'gcc' as well as all the compiler names understood by \ndistutils. On Unix, it'll only understand the values understoof by distutils. \n(I should add 'gcc' though to this).\n

              \nOn windows, the compiler defaults to the Microsoft C++ compiler. If this isn't \navailable, it looks for mingw32 (the gcc compiler).\n

              \nOn Unix, it'll probably use the same compiler that was used when compiling \nPython. Cygwin's behavior should be similar.

              \n
              \n\n
              verbose
              \n \n
              \noptional. 0,1, or 2. defualt 0. Speficies how much \n much information is printed during the compile phase of inlining code. 0 is \n silent (except on windows with msvc where it still prints some garbage). 1 \n informs you when compiling starts, finishes, and how long it took. 2 prints \n out the command lines for the compilation process and can be useful if you're \n having problems getting code to work. Its handy for finding the name of the \n .cpp file if you need to examine it. verbose has no affect if the \n compilation isn't necessary. \n
              \n\n
              support_code
              \n \n
              \noptional. string. A string of valid C++ code \n declaring extra code that might be needed by your compiled function. This \n could be declarations of functions, classes, or structures. \n
              \n\n
              customize
              \n \n
              \noptional. base_info.custom_info object. An \n alternative way to specifiy support_code, headers, etc. needed by the \n function see the weave.base_info module for more details. (not sure \n this'll be used much). \n \n
              \n
              type_factories
              \n \n
              \noptional. list of type specification factories. These guys are what convert \nPython data types to C/C++ data types. If you'd like to use a different set of \ntype conversions than the default, specify them here. Look in the type \nconversions section of the main documentation for examples.\n
              \n
              auto_downcast
              \n \n
              \noptional. 0 or 1. default 1. This only affects functions that have Numeric \narrays as input variables. Setting this to 1 will cause all floating point \nvalues to be cast as float instead of double if all the Numeric arrays are of \ntype float. If even one of the arrays has type double or double complex, all \nvariables maintain there standard types.\n
              \n
              \n
              \n\n

              Distutils keywords:

              \n
              \ninline() also accepts a number of distutils keywords \nfor controlling how the code is compiled. The following descriptions have been \ncopied from Greg Ward's distutils.extension.Extension class doc-\nstrings for convenience:\n\n
              \n
              sources
              \n \n
              \n[string] list of source filenames, relative to the \n distribution root (where the setup script lives), in Unix form \n (slash-separated) for portability. Source files may be C, C++, SWIG (.i), \n platform-specific resource files, or whatever else is recognized by the \n \"build_ext\" command as source for a Python extension. Note: The module_path \n file is always appended to the front of this list \n
              \n\n
              include_dirs
              \n \n
              \n[string] list of directories to search for C/C++ \n header files (in Unix form for portability) \n
              \n\n
              define_macros
              \n \n
              \n[(name : string, value : string|None)] list of \n macros to define; each macro is defined using a 2-tuple, where 'value' is \n either the string to define it to or None to define it without a particular \n value (equivalent of \"#define FOO\" in source or -DFOO on Unix C compiler \n command line) \n
              \n
              undef_macros
              \n \n
              \n[string] list of macros to undefine explicitly \n
              \n
              library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at link time \n
              \n
              libraries
              \n
              \n[string] list of library names (not filenames or paths) to link against \n
              \n
              runtime_library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at run time (for \nshared extensions, this is when the extension is loaded) \n
              \n\n
              extra_objects
              \n \n
              \n[string] list of extra files to link with (eg. \n object files not implied by 'sources', static library that must be \n explicitly specified, binary resource files, etc.) \n
              \n\n
              extra_compile_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when compiling the source files in 'sources'. For \n platforms and compilers where \"command line\" makes sense, this is typically \n a list of command-line arguments, but for other platforms it could be \n anything. \n
              \n
              extra_link_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when linking object files together to create the \n extension (or to create a new static Python interpreter). Similar \n interpretation as for 'extra_compile_args'. \n
              \n
              export_symbols
              \n \n
              \n[string] list of symbols to be exported from a shared extension. Not used on \nall platforms, and not generally necessary for Python extensions, which \ntypically export exactly one symbol: \"init\" + extension_name. \n
              \n
              \n
              \n\n\n

              Keyword Option Examples

              \nWe'll walk through several examples here to demonstrate the behavior of \ninline and also how the various arguments are used.\n\nIn the simplest (most) cases, code and arg_names\nare the only arguments that need to be specified. Here's a simple example\nrun on Windows machine that has Microsoft VC++ installed.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'string'\n    >>> code = \"\"\"\n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));\n    ...        \"\"\"\n    >>> inline(code,['a'])\n     sc_86e98826b65b047ffd2cd5f479c627f12.cpp\n    Creating\n       library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f12.lib\n    and object C:\\DOCUME~ 1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ff\n    d2cd5f479c627f12.exp\n    6\n    >>> inline(code,['a'])\n    6\n
              \n \nWhen inline is first run, you'll notice that pause and some \ntrash printed to the screen. The \"trash\" is acutually part of the compilers\noutput that distutils does not supress. The name of the extension file, \nsc_bighonkingnumber.cpp, is generated from the md5 check sum\nof the C/C++ code fragment. On Unix or windows machines with only\ngcc installed, the trash will not appear. On the second call, the code \nfragment is not compiled since it already exists, and only the answer is \nreturned. Now kill the interpreter and restart, and run the same code with\na different string.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'a longer string' \n    >>> code = \"\"\" \n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));  \n    ...        \"\"\"\n    >>> inline(code,['a'])\n    15\n
              \n

              \nNotice this time, inline() did not recompile the code because it\nfound the compiled function in the persistent catalog of functions. There is\na short pause as it looks up and loads the function, but it is much shorter \nthan compiling would require.\n

              \nYou can specify the local and global dictionaries if you'd like (much like \nexec or eval() in Python), but if they aren't \nspecified, the \"expected\" ones are used -- i.e. the ones from the function that \ncalled inline() . This is accomplished through a little call \nframe trickery. Here is an example where the local_dict is specified using\nthe same code example from above:\n\n 

              \n    >>> a = 'a longer string'\n    >>> b = 'an even  longer string' \n    >>> my_dict = {'a':b}\n    >>> inline(code,['a'])\n    15\n    >>> inline(code,['a'],my_dict)\n    21\n
              \n \n

              \nEverytime, the code is changed, inline does a \nrecompile. However, changing any of the other options in inline does not\nforce a recompile. The force option was added so that one\ncould force a recompile when tinkering with other variables. In practice,\nit is just as easy to change the code by a single character\n(like adding a space some place) to force the recompile. Note: It also \nmight be nice to add some methods for purging the cache and on disk \ncatalogs.\n

              \nI use verbose sometimes for debugging. When set to 2, it'll \noutput all the information (including the name of the .cpp file) that you'd\nexpect from running a make file. This is nice if you need to examine the\ngenerated code to see where things are going haywire. Note that error\nmessages from failed compiles are printed to the screen even if verbose\n is set to 0.\n

              \nThe following example demonstrates using gcc instead of the standard msvc \ncompiler on windows using same code fragment as above. Because the example has \nalready been compiled, the force=1 flag is needed to make \ninline() ignore the previously compiled version and recompile \nusing gcc. The verbose flag is added to show what is printed out:\n\n 

              \n    >>>inline(code,['a'],compiler='gcc',verbose=2,force=1)\n    running build_ext    \n    building 'sc_86e98826b65b047ffd2cd5f479c627f13' extension \n    c:\\gcc-2.95.2\\bin\\g++.exe -mno-cygwin -mdll -O2 -w -Wstrict-prototypes -IC:\n    \\home\\ej\\wrk\\scipy\\weave -IC:\\Python21\\Include -c C:\\DOCUME~1\\eric\\LOCAL\n    S~1\\Temp\\python21_compiled\\sc_86e98826b65b047ffd2cd5f479c627f13.cpp -o C:\\D\n    OCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b04\n    7ffd2cd5f479c627f13.o    \n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxextensions.c (C:\\DOCUME~1\\eri\n    c\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxextensions.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxsupport.cxx (C:\\DOCUME~1\\eric\n    \\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxsupport.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\IndirectPythonInterface.cxx (C:\\\n    DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\indirectpythonin\n    terface.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxx_extensions.cxx (C:\\DOCUME~1\\\n    eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxx_extensions.o up-to-da\n    te)\n    writing C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86\n    e98826b65b047ffd2cd5f479c627f13.def\n    c:\\gcc-2.95.2\\bin\\dllwrap.exe --driver-name g++ -mno-cygwin -mdll -static -\n    -output-lib C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\l\n    ibsc_86e98826b65b047ffd2cd5f479c627f13.a --def C:\\DOCUME~1\\eric\\LOCALS~1\\Te\n    mp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f13.def \n    -s C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e9882\n    6b65b047ffd2cd5f479c627f13.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compil\n    ed\\temp\\Release\\cxxextensions.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\cxxsupport.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\indirectpythoninterface.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\n    \\python21_compiled\\temp\\Release\\cxx_extensions.o -LC:\\Python21\\libs -lpytho\n    n21 -o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\sc_86e98826b65b047f\n    fd2cd5f479c627f13.pyd\n    15\n
              \n\nThat's quite a bit of output. verbose=1 just prints the compile\ntime.\n\n 
              \n    >>>inline(code,['a'],compiler='gcc',verbose=1,force=1)\n    Compiling code...\n    finished compiling (sec):  6.00800001621\n    15\n
              \n\n

              \n Note: I've only used the compiler option for switching between 'msvc'\nand 'gcc' on windows. It may have use on Unix also, but I don't know yet.\n\n\n

              \nThe support_code argument is likely to be used a lot. It allows \nyou to specify extra code fragments such as function, structure or class \ndefinitions that you want to use in the code string. Note that \nchanges to support_code do not force a recompile. The \ncatalog only relies on code (for performance reasons) to determine \nwhether recompiling is necessary. So, if you make a change to support_code, \nyou'll need to alter code in some way or use the \nforce argument to get the code to recompile. I usually just add \nsome inocuous whitespace to the end of one of the lines in code \nsomewhere. Here's an example of defining a separate method for calculating\nthe string length:\n\n 

              \n    >>> from weave import inline\n    >>> a = 'a longer string'\n    >>> support_code = \"\"\"\n    ...                PyObject* length(Py::String a)\n    ...                {\n    ...                    int l = a.length();  \n    ...                    return Py::new_reference_to(Py::Int(l)); \n    ...                }\n    ...                \"\"\"        \n    >>> inline(\"return_val = length(a);\",['a'],\n    ...        support_code = support_code)\n    15\n
              \n

              \ncustomize is a left over from a previous way of specifying \ncompiler options. It is a custom_info object that can specify \nquite a bit of information about how a file is compiled. These \ninfo objects are the standard way of defining compile information \nfor type conversion classes. However, I don't think they are as handy here, \nespecially since we've exposed all the keyword arguments that distutils can \nhandle. Between these keywords, and the support_code option, I \nthink customize may be obsolete. We'll see if anyone cares to use \nit. If not, it'll get axed in the next version.\n

              \nThe type_factories variable is important to people who want to\ncustomize the way arguments are converted from Python to C. We'll talk about\nthis in the next chapter **xx** of this document when we discuss type\nconversions.\n

              \nauto_downcast handles one of the big type conversion issues that\nis common when using Numeric arrays in conjunction with Python scalar values.\nIf you have an array of single precision values and multiply that array by a \nPython scalar, the result is upcast to a double precision array because the\nscalar value is double precision. This is not usually the desired behavior\nbecause it can double your memory usage. auto_downcast goes\nsome distance towards changing the casting precedence of arrays and scalars.\nIf your only using single precision arrays, it will automatically downcast all\nscalar values from double to single precision when they are passed into the\nC++ code. This is the default behavior. If you want all values to keep there\ndefault type, set auto_downcast to 0.\n

              \n\n\n\n

              Returning Values

              \n\nPython variables in the local and global scope transfer seemlessly from Python \ninto the C++ snippets. And, if inline were to completely live up\nto its name, any modifications to variables in the C++ code would be reflected\nin the Python variables when control was passed back to Python. For example,\nthe desired behavior would be something like:\n\n 
              \n    # THIS DOES NOT WORK\n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    2\n
              \n\nInstead you get:\n\n 
              \n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    1\n
              \n \nVariables are passed into C++ as if you are calling a Python function. Python's \ncalling convention is sometimes called \"pass by assignment\". This means its as \nif a c_a = a assignment is made right before inline \ncall is made and the c_a variable is used within the C++ code. \nThus, any changes made to c_a are not reflected in Python's \na variable. Things do get a little more confusing, however, when \nlooking at variables with mutable types. Changes made in C++ to the contents \nof mutable types are reflected in the Python variables.\n\n 
              \n    >>> a= [1,2]\n    >>> weave.inline(\"PyList_SetItem(a.ptr(),0,PyInt_FromLong(3));\",['a'])\n    >>> print a\n    [3, 2]\n
              \n\nSo modifications to the contents of mutable types in C++ are seen when control\nis returned to Python. Modifications to immutable types such as tuples,\nstrings, and numbers do not alter the Python variables.\n\nIf you need to make changes to an immutable variable, you'll need to assign\nthe new value to the \"magic\" variable return_val in C++. This\nvalue is returned by the inline() function:\n\n 
              \n    >>> a = 1\n    >>> a = weave.inline(\"return_val = Py::new_reference_to(Py::Int(a+1));\",['a'])  \n    >>> a\n    2\n
              \n\nThe return_val variable can also be used to return newly created \nvalues. This is possible by returning a tuple. The following trivial example \nillustrates how this can be done:\n\n 
                     \n    # python version\n    def multi_return():\n        return 1, '2nd'\n    \n    # C version.\n    def c_multi_return():    \n        code =  \"\"\"\n     \t        Py::Tuple results(2);\n     \t        results[0] = Py::Int(1);\n     \t        results[1] = Py::String(\"2nd\");\n     \t        return_val = Py::new_reference_to(results); \t        \n                \"\"\"\n        return inline_tools.inline(code)\n
              \n

              \nThe example is available in examples/tuple_return.py. It also\nhas the dubious honor of demonstrating how much inline() can \nslow things down. The C version here is about 10 times slower than the Python\nversion. Of course, something so trivial has no reason to be written in\nC anyway.\n\n\n

              The issue with locals()

              \n

              \ninline passes the locals() and globals() \ndictionaries from Python into the C++ function from the calling function. It \nextracts the variables that are used in the C++ code from these dictionaries, \nconverts then to C++ variables, and then calculates using them. It seems like \nit would be trivial, then, after the calculations were finished to then insert \nthe new values back into the locals() and globals() \ndictionaries so that the modified values were reflected in Python. \nUnfortunately, as pointed out by the Python manual, the locals() dictionary is \nnot writable. \n

              \n\nI suspect locals() is not writable because there are some \noptimizations done to speed lookups of the local namespace. I'm guessing local \nlookups don't always look at a dictionary to find values. Can someone \"in the \nknow\" confirm or correct this? Another thing I'd like to know is whether there \nis a way to write to the local namespace of another stack frame from C/C++. If \nso, it would be possible to have some clean up code in compiled functions that \nwrote final values of variables in C++ back to the correct Python stack frame. \nI think this goes a long way toward making inline truely live up \nto its name. I don't think we'll get to the point of creating variables in \nPython for variables created in C -- although I suppose with a C/C++ parser you \ncould do that also.\n\n

              \n\n\n

              A quick look at the code

              \n\nweave generates a C++ file holding an extension function for \neach inline code snippet. These file names are generated using \nfrom the md5 signature of the code snippet and saved to a location specified by \nthe PYTHONCOMPILED environment variable (discussed later). The cpp files are \ngenerally about 200-400 lines long and include quite a few functions to support \ntype conversions, etc. However, the actual compiled function is pretty simple. \nBelow is the familiar printf example:\n\n 
              \n    >>> import weave    \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n\nAnd here is the extension function generated by inline:\n\n 
              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        // The Py_None needs an incref before returning\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n        \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try                              \n        {                                \n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n            /* Here is the inline code */            \n            printf(\"%d\\n\",a);\n            /* I would like to fill in changed locals and globals here... */\n        }                                       \n        catch( Py::Exception& e)           \n        {                                \n            return_val =  Py::Null();    \n            exception_occured = 1;       \n        }                                 \n        if(!return_val && !exception_occured)\n        {\n                                      \n            Py_INCREF(Py_None);              \n            return_val = Py_None;            \n        }\n        /* clean up code */\n        \n        /* return */                              \n        return return_val;           \n    }                                \n
              \n\nEvery inline function takes exactly two arguments -- the local and global\ndictionaries for the current scope. All variable values are looked up out\nof these dictionaries. The lookups, along with all inline code \nexecution, are done within a C++ try block. If the variables\naren't found, or there is an error converting a Python variable to the \nappropriate type in C++, an exception is raised. The C++ exception\nis automatically converted to a Python exception by CXX and returned to Python.\n\nThe py_to_int() function illustrates how the conversions and\nexception handling works. py_to_int first checks that the given PyObject*\npointer is not NULL and is a Python integer. If all is well, it calls the\nPython API to convert the value to an int. Otherwise, it calls\nhandle_bad_type() which gathers information about what went wrong\nand then raises a CXX TypeError which returns to Python as a TypeError.\n\n 
              \n    int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\n 
              \n    void handle_bad_type(PyObject* py_obj, char* good_type, char*  var_name)\n    {\n        char msg[500];\n        sprintf(msg,\"received '%s' type instead of '%s' for variable '%s'\",\n                find_type(py_obj),good_type,var_name);\n        throw Py::TypeError(msg);\n    }\n    \n    char* find_type(PyObject* py_obj)\n    {\n        if(py_obj == NULL) return \"C NULL value\";\n        if(PyCallable_Check(py_obj)) return \"callable\";\n        if(PyString_Check(py_obj)) return \"string\";\n        if(PyInt_Check(py_obj)) return \"int\";\n        if(PyFloat_Check(py_obj)) return \"float\";\n        if(PyDict_Check(py_obj)) return \"dict\";\n        if(PyList_Check(py_obj)) return \"list\";\n        if(PyTuple_Check(py_obj)) return \"tuple\";\n        if(PyFile_Check(py_obj)) return \"file\";\n        if(PyModule_Check(py_obj)) return \"module\";\n        \n        //should probably do more interagation (and thinking) on these.\n        if(PyCallable_Check(py_obj) && PyInstance_Check(py_obj)) return \"callable\";\n        if(PyInstance_Check(py_obj)) return \"instance\"; \n        if(PyCallable_Check(py_obj)) return \"callable\";\n        return \"unkown type\";\n    }\n
              \n\nSince the inline is also executed within the try/catch\nblock, you can use CXX exceptions within your code. It is usually a bad idea\nto directly return from your code, even if an error occurs. This\nskips the clean up section of the extension function. In this simple example,\nthere isn't any clean up code, but in more complicated examples, there may\nbe some reference counting that needs to be taken care of here on converted\nvariables. To avoid this, either uses exceptions or set \nreturn_val to NULL and use if/then's to skip code\nafter errors.\n\n\n

              Technical Details

              \n

              \nThere are several main steps to using C/C++ code withing Python:\n

                \n
              1. Type conversion \n
              2. Generating C/C++ code \n
              3. Compile the code to an extension module \n
              4. Catalog (and cache) the function for future use
                5. \n
              \n

              \nItems 1 and 2 above are related, but most easily discussed separately. Type \nconversions are customizable by the user if needed. Understanding them is \npretty important for anything beyond trivial uses of inline. \nGenerating the C/C++ code is handled by ext_function and \next_module classes and . For the most part, compiling the code is \nhandled by distutils. Some customizations were needed, but they were \nrelatively minor and do not require changes to distutils itself. Cataloging is \npretty simple in concept, but surprisingly required the most code to implement \n(and still likely needs some work). So, this section covers items 1 and 4 from \nthe list. Item 2 is covered later in the chapter covering the \next_tools module, and distutils is covered by a completely \nseparate document xxx.\n\n

              Passing Variables in/out of the C/C++ code

              \n\nNote: Passing variables into the C code is pretty straight forward, but there \nare subtlties to how variable modifications in C are returned to Python. see Returning Values for a more thorough discussion of \nthis issue.\n \n \n\n

              Type Conversions

              \n\n\nNote: Maybe xxx_converter instead of \nxxx_specification is a more descriptive name. Might change in \nfuture version?\n\n\n

              \nBy default, inline() makes the following type conversions between\nPython and C++ types.\n

              \n\n

              \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
              \n

              Default Data Type Conversions

              \n

              Python

              		\n

              C++

                 int   int
                 float   double
                 complex   std::complex
                 string   Py::String
                 list   Py::List
                 dict   Py::Dict
                 tuple   Py::Tuple
                 file   FILE*
                 callable   PyObject*
                 instance   PyObject*
                 Numeric.array   PyArrayObject*
                 wxXXX   wxXXX*
              \n
              \n

              \nThe Py:: namespace is defined by the \nCXX library which has C++ class\nequivalents for many Python types. std:: is the namespace of the\nstandard library in C++.\n

              \n\nNote: \n

                \n
              • I haven't figured out how to handle long int yet (I think they are currenlty converted \n to int - - check this). \n \n
              • \nHopefully VTK will be added to the list soon
                • \n
              \n\n

              \n\nPython to C++ conversions fill in code in several locations in the generated\ninline extension function. Below is the basic template for the\nfunction. This is actually the exact code that is generated by calling\nweave.inline(\"\").\n\n 

              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n    \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try\n        {\n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            /* argument conversion code */\n            /* inline code */\n            /*I would like to fill in changed locals and globals here...*/\n    \n        }\n        catch( Py::Exception& e)\n        {\n            return_val =  Py::Null();\n            exception_occured = 1;\n        }\n        /* cleanup code */\n        if(!return_val && !exception_occured)\n        {\n    \n            Py_INCREF(Py_None);\n            return_val = Py_None;\n        }\n    \n        return return_val;\n    }\n
              \n\nThe /* inline code */ section is filled with the code passed to\nthe inline() function call. The \n/*argument convserion code*/ and /* cleanup code */\nsections are filled with code that handles conversion from Python to C++\ntypes and code that deallocates memory or manipulates reference counts before\nthe function returns. The following sections demostrate how these two areas\nare filled in by the default conversion methods.\n\n \nNote: I'm not sure I have reference counting correct on a few of these. The \nonly thing I increase/decrease the ref count on is Numeric arrays. If you\nsee an issue, please let me know.\n\n\n\n

              Numeric Argument Conversion

              \n\nInteger, floating point, and complex arguments are handled in a very similar\nfashion. Consider the following inline function that has a single integer \nvariable passed in:\n\n 
              \n    >>> a = 1\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_int() has the following\nform:\n\n 
              \n    static int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\nSimilarly, the float and complex conversion routines look like:\n\n 
                  \n    static double py_to_float(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyFloat_Check(py_obj))\n            handle_bad_type(py_obj,\"float\", name);\n        return PyFloat_AsDouble(py_obj);\n    }\n    \n    static std::complex py_to_complex(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyComplex_Check(py_obj))\n            handle_bad_type(py_obj,\"complex\", name);\n        return std::complex(PyComplex_RealAsDouble(py_obj),\n                                    PyComplex_ImagAsDouble(py_obj));    \n    }\n
              \n\nNumeric conversions do not require any clean up code.\n\n\n

              String, List, Tuple, and Dictionary Conversion

              \n\nStrings, Lists, Tuples and Dictionary conversions are all converted to \nCXX types by default.\n\nFor the following code, \n\n 
              \n    >>> a = [1]\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    Py::List a = py_to_list (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_list() and its\nfriends has the following form:\n\n 
                  \n    static Py::List py_to_list(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyList_Check(py_obj))\n            handle_bad_type(py_obj,\"list\", name);\n        return Py::List(py_obj);\n    }\n    \n    static Py::String py_to_string(PyObject* py_obj,char* name)\n    {\n        if (!PyString_Check(py_obj))\n            handle_bad_type(py_obj,\"string\", name);\n        return Py::String(py_obj);\n    }\n\n    static Py::Dict py_to_dict(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyDict_Check(py_obj))\n            handle_bad_type(py_obj,\"dict\", name);\n        return Py::Dict(py_obj);\n    }\n    \n    static Py::Tuple py_to_tuple(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyTuple_Check(py_obj))\n            handle_bad_type(py_obj,\"tuple\", name);\n        return Py::Tuple(py_obj);\n    }\n
              \n\nCXX handles reference counts on for strings, lists, tuples, and dictionaries,\nso clean up code isn't necessary.\n\n\n

              File Conversion

              \n\nFor the following code, \n\n 
              \n    >>> a = open(\"bob\",'w')  \n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code is:\n\n 
              \n    /* argument conversion code */\n    PyObject* py_a = get_variable(\"a\",raw_locals,raw_globals);\n    FILE* a = py_to_file(py_a,\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_file() converts\nPyObject* to a FILE* and increments the reference count of the PyObject*:\n\n 
              \n    FILE* py_to_file(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"file\", name);\n    \n        Py_INCREF(py_obj);\n        return PyFile_AsFile(py_obj);\n    }\n
              \n\nBecause the PyObject* was incremented, the clean up code needs to decrement\nthe counter\n\n 
              \n    /* cleanup code */\n    Py_XDECREF(py_a);\n
              \n\nIts important to understand that file conversion only works on actual files --\ni.e. ones created using the open() command in Python. It does\nnot support converting arbitrary objects that support the file interface into\nC FILE* pointers. This can affect many things. For example, in\ninitial printf() examples, one might be tempted to solve the \nproblem of C and Python IDE's (PythonWin, PyCrust, etc.) writing to different\nstdout and stderr by using fprintf() and passing in \nsys.stdout and sys.stderr. For example, instead of\n\n 
              \n    >>> weave.inline('printf(\"hello\\\\n\");')\n
              \n \nYou might try:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n
              \n\nThis will work as expected from a standard python interpreter, but in PythonWin,\nthe following occurs:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n    Traceback (most recent call last):\n        File \"\", line 1, in ?\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 315, in inline\n            auto_downcast = auto_downcast,\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 386, in compile_function\n            type_factories = type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 197, in __init__\n            auto_downcast, type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 390, in assign_variable_types\n            raise TypeError, format_error_msg(errors)\n        TypeError: {'buf': \"Unable to convert variable 'buf' to a C++ type.\"}\n
              \n\nThe traceback tells us that inline() was unable to convert 'buf' to a\nC++ type (If instance conversion was implemented, the error would have occurred at \nruntime instead). Why is this? Let's look at what the buf object \nreally is:\n\n 
              \n    >>> buf\n    pywin.framework.interact.InteractiveView instance at 00EAD014\n
              \n\nPythonWin has reassigned sys.stdout to a special object that \nimplements the Python file interface. This works great in Python, but since \nthe special object doesn't have a FILE* pointer underlying it, fprintf doesn't \nknow what to do with it (well this will be the problem when instance conversion \nis implemented...).\n\n\n

              Callable, Instance, and Module Conversion

              \n\nNote: Need to look into how ref counts should be handled. Also,\nInstance and Module conversion are not currently implemented.\n\n\n 
              \n    >>> def a(): \n        pass\n    >>> inline(\"\",['a'])\n
              \n\nCallable and instance variables are converted to PyObject*. Nothing is done\nto there reference counts.\n\n 
              \n    /* argument conversion code */\n    PyObject* a = py_to_callable(get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. The py_to_callable() and\npy_to_instance() don't currently increment the ref count.\n\n 
                  \n    PyObject* py_to_callable(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyCallable_Check(py_obj))\n            handle_bad_type(py_obj,\"callable\", name);    \n        return py_obj;\n    }\n\n    PyObject* py_to_instance(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"instance\", name);    \n        return py_obj;\n    }\n
              \n \nThere is no cleanup code for callables, modules, or instances.\n\n\n

              Customizing Conversions

              \n

              \nConverting from Python to C++ types is handled by xxx_specification classes. A \ntype specification class actually serve in two related but different \nroles. The first is in determining whether a Python variable that needs to be \nconverted should be represented by the given class. The second is as a code \ngenerator that generate C++ code needed to convert from Python to C++ types for \na specific variable.\n

              \nWhen \n\n 

              \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\",a);',['a'])\n
              \n \nis called for the first time, the code snippet has to be compiled. In this \nprocess, the variable 'a' is tested against a list of type specifications (the \ndefault list is stored in weave/ext_tools.py). The first \nspecification in the list is used to represent the variable. \n\n

              \nExamples of xxx_specification are scattered throughout numerous \n\"xxx_spec.py\" files in the weave package. Closely related to \nthe xxx_specification classes are yyy_info classes. \nThese classes contain compiler, header, and support code information necessary \nfor including a certain set of capabilities (such as blitz++ or CXX support)\nin a compiled module. xxx_specification classes have one or more\nyyy_info classes associated with them.\n\nIf you'd like to define your own set of type specifications, the current best route\nis to examine some of the existing spec and info files. Maybe looking over\nsequence_spec.py and cxx_info.py are a good place to start. After defining \nspecification classes, you'll need to pass them into inline using the \ntype_factories argument. \n\nA lot of times you may just want to change how a specific variable type is \nrepresented. Say you'd rather have Python strings converted to \nstd::string or maybe char* instead of using the CXX \nstring object, but would like all other type conversions to have default \nbehavior. This requires that a new specification class that handles strings\nis written and then prepended to a list of the default type specifications. Since\nit is closer to the front of the list, it effectively overrides the default\nstring specification.\n\nThe following code demonstrates how this is done:\n\n...\n\n\n

              The Catalog

              \n

              \ncatalog.py has a class called catalog that helps keep \ntrack of previously compiled functions. This prevents inline() \nand related functions from having to compile functions everytime they are \ncalled. Instead, catalog will check an in memory cache to see if the function \nhas already been loaded into python. If it hasn't, then it starts searching \nthrough persisent catalogs on disk to see if it finds an entry for the given \nfunction. By saving information about compiled functions to disk, it isn't\nnecessary to re-compile functions everytime you stop and restart the interpreter.\nFunctions are compiled once and stored for future use.\n\n

              \nWhen inline(cpp_code) is called the following things happen:\n

                \n
              1. \n A fast local cache of functions is checked for the last function called for \n cpp_code. If an entry for cpp_code doesn't exist in the \n cache or the cached function call fails (perhaps because the function doesn't \n have compatible types) then the next step is to check the catalog. \n
              2. \n The catalog class also keeps an in-memory cache with a list of all the \n functions compiled for cpp_code. If cpp_code has\n ever been called, then this cache will be present (loaded from disk). If\n the cache isn't present, then it is loaded from disk.\n

                \n If the cache is present, each function in the cache is \n called until one is found that was compiled for the correct argument types. If \n none of the functions work, a new function is compiled with the given argument \n types. This function is written to the on-disk catalog as well as into the \n in-memory cache.

                \n
              3. \n When a lookup for cpp_code fails, the catalog looks through \n the on-disk function catalogs for the entries. The PYTHONCOMPILED variable \n determines where to search for these catalogs and in what order. If \n PYTHONCOMPILED is not present several platform dependent locations are \n searched. All functions found for cpp_code in the path are \n loaded into the in-memory cache with functions found earlier in the search \n path closer to the front of the call list.\n

                \n If the function isn't found in the on-disk catalog, \n then the function is compiled, written to the first writable directory in the \n PYTHONCOMPILED path, and also loaded into the in-memory cache.

                \n
                4. \n
              \n\n\n

              Function Storage: How functions are stored in caches and on disk

              \n

              \nFunction caches are stored as dictionaries where the key is the entire C++\ncode string and the value is either a single function (as in the \"level 1\"\ncache) or a list of functions (as in the main catalog cache). On disk\ncatalogs are stored in the same manor using standard Python shelves.\n

              \nEarly on, there was a question as to whether md5 check sums of the C++\ncode strings should be used instead of the actual code strings. I think this\nis the route inline Perl took. Some (admittedly quick) tests of the md5 vs.\nthe entire string showed that using the entire string was at least a\nfactor of 3 or 4 faster for Python. I think this is because it is more\ntime consuming to compute the md5 value than it is to do look-ups of long\nstrings in the dictionary. Look at the examples/md5_speed.py file for the\ntest run. \n\n\n

              Catalog search paths and the PYTHONCOMPILED variable

              \n

              \nThe default location for catalog files on Unix is is ~/.pythonXX_compiled where \nXX is version of Python being used. If this directory doesn't exist, it is \ncreated the first time a catalog is used. The directory must be writable. If, \nfor any reason it isn't, then the catalog attempts to create a directory based \non your user id in the /tmp directory. The directory permissions are set so \nthat only you have access to the directory. If this fails, I think you're out of \nluck. I don't think either of these should ever fail though. On Windows, a \ndirectory called pythonXX_compiled is created in the user's temporary \ndirectory. \n

              \nThe actual catalog file that lives in this directory is a Python shelve with\na platform specific name such as \"nt21compiled_catalog\" so that multiple OSes\ncan share the same file systems without trampling on each other. Along with\nthe catalog file, the .cpp and .so or .pyd files created by inline will live\nin this directory. The catalog file simply contains keys which are the C++\ncode strings with values that are lists of functions. The function lists point\nat functions within these compiled modules. Each function in the lists \nexecutes the same C++ code string, but compiled for different input variables.\n

              \nYou can use the PYTHONCOMPILED environment variable to specify alternative\nlocations for compiled functions. On Unix this is a colon (':') separated\nlist of directories. On windows, it is a (';') separated list of directories.\nThese directories will be searched prior to the default directory for a\ncompiled function catalog. Also, the first writable directory in the list\nis where all new compiled function catalogs, .cpp and .so or .pyd files are\nwritten. Relative directory paths ('.' and '..') should work fine in the\nPYTHONCOMPILED variable as should environement variables.\n

              \nThere is a \"special\" path variable called MODULE that can be placed in the \nPYTHONCOMPILED variable. It specifies that the compiled catalog should\nreside in the same directory as the module that called it. This is useful\nif an admin wants to build a lot of compiled functions during the build\nof a package and then install them in site-packages along with the package.\nUser's who specify MODULE in their PYTHONCOMPILED variable will have access\nto these compiled functions. Note, however, that if they call the function\nwith a set of argument types that it hasn't previously been built for, the\nnew function will be stored in their default directory (or some other writable\ndirectory in the PYTHONCOMPILED path) because the user will not have write\naccess to the site-packages directory.\n

              \nAn example of using the PYTHONCOMPILED path on bash follows:\n\n 

              \n    PYTHONCOMPILED=MODULE:/some/path;export PYTHONCOMPILED;\n
              \n\nIf you are using python21 on linux, and the module bob.py in site-packages\nhas a compiled function in it, then the catalog search order when calling that\nfunction for the first time in a python session would be:\n\n 
              \n    /usr/lib/python21/site-packages/linuxpython_compiled\n    /some/path/linuxpython_compiled\n    ~/.python21_compiled/linuxpython_compiled\n
              \n\nThe default location is always included in the search path.\n

              \n \nNote: hmmm. see a possible problem here. I should probably make a sub-\ndirectory such as /usr/lib/python21/site-\npackages/python21_compiled/linuxpython_compiled so that library files compiled \nwith python21 are tried to link with python22 files in some strange scenarios. \nNeed to check this.\n\n\n

              \nThe in-module cache (in weave.inline_tools reduces the overhead \nof calling inline functions by about a factor of 2. It can be reduced a little \nmore for type loop calls where the same function is called over and over again \nif the cache was a single value instead of a dictionary, but the benefit is \nvery small (less than 5%) and the utility is quite a bit less. So, we'll stick \nwith a dictionary as the cache.\n

              \n\n\n

              Blitz

              \n Note: most of this section is lifted from old documentation. It should be\npretty accurate, but there may be a few discrepancies.\n

              \nweave.blitz() compiles Numeric Python expressions for fast \nexecution. For most applications, compiled expressions should provide a \nfactor of 2-10 speed-up over Numeric arrays. Using compiled \nexpressions is meant to be as unobtrusive as possible and works much like \npythons exec statement. As an example, the following code fragment takes a 5 \npoint average of the 512x512 2d image, b, and stores it in array, a:\n\n 

              \n    from scipy import *  # or from Numeric import *\n    a = ones((512,512), Float64) \n    b = ones((512,512), Float64) \n    # ...do some stuff to fill in b...\n    # now average\n    a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] \\\n                   + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n
              \n \nTo compile the expression, convert the expression to a string by putting\nquotes around it and then use weave.blitz:\n\n 
              \n    import weave\n    expr = \"a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n                          \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n    weave.blitz(expr)\n
              \n\nThe first time weave.blitz is run for a given expression and \nset of arguements, C++ code that accomplishes the exact same task as the Python \nexpression is generated and compiled to an extension module. This can take up \nto a couple of minutes depending on the complexity of the function. Subsequent \ncalls to the function are very fast. Futher, the generated module is saved \nbetween program executions so that the compilation is only done once for a \ngiven expression and associated set of array types. If the given expression\nis executed with a new set of array types, the code most be compiled again. This\ndoes not overwrite the previously compiled function -- both of them are saved and\navailable for exectution. \n

              \nThe following table compares the run times for standard Numeric code and \ncompiled code for the 5 point averaging.\n

              \n

              \n\n\n\n\n\n
              Method Run Time (seconds)
              Standard Numeric 0.46349
              blitz (1st time compiling) 78.95526
              blitz (subsequent calls) 0.05843 (factor of 8 speedup)
              \n
              \n

              \nThese numbers are for a 512x512 double precision image run on a 400 MHz Celeron \nprocessor under RedHat Linux 6.2.\n

              \nBecause of the slow compile times, its probably most effective to develop \nalgorithms as you usually do using the capabilities of scipy or the Numeric \nmodule. Once the algorithm is perfected, put quotes around it and execute it \nusing weave.blitz. This provides the standard rapid \nprototyping strengths of Python and results in algorithms that run close to \nthat of hand coded C or Fortran.\n\n\n

              Requirements

              \n\nCurrently, the weave.blitz has only been tested under Linux \nwith gcc-2.95-3 and on Windows with Mingw32 (2.95.2). Its compiler \nrequirements are pretty heavy duty (see the \nblitz++ home page), so it won't \nwork with just any compiler. Particularly MSVC++ isn't up to snuff. A number \nof other compilers such as KAI++ will also work, but my suspicions are that gcc \nwill get the most use.\n\n\n

              Limitations

              \n
                \n
              1. \nCurrently, weave.blitz handles all standard mathematic \noperators except for the ** power operator. The built-in trigonmetric, log, \nfloor/ceil, and fabs functions might work (but haven't been tested). It also \nhandles all types of array indexing supported by the Numeric module. \n

                \nweave.blitz does not currently support operations that use \narray broadcasting, nor have any of the special purpose functions in Numeric \nsuch as take, compress, etc. been implemented. Note that there are no obvious \nreasons why most of this functionality cannot be added to scipy.weave, so it \nwill likely trickle into future versions. Using slice() objects \ndirectly instead of start:stop:step is also not supported.\n

                2. \n
              2. \nCurrently Python only works on expressions that include assignment such as\n \n 
                \n    >>> result = b + c + d\n
                \n\nThis means that the result array must exist before calling \nweave.blitz. Future versions will allow the following:\n\n 
                \n    >>> result = weave.blitz_eval(\"b + c + d\")\n
                \n
                3. \n
              3. \nweave.blitz works best when algorithms can be expressed in a \n\"vectorized\" form. Algorithms that have a large number of if/thens and other \nconditions are better hand written in C or Fortran. Further, the restrictions \nimposed by requiring vectorized expressions sometimes preclude the use of more \nefficient data structures or algorithms. For maximum speed in these cases, \nhand-coded C or Fortran code is the only way to go.\n
                4. \n
              4. \nOne other point deserves mention lest people be confused. \nweave.blitz is not a general purpose Python->C compiler. It \nonly works for expressions that contain Numeric arrays and/or \nPython scalar values. This focused scope concentrates effort on the \ncompuationally intensive regions of the program and sidesteps the difficult \nissues associated with a general purpose Python->C compiler.\n
                5. \n
              \n\n\n

              Numeric efficiency issues: What compilation buys you

              \n\nSome might wonder why compiling Numeric expressions to C++ is beneficial since \noperations on Numeric array operations are already executed within C loops. \nThe problem is that anything other than the simplest expression are executed in \nless than optimal fashion. Consider the following Numeric expression:\n\n 
              \n    a = 1.2 * b + c * d\n
              \n \nWhen Numeric calculates the value for the 2d array, a, it does \nthe following steps:\n\n 
              \n    temp1 = 1.2 * b\n    temp2 = c * d\n    a = temp1 + temp2\n
              \n \nTwo things to note. Since c is an (perhaps large) array, a large \ntemporary array must be created to store the results of 1.2 * b. \nThe same is true for temp2. Allocation is slow. The second thing \nis that we have 3 loops executing, one to calculate temp1, one for \ntemp2 and one for adding them up. A C loop for the same problem \nmight look like:\n\n 
              \n    for(int i = 0; i < M; i++)\n        for(int j = 0; j < N; j++)\n            a[i,j] = 1.2 * b[i,j] + c[i,j] * d[i,j]\n
              \n \nHere, the 3 loops have been fused into a single loop and there is no longer\na need for a temporary array. This provides a significant speed improvement\nover the above example (write me and tell me what you get). \n

              \nSo, converting Numeric expressions into C/C++ loops that fuse the loops and \neliminate temporary arrays can provide big gains. The goal then,is to convert \nNumeric expression to C/C++ loops, compile them in an extension module, and \nthen call the compiled extension function. The good news is that there is an \nobvious correspondence between the Numeric expression above and the C loop. The \nbad news is that Numeric is generally much more powerful than this simple \nexample illustrates and handling all possible indexing possibilities results in \nloops that are less than straight forward to write. (take a peak in Numeric for \nconfirmation). Luckily, there are several available tools that simplify the \nprocess.\n\n\n

              The Tools

              \n\nweave.blitz relies heavily on several remarkable tools. On the \nPython side, the main facilitators are Jermey Hylton's parser module and Jim \nHuginin's Numeric module. On the compiled language side, Todd Veldhuizen's \nblitz++ array library, written in C++ (shhhh. don't tell David Beazley), does \nthe heavy lifting. Don't assume that, because it's C++, it's much slower than C \nor Fortran. Blitz++ uses a jaw dropping array of template techniques \n(metaprogramming, template expression, etc) to convert innocent looking and \nreadable C++ expressions into to code that usually executes within a few \npercentage points of Fortran code for the same problem. This is good. \nUnfortunately all the template raz-ma-taz is very expensive to compile, so the \n200 line extension modules often take 2 or more minutes to compile. This isn't so \ngood. weave.blitz works to minimize this issue by remembering \nwhere compiled modules live and reusing them instead of re-compiling every time \na program is re-run.\n\n\n

              Parser

              \nTearing Numeric expressions apart, examining the pieces, and then rebuilding \nthem as C++ (blitz) expressions requires a parser of some sort. I can imagine \nsomeone attacking this problem with regular expressions, but it'd likely be \nugly and fragile. Amazingly, Python solves this problem for us. It actually \nexposes its parsing engine to the world through the parser module. \nThe following fragment creates an Abstract Syntax Tree (AST) object for the \nexpression and then converts to a (rather unpleasant looking) deeply nested list \nrepresentation of the tree. \n \n 
              \n    >>> import parser\n    >>> import scipy.weave.misc\n    >>> ast = parser.suite(\"a = b * c + d\")\n    >>> ast_list = ast.tolist()\n    >>> sym_list = scipy.weave.misc.translate_symbols(ast_list)\n    >>> pprint.pprint(sym_list)\n    ['file_input',\n     ['stmt',\n      ['simple_stmt',\n       ['small_stmt',\n        ['expr_stmt',\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'a']]]]]]]]]]]]]]],\n         ['EQUAL', '='],\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'b']]]],\n                    ['STAR', '*'],\n                    ['factor', ['power', ['atom', ['NAME', 'c']]]]],\n                   ['PLUS', '+'],\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'd']]]]]]]]]]]]]]]]],\n       ['NEWLINE', '']]],\n     ['ENDMARKER', '']]\n
              \n\nDespite its looks, with some tools developed by Jermey H., its possible\nto search these trees for specific patterns (sub-trees), extract the \nsub-tree, manipulate them converting python specific code fragments\nto blitz code fragments, and then re-insert it in the parse tree. The parser\nmodule documentation has some details on how to do this. Traversing the \nnew blitzified tree, writing out the terminal symbols as you go, creates\nour new blitz++ expression string.\n\n \n

              Blitz and Numeric

              \nThe other nice discovery in the project is that the data structure used\nfor Numeric arrays and blitz arrays is nearly identical. Numeric stores\n\"strides\" as byte offsets and blitz stores them as element offsets, but\nother than that, they are the same. Further, most of the concept and\ncapabilities of the two libraries are remarkably similar. It is satisfying \nthat two completely different implementations solved the problem with \nsimilar basic architectures. It is also fortitous. The work involved in \nconverting Numeric expressions to blitz expressions was greatly diminished.\nAs an example, consider the code for slicing an array in Python with a\nstride:\n\n 
              \n    >>> a = b[0:4:2] + c\n    >>> a\n    [0,2,4]\n
              \n\n\nIn Blitz it is as follows:\n\n 
              \n    Array<2,int> b(10);\n    Array<2,int> c(3);\n    // ...\n    Array<2,int> a = b(Range(0,3,2)) + c;\n
              \n\n\nHere the range object works exactly like Python slice objects with the exception\nthat the top index (3) is inclusive where as Python's (4) is exclusive. Other \ndifferences include the type declaraions in C++ and parentheses instead of \nbrackets for indexing arrays. Currently, weave.blitz handles the \ninclusive/exclusive issue by subtracting one from upper indices during the\ntranslation. An alternative that is likely more robust/maintainable in the \nlong run, is to write a PyRange class that behaves like Python's range. \nThis is likely very easy.\n

              \nThe stock blitz also doesn't handle negative indices in ranges. The current \nimplementation of the blitz() has a partial solution to this \nproblem. It calculates and index that starts with a '-' sign by subtracting it \nfrom the maximum index in the array so that:\n\n 

              \n                    upper index limit\n                        /-----\\\n    b[:-1] -> b(Range(0,Nb[0]-1-1))\n
              \n\nThis approach fails, however, when the top index is calculated from other \nvalues. In the following scenario, if i+j evaluates to a negative \nvalue, the compiled code will produce incorrect results and could even core-\ndump. Right now, all calculated indices are assumed to be positive.\n \n 
              \n    b[:i-j] -> b(Range(0,i+j))\n
              \n\nA solution is to calculate all indices up front using if/then to handle the\n+/- cases. This is a little work and results in more code, so it hasn't been\ndone. I'm holding out to see if blitz++ can be modified to handle negative\nindexing, but haven't looked into how much effort is involved yet. While it \nneeds fixin', I don't think there is a ton of code where this is an issue.\n

              \nThe actual translation of the Python expressions to blitz expressions is \ncurrently a two part process. First, all x:y:z slicing expression are removed\nfrom the AST, converted to slice(x,y,z) and re-inserted into the tree. Any\nmath needed on these expressions (subtracting from the \nmaximum index, etc.) are also preformed here. _beg and _end are used as special\nvariables that are defined as blitz::fromBegin and blitz::toEnd.\n\n 

              \n    a[i+j:i+j+1,:] = b[2:3,:] \n
              \n\nbecomes a more verbose:\n \n 
              \n    a[slice(i+j,i+j+1),slice(_beg,_end)] = b[slice(2,3),slice(_beg,_end)]\n
              \n \nThe second part does a simple string search/replace to convert to a blitz \nexpression with the following translations:\n\n 
              \n    slice(_beg,_end) -> _all  # not strictly needed, but cuts down on code.\n    slice            -> blitz::Range\n    [                -> (\n    ]                -> )\n    _stp             -> 1\n
              \n\n_all is defined in the compiled function as \nblitz::Range.all(). These translations could of course happen \ndirectly in the syntax tree. But the string replacement is slightly easier. \nNote that name spaces are maintained in the C++ code to lessen the likelyhood \nof name clashes. Currently no effort is made to detect name clashes. A good \nrule of thumb is don't use values that start with '_' or 'py_' in compiled \nexpressions and you'll be fine.\n\n \n

              Type definitions and coersion

              \n\nSo far we've glossed over the dynamic vs. static typing issue between Python \nand C++. In Python, the type of value that a variable holds can change\nthrough the course of program execution. C/C++, on the other hand, forces you\nto declare the type of value a variables will hold prior at compile time.\nweave.blitz handles this issue by examining the types of the\nvariables in the expression being executed, and compiling a function for those\nexplicit types. For example:\n\n 
              \n    a = ones((5,5),Float32)\n    b = ones((5,5),Float32)\n    weave.blitz(\"a = a + b\")\n
              \n\nWhen compiling this expression to C++, weave.blitz sees that the\nvalues for a and b in the local scope have type Float32, or 'float'\non a 32 bit architecture. As a result, it compiles the function using \nthe float type (no attempt has been made to deal with 64 bit issues).\nIt also goes one step further. If all arrays have the same type, a templated\nversion of the function is made and instantiated for float, double, \ncomplex, and complex arrays. Note: This feature has been \nremoved from the current version of the code. Each version will be compiled\nseparately \n

              \nWhat happens if you call a compiled function with array types that are \ndifferent than the ones for which it was originally compiled? No biggie, you'll \njust have to wait on it to compile a new version for your new types. This \ndoesn't overwrite the old functions, as they are still accessible. See the \ncatalog section in the inline() documentation to see how this is handled. \nSuffice to say, the mechanism is transparent to the user and behaves \nlike dynamic typing with the occasional wait for compiling newly typed \nfunctions.\n

              \nWhen working with combined scalar/array operations, the type of the array is \nalways used. This is similar to the savespace flag that was recently \nadded to Numeric. This prevents issues with the following expression perhaps \nunexpectedly being calculated at a higher (more expensive) precision that can \noccur in Python:\n\n 

              \n    >>> a = array((1,2,3),typecode = Float32)\n    >>> b = a * 2.1 # results in b being a Float64 array.\n
              \n \nIn this example, \n\n 
              \n    >>> a = ones((5,5),Float32)\n    >>> b = ones((5,5),Float32)\n    >>> weave.blitz(\"b = a * 2.1\")\n
              \n \nthe 2.1 is cast down to a float before carrying out \nthe operation. If you really want to force the calculation to be a \ndouble, define a and b as \ndouble arrays.\n

              \nOne other point of note. Currently, you must include both the right hand side \nand left hand side (assignment side) of your equation in the compiled \nexpression. Also, the array being assigned to must be created prior to calling \nweave.blitz. I'm pretty sure this is easily changed so that a \ncompiled_eval expression can be defined, but no effort has been made to \nallocate new arrays (and decern their type) on the fly.\n\n \n

              Cataloging Compiled Functions

              \n\nSee the Cataloging functions section in the \nweave.inline() documentation.\n\n \n

              Checking Array Sizes

              \n\nSurprisingly, one of the big initial problems with compiled code was making\nsure all the arrays in an operation were of compatible type. The following\ncase is trivially easy:\n\n 
              \n    a = b + c\n
              \n \nIt only requires that arrays a, b, and c \nhave the same shape. However, expressions like:\n\n 
              \n    a[i+j:i+j+1,:] = b[2:3,:] + c\n
              \n\nare not so trivial. Since slicing is involved, the size of the slices, not the \ninput arrays must be checked. Broadcasting complicates things further because \narrays and slices with different dimensions and shapes may be compatible for \nmath operations (broadcasting isn't yet supported by \nweave.blitz). Reductions have a similar effect as their \nresults are different shapes than their input operand. The binary operators in \nNumeric compare the shapes of their two operands just before they operate on \nthem. This is possible because Numeric treats each operation independently. \nThe intermediate (temporary) arrays created during sub-operations in an \nexpression are tested for the correct shape before they are combined by another \noperation. Because weave.blitz fuses all operations into a \nsingle loop, this isn't possible. The shape comparisons must be done and \nguaranteed compatible before evaluating the expression.\n

              \nThe solution chosen converts input arrays to \"dummy arrays\" that only represent \nthe dimensions of the arrays, not the data. Binary operations on dummy arrays \ncheck that input array sizes are comptible and return a dummy array with the \nsize correct size. Evaluating an expression of dummy arrays traces the \nchanging array sizes through all operations and fails if incompatible array \nsizes are ever found. \n

              \nThe machinery for this is housed in weave.size_check. It \nbasically involves writing a new class (dummy array) and overloading it math \noperators to calculate the new sizes correctly. All the code is in Python and \nthere is a fair amount of logic (mainly to handle indexing and slicing) so the \noperation does impose some overhead. For large arrays (ie. 50x50x50), the \noverhead is negligible compared to evaluating the actual expression. For small \narrays (ie. 16x16), the overhead imposed for checking the shapes with this \nmethod can cause the weave.blitz to be slower than evaluating \nthe expression in Python. \n

              \nWhat can be done to reduce the overhead? (1) The size checking code could be \nmoved into C. This would likely remove most of the overhead penalty compared \nto Numeric (although there is also some calling overhead), but no effort has \nbeen made to do this. (2) You can also call weave.blitz with\ncheck_size=0 and the size checking isn't done. However, if the \nsizes aren't compatible, it can cause a core-dump. So, foregoing size_checking\nisn't advisable until your code is well debugged.\n\n \n

              Creating the Extension Module

              \n\nweave.blitz uses the same machinery as \nweave.inline to build the extension module. The only difference\nis the code included in the function is automatically generated from the\nNumeric array expression instead of supplied by the user.\n\n\n

              Extension Modules

              \nweave.inline and weave.blitz are high level tools\nthat generate extension modules automatically. Under the covers, they use several\nclasses from weave.ext_tools to help generate the extension module.\nThe main two classes are ext_module and ext_function (I'd\nlike to add ext_class and ext_method also). These classes\nsimplify the process of generating extension modules by handling most of the \"boiler\nplate\" code automatically.\n\n\nNote: inline actually sub-classes weave.ext_tools.ext_function \nto generate slightly different code than the standard ext_function.\nThe main difference is that the standard class converts function arguments to\nC types, while inline always has two arguments, the local and global dicts, and\nthe grabs the variables that need to be convereted to C from these.\n\n\n\n

              A Simple Example

              \nThe following simple example demonstrates how to build an extension module within\na Python function:\n\n 
              \n    # examples/increment_example.py\n    from weave import ext_tools\n    \n    def build_increment_ext():\n        \"\"\" Build a simple extension with functions that increment numbers.\n            The extension will be built in the local directory.\n        \"\"\"        \n        mod = ext_tools.ext_module('increment_ext')\n    \n        a = 1 # effectively a type declaration for 'a' in the \n              # following functions.\n    \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n        mod.add_function(func)\n        \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+2));\"    \n        func = ext_tools.ext_function('increment_by_2',ext_code,['a'])\n        mod.add_function(func)\n                \n        mod.compile()\n
              \n\n\nThe function build_increment_ext() creates an extension module \nnamed increment_ext and compiles it to a shared library (.so or \n.pyd) that can be loaded into Python.. increment_ext contains two \nfunctions, increment and increment_by_2. \n\nThe first line of build_increment_ext(),\n\n 
              \n        mod = ext_tools.ext_module('increment_ext') \n
              \n\ncreates an ext_module instance that is ready to have \next_function instances added to it. ext_function \ninstances are created much with a calling convention similar to \nweave.inline(). The most common call includes a C/C++ code \nsnippet and a list of the arguments for the function. The following\n\n 
              \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n
              \n \ncreates a C/C++ extension function that is equivalent to the following Python\nfunction:\n\n 
              \n        def increment(a):\n            return a + 1\n
              \n\nA second method is also added to the module and then,\n\n 
              \n        mod.compile()\n
              \n\nis called to build the extension module. By default, the module is created\nin the current working directory.\n\nThis example is available in the examples/increment_example.py file\nfound in the weave directory. At the bottom of the file in the\nmodule's \"main\" program, an attempt to import increment_ext without\nbuilding it is made. If this fails (the module doesn't exist in the PYTHONPATH), \nthe module is built by calling build_increment_ext(). This approach\nonly takes the time consuming ( a few seconds for this example) process of building\nthe module if it hasn't been built before.\n\n 
              \n    if __name__ == \"__main__\":\n        try:\n            import increment_ext\n        except ImportError:\n            build_increment_ext()\n            import increment_ext\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\n\nNote: If we were willing to always pay the penalty of building the C++ code for \na module, we could store the md5 checksum of the C++ code along with some \ninformation about the compiler, platform, etc. Then, \next_module.compile() could try importing the module before it actually\ncompiles it, check the md5 checksum and other meta-data in the imported module\nwith the meta-data of the code it just produced and only compile the code if\nthe module didn't exist or the meta-data didn't match. This would reduce the\nabove code to:\n\n 
              \n    if __name__ == \"__main__\":\n        build_increment_ext()\n\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\nNote: There would always be the overhead of building the C++ code, but it would only actually compile the code once. You pay a little in overhead and get cleaner\n\"import\" code. Needs some thought.\n\n

              \n\nIf you run increment_example.py from the command line, you get\nthe following:\n\n 

              \n    [eric@n0]$ python increment_example.py\n    a, a+1: 1 2\n    a, a+2: 1 3\n
              \n\nIf the module didn't exist before it was run, the module is created. If it did\nexist, it is just imported and used.\n\n\n

              Fibonacci Example

              \nexamples/fibonacci.py provides a little more complex example of \nhow to use ext_tools. Fibonacci numbers are a series of numbers \nwhere each number in the series is the sum of the previous two: 1, 1, 2, 3, 5, \n8, etc. Here, the first two numbers in the series are taken to be 1. One \napproach to calculating Fibonacci numbers uses recursive function calls. In \nPython, it might be written as:\n\n 
              \n    def fib(a):\n        if a <= 2:\n            return 1\n        else:\n            return fib(a-2) + fib(a-1)\n
              \n\nIn C, the same function would look something like this:\n\n 
              \n     int fib(int a)\n     {                   \n         if(a <= 2)\n             return 1;\n         else\n             return fib(a-2) + fib(a-1);  \n     }                      \n
              \n\nRecursion is much faster in C than in Python, so it would be beneficial\nto use the C version for fibonacci number calculations instead of the\nPython version. We need an extension function that calls this C function\nto do this. This is possible by including the above code snippet as \n\"support code\" and then calling it from the extension function. Support \ncode snippets (usually structure definitions, helper functions and the like)\nare inserted into the extension module C/C++ file before the extension\nfunction code. Here is how to build the C version of the fibonacci number\ngenerator:\n\n 
              \ndef build_fibonacci():\n    \"\"\" Builds an extension module with fibonacci calculators.\n    \"\"\"\n    mod = ext_tools.ext_module('fibonacci_ext')\n    a = 1 # this is effectively a type declaration\n    \n    # recursive fibonacci in C \n    fib_code = \"\"\"\n                   int fib1(int a)\n                   {                   \n                       if(a <= 2)\n                           return 1;\n                       else\n                           return fib1(a-2) + fib1(a-1);  \n                   }                         \n               \"\"\"\n    ext_code = \"\"\"\n                   int val = fib1(a);\n                   return_val = Py::new_reference_to(Py::Int(val));\n               \"\"\"    \n    fib = ext_tools.ext_function('fib',ext_code,['a'])\n    fib.customize.add_support_code(fib_code)\n    mod.add_function(fib)\n\n    mod.compile()\n\n
              \n\nXXX More about custom_info, and what xxx_info instances are good for.\n\n

              \n\nNote: recursion is not the fastest way to calculate fibonacci numbers, but this \napproach serves nicely for this example.\n\n

              \n\n

              Customizing Type Conversions -- Type Factories

              \nnot written\n\n

              Things I wish weave did

              \n\nIt is possible to get name clashes if you uses a variable name that is already defined\nin a header automatically included (such as stdio.h) For instance, if you\ntry to pass in a variable named stdout, you'll get a cryptic error report\ndue to the fact that stdio.h also defines the name. weave\nshould probably try and handle this in some way.\n\nOther things...", "methods": [], "methods_before": [], "changed_methods": [], "nloc": null, "complexity": null, "token_count": null, "diff_parsed": { "added": [ "Speed up is the improvement (degredation) factor of weave compared to", "conventional Python functions. The blitz() comparisons are shown", "compared to Numeric.", "", "The benchmarks shown blitz in the best possible light. Numeric", "(at least on my machine) is significantly worse for double precision than it is", "for single precision calculations. If your interested in single precision", "results, you can pretty much divide the double precision speed up by 3 and you'll", "be close.", "" ], "deleted": [] } } ] }, { "hash": "587e00a3ecd762fa58e04f7b46c29c654319f864", "msg": "Introduced get_version, started compaq_fortran_compiler", "author": { "name": "Pearu Peterson", "email": "pearu.peterson@gmail.com" }, "committer": { "name": "Pearu Peterson", "email": "pearu.peterson@gmail.com" }, "author_date": "2002-01-04T22:27:11+00:00", "author_timezone": 0, "committer_date": "2002-01-04T22:27:11+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "0ebec761d9cd9d48f68d8f5442519c828bcd0a2a" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 7, "insertions": 87, "lines": 94, "files": 3, "dmm_unit_size": 0.8636363636363636, "dmm_unit_complexity": 0.75, "dmm_unit_interfacing": 0.5, "modified_files": [ { "old_path": "scipy_distutils/command/build_flib.py", "new_path": "scipy_distutils/command/build_flib.py", "filename": "build_flib.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -36,10 +36,11 @@\n Absoft\n Sun\n SGI\n- Gnu\n Intel\n Itanium\n NAG\n+ Compaq\n+ Gnu\n VAST\n \"\"\"\n \n@@ -761,6 +762,43 @@ def __init__(self, fc = None, f90c = None):\n def get_linker_so(self):\n return [self.f90_compiler,'-shared']\n \n+class compaq_fortran_compiler(fortran_compiler_base):\n+\n+ vendor = 'Compaq'\n+ ver_match = r'Compaq Fortran (?P[^\\s]*)'\n+\n+ def __init__(self, fc = None, f90c = None):\n+ fortran_compiler_base.__init__(self)\n+\n+ if fc is None:\n+ fc = 'fort'\n+ if f90c is None:\n+ f90c = fc\n+\n+ self.f77_compiler = fc\n+ self.f90_compiler = f90c\n+\n+ switches = ' -assume no2underscore -nomixed_str_len_arg '\n+ debug = ' -g -check_bounds '\n+\n+ self.f77_switches = self.f90_switches = switches\n+ self.f77_debug = self.f90_debug = debug\n+ self.f77_opt = self.f90_opt = self.get_opt()\n+\n+ # XXX: uncomment if required\n+ #self.libraries = ' -lUfor -lfor -lFutil -lcpml -lots -lc '\n+\n+ # XXX: fix the version showing flag\n+ self.ver_cmd = self.f77_compiler+' -V '\n+\n+ def get_opt(self):\n+ opt = ' -O4 -align dcommons -arch host -assume bigarrays -assume nozsize -math_library fast -tune host '\n+ return opt\n+\n+ def get_linker_so(self):\n+ # XXX: is -shared needed?\n+ return [self.f77_compiler,'-shared']\n+\n \n def match_extension(files,ext):\n match = re.compile(r'.*[.]('+ext+r')\\Z',re.I).match\n@@ -790,11 +828,12 @@ def find_fortran_compiler(vendor = None, fc = None, f90c = None):\n all_compilers = [absoft_fortran_compiler,\n mips_fortran_compiler,\n sun_fortran_compiler,\n- gnu_fortran_compiler,\n intel_ia32_fortran_compiler,\n intel_itanium_fortran_compiler,\n nag_fortran_compiler,\n+ compaq_fortran_compiler,\n vast_fortran_compiler,\n+ gnu_fortran_compiler,\n ]\n \n if __name__ == \"__main__\":\n", "added_lines": 41, "deleted_lines": 2, "source_code": "\"\"\" Implements the build_flib command which should go into Distutils\n at some point.\n \n Note:\n Right now, we're dynamically linking to the Fortran libraries on \n some platforms (Sun for sure). This is fine for local installations\n but a bad thing for redistribution because these libraries won't\n live on any machine that doesn't have a fortran compiler installed.\n It is pretty hard (impossible?) to get gcc to pass the right compiler\n flags on Sun to get the linker to use static libs for the fortran\n stuff. Investigate further...\n\nBugs:\n *** Options -e and -x have no effect when used with --help-compiler\n options. E.g. \n ./setup.py build_flib --help-compiler -e g77-3.0\n finds g77-2.95.\n How to extract these options inside the show_compilers function?\n *** Option --force has no effect when switching a compiler. One must\n manually remove .o files that were generated earlier by a\n different compiler.\n *** compiler.is_available() method may not work correctly on nt\n because of lack of knowledge how to get exit status in\n run_command function. However, it may give reasonable results\n based on a version string.\n *** Some vendors provide different compilers for F77 and F90\n compilations. Currently, checking the availability of these\n compilers is based on only checking the availability of the\n corresponding F77 compiler. If it exists, then F90 is assumed\n to exist also.\n\nOpen issues:\n *** User-defined compiler flags. Do we need --fflags?\n\nFortran compilers (as to be used with --fcompiler= option):\n Absoft\n Sun\n SGI\n Intel\n Itanium\n NAG\n Compaq\n Gnu\n VAST\n\"\"\"\n\nimport distutils\nimport distutils.dep_util, distutils.dir_util\nimport os,sys,string\nimport commands,re\nfrom types import *\nfrom distutils.command.build_clib import build_clib\nfrom distutils.errors import *\n\nif os.name == 'nt':\n def run_command(command):\n \"\"\" not sure how to get exit status on nt. \"\"\"\n in_pipe,out_pipe = os.popen4(command)\n in_pipe.close()\n text = out_pipe.read()\n return 0, text\nelse:\n run_command = commands.getstatusoutput\n \ndef show_compilers():\n for compiler_class in all_compilers:\n compiler = compiler_class()\n if compiler.is_available():\n print compiler\n\nclass build_flib (build_clib):\n\n description = \"build f77/f90 libraries used by Python extensions\"\n\n user_options = [\n ('build-flib', 'b',\n \"directory to build f77/f90 libraries to\"),\n ('build-temp', 't',\n \"directory to put temporary build by-products\"),\n ('debug', 'g',\n \"compile with debugging information\"),\n ('force', 'f',\n \"forcibly build everything (ignore file timestamps)\"),\n ('fcompiler=', 'c',\n \"specify the compiler type\"),\n ('fcompiler-exec=', 'e',\n \"specify the path to F77 compiler\"),\n ('f90compiler-exec=', 'x',\n \"specify the path to F90 compiler\"),\n ]\n\n boolean_options = ['debug', 'force']\n\n help_options = [\n ('help-compiler', None,\n \"list available compilers\", show_compilers),\n ]\n\n def initialize_options (self):\n\n self.build_flib = None\n self.build_temp = None\n\n self.fortran_libraries = None\n self.define = None\n self.undef = None\n self.debug = None\n self.force = 0\n self.fcompiler = None\n self.fcompiler_exec = None\n self.f90compiler_exec = None\n\n # initialize_options()\n\n def finalize_options (self):\n self.set_undefined_options('build',\n ('build_temp', 'build_flib'),\n ('build_temp', 'build_temp'),\n ('debug', 'debug'),\n ('force', 'force'))\n fc = find_fortran_compiler(self.fcompiler,\n self.fcompiler_exec,\n self.f90compiler_exec)\n if not fc:\n raise DistutilsOptionError, 'Fortran compiler not available: %s'%(self.fcompiler)\n else:\n self.announce(' using %s Fortran compiler' % fc)\n self.fcompiler = fc\n if self.has_f_libraries():\n self.fortran_libraries = self.distribution.fortran_libraries\n self.check_library_list(self.fortran_libraries)\n\n # finalize_options()\n\n def has_f_libraries(self):\n return self.distribution.has_f_libraries()\n\n def run (self):\n if not self.has_f_libraries():\n return\n self.build_libraries(self.fortran_libraries)\n\n # run ()\n\n def get_library_names(self):\n if not self.has_f_libraries():\n return None\n\n lib_names = [] \n\n for (lib_name, build_info) in self.fortran_libraries:\n lib_names.append(lib_name)\n\n if self.fcompiler is not None:\n lib_names.extend(self.fcompiler.get_libraries())\n \n return lib_names\n\n # get_library_names ()\n\n def get_library_dirs(self):\n if not self.has_f_libraries():\n return []#None\n\n lib_dirs = [] \n\n if self.fcompiler is not None:\n lib_dirs.extend(self.fcompiler.get_library_dirs())\n \n return lib_dirs\n\n # get_library_dirs ()\n\n def get_runtime_library_dirs(self):\n if not self.has_f_libraries():\n return []#None\n\n lib_dirs = [] \n\n if self.fcompiler is not None:\n lib_dirs.extend(self.fcompiler.get_runtime_library_dirs())\n \n return lib_dirs\n\n # get_library_dirs ()\n\n def get_source_files (self):\n self.check_library_list(self.fortran_libraries)\n filenames = []\n\n # Gets source files specified \n for ext in self.fortran_libraries:\n filenames.extend(ext[1]['sources'])\n\n return filenames \n \n def build_libraries (self, fortran_libraries):\n \n fcompiler = self.fcompiler\n \n for (lib_name, build_info) in fortran_libraries:\n sources = build_info.get('sources')\n if sources is None or type(sources) not in (ListType, TupleType):\n raise DistutilsSetupError, \\\n (\"in 'fortran_libraries' option (library '%s'), \" +\n \"'sources' must be present and must be \" +\n \"a list of source filenames\") % lib_name\n sources = list(sources)\n module_dirs = build_info.get('module_dirs')\n module_files = build_info.get('module_files')\n self.announce(\" building '%s' library\" % lib_name)\n \n if module_files:\n fcompiler.build_library(lib_name, module_files,\n temp_dir=self.build_temp)\n \n fcompiler.build_library(lib_name, sources,\n module_dirs, temp_dir=self.build_temp)\n\n # for loop\n\n # build_libraries ()\n\n\nclass fortran_compiler_base:\n\n vendor = None\n ver_match = None\n \n def __init__(self):\n # Default initialization. Constructors of derived classes MUST\n # call this functions.\n self.version = None\n \n self.f77_switches = ''\n self.f77_opt = ''\n self.f77_debug = ''\n \n self.f90_switches = ''\n self.f90_opt = ''\n self.f90_debug = ''\n \n self.libraries = []\n self.library_dirs = []\n\n if self.vendor is None:\n raise DistutilsInternalError,\\\n '%s must define vendor attribute'%(self.__class__)\n if self.ver_match is None:\n raise DistutilsInternalError,\\\n '%s must define ver_match attribute'%(self.__class__)\n\n def to_object(self,dirty_files,module_dirs=None, temp_dir=''):\n files = string.join(dirty_files)\n f90_files = get_f90_files(dirty_files)\n f77_files = get_f77_files(dirty_files)\n if f90_files != []:\n obj1 = self.f90_compile(f90_files,module_dirs,temp_dir = temp_dir)\n else:\n obj1 = []\n if f77_files != []:\n obj2 = self.f77_compile(f77_files, temp_dir = temp_dir)\n else:\n obj2 = []\n return obj1 + obj2\n\n def source_to_object_names(self,source_files, temp_dir=''):\n file_list = map(lambda x: os.path.basename(x),source_files)\n file_base_ext = map(lambda x: os.path.splitext(x),file_list)\n object_list = map(lambda x: x[0] +'.o',file_base_ext)\n object_files = map(lambda x,td=temp_dir: os.path.join(td,x),object_list)\n return object_files\n \n def source_and_object_pairs(self,source_files, temp_dir=''):\n object_files = self.source_to_object_names(source_files,temp_dir)\n file_pairs = zip(source_files,object_files)\n return file_pairs\n \n def f_compile(self,compiler,switches, source_files,\n module_dirs=None, temp_dir=''):\n module_switch = self.build_module_switch(module_dirs)\n file_pairs = self.source_and_object_pairs(source_files,temp_dir)\n object_files = []\n for source,object in file_pairs:\n if distutils.dep_util.newer(source,object):\n cmd = compiler + ' ' + switches + \\\n module_switch + ' -c ' + source + ' -o ' + object \n print cmd\n failure = os.system(cmd)\n if failure:\n raise ValueError, 'failure during compile' \n object_files.append(object)\n return object_files\n #return all object files to make sure everything is archived \n #return map(lambda x: x[1], file_pairs)\n\n def f90_compile(self,source_files,module_dirs=None, temp_dir=''):\n switches = string.join((self.f90_switches, self.f90_opt))\n return self.f_compile(self.f90_compiler,switches,\n source_files, module_dirs,temp_dir)\n\n def f77_compile(self,source_files,module_dirs=None, temp_dir=''):\n switches = string.join((self.f77_switches, self.f77_opt))\n return self.f_compile(self.f77_compiler,switches,\n source_files, module_dirs,temp_dir)\n\n\n def build_module_switch(self, module_dirs):\n return ''\n\n def create_static_lib(self, object_files, library_name,\n output_dir='', debug=None):\n lib_file = os.path.join(output_dir,'lib'+library_name+'.a')\n newer = distutils.dep_util.newer\n # This doesn't work -- no way to know if the file is in the archive\n #object_files = filter(lambda o,lib=lib_file:\\\n # distutils.dep_util.newer(o,lib),object_files)\n objects = string.join(object_files)\n if objects:\n cmd = 'ar -cur %s %s' % (lib_file,objects)\n print cmd\n os.system(cmd)\n\n def build_library(self,library_name,source_list,module_dirs=None,\n temp_dir = ''):\n #make sure the temp directory exists before trying to build files\n import distutils.dir_util\n distutils.dir_util.mkpath(temp_dir)\n #this compiles the files\n object_list = self.to_object(source_list,module_dirs,temp_dir)\n # actually we need to use all the object file names here to\n # make sure the library is always built. It could occur that an\n # object file exists but hasn't been put in the archive. (happens\n # a lot when builds fail once and are restarted).\n object_list = self.source_to_object_names(source_list, temp_dir)\n #self.create_static_lib(object_list,library_name,temp_dir) \n # This is pure bunk...\n # Windows fails for long argument strings on the command line.\n # if objects is real long (> 2048 chars or so on my machine),\n # the command fails (cmd.exe /e:2048 on w2k)\n # for now we'll split linking into to steps which should work for\n objects = object_list[:]\n while objects:\n obj,objects = objects[:20],objects[20:]\n self.create_static_lib(obj,library_name,temp_dir)\n\n def dummy_fortran_files(self):\n import tempfile \n d = tempfile.gettempdir()\n dummy_name = os.path.join(d,'__dummy.f')\n dummy = open(dummy_name,'w')\n dummy.write(\" subroutine dummy()\\n end\\n\")\n dummy.close()\n return (os.path.join(d,'__dummy.f'),os.path.join(d,'__dummy.o'))\n \n def is_available(self):\n return self.get_version()\n \n def get_version(self):\n \"\"\"Return the compiler version. If compiler is not available,\n return empty string.\"\"\"\n # XXX: Is there compilers that have no version? If yes,\n # this test will fail even if the compiler is available.\n if self.version is not None:\n # Finding version is expensive, so return previously found\n # version string.\n return self.version\n self.version = ''\n # works I think only for unix... \n #print 'command:', self.ver_cmd\n exit_status, out_text = run_command(self.ver_cmd)\n #print exit_status, out_text\n if not exit_status:\n m = re.match(self.ver_match,out_text)\n if m:\n self.version = m.group('version')\n return self.version\n\n def get_libraries(self):\n return self.libraries\n def get_library_dirs(self):\n return self.library_dirs\n def get_extra_link_args(self):\n return []\n def get_runtime_library_dirs(self):\n return []\n def get_linker_so(self):\n \"\"\"\n If a compiler requires specific linker then return a list\n containing a linker executable name and linker options.\n Otherwise, return None.\n \"\"\"\n\n def __str__(self):\n return \"%s %s\" % (self.vendor, self.get_version())\n\n\nclass absoft_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Absoft'\n ver_match = r'FORTRAN 77 Compiler (?P[^\\s*,]*).*?Absoft Corp'\n \n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n # got rid of -B108 cause it was generating 2 underscores instead\n # of one on the newest version. Now we use -YEXT_SFX=_ to \n # specify the output format\n if os.name == 'nt':\n self.f90_switches = '-f fixed -YCFRL=1 -YCOM_NAMES=LCS' \\\n ' -YCOM_PFX -YEXT_PFX -YEXT_NAMES=LCS' \\\n ' -YCOM_SFX=_ -YEXT_SFX=_ -YEXT_NAMES=LCS' \n self.f90_opt = '-O -Q100'\n self.f77_switches = '-N22 -N90 -N110'\n self.f77_opt = '-O -Q100'\n self.libraries = ['fio', 'fmath', 'f90math', 'COMDLG32']\n else:\n self.f90_switches = '-ffixed -YCFRL=1 -YCOM_NAMES=LCS' \\\n ' -YCOM_PFX -YEXT_PFX -YEXT_NAMES=LCS' \\\n ' -YCOM_SFX=_ -YEXT_SFX=_ -YEXT_NAMES=LCS' \n self.f90_opt = '-O -B101' \n self.f77_switches = '-N22 -N90 -N110 -B108'\n self.f77_opt = '-O -B101'\n\n self.libraries = ['fio', 'f77math', 'f90math']\n \n try:\n dir = os.environ['ABSOFT'] \n self.library_dirs = [os.path.join(dir,'lib')]\n except KeyError:\n self.library_dirs = []\n\n self.ver_cmd = self.f77_compiler + ' -V -c %s -o %s' % \\\n self.dummy_fortran_files()\n\n def build_module_switch(self,module_dirs):\n res = ''\n if module_dirs:\n for mod in module_dirs:\n res = res + ' -p' + mod\n return res\n\n def get_extra_link_args(self):\n return []\n # Couldn't get this to link for anything using gcc.\n #dr = \"c:\\\\Absoft62\\\\lib\"\n #libs = ['fio.lib', 'COMDLG32.lib','fmath.lib', 'f90math.lib','libcomdlg32.a' ] \n #libs = map(lambda x,dr=dr:os.path.join(dr,x),libs)\n #return libs\n\n\nclass sun_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Sun'\n ver_match = r'f77: (?P[^\\s*,]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc # not tested\n self.f77_switches = ' -pic '\n self.f77_opt = ' -fast -dalign '\n\n self.f90_compiler = f90c\n self.f90_switches = ' -fixed ' # ??? why fixed?\n self.f90_opt = ' -fast -dalign '\n\n self.libraries = ['f90', 'F77', 'M77', 'sunmath', 'm']\n #threaded\n #self.libraries = ['f90', 'F77_mt', 'sunmath_mt', 'm', 'thread']\n #self.libraries = []\n self.library_dirs = self.find_lib_dir()\n #print 'sun:',self.library_dirs\n\n self.ver_cmd = self.f77_compiler + ' -V'\n\n def build_module_switch(self,module_dirs):\n res = ''\n if module_dirs:\n for mod in module_dirs:\n res = res + ' -M' + mod\n return res\n\n def find_lib_dir(self):\n library_dirs = []\n lib_match = r'### f90: Note: LD_RUN_PATH\\s*= '\\\n '(?P[^\\s.]*).*'\n cmd = self.f90_compiler + ' -dryrun dummy.f'\n exit_status, output = run_command(cmd)\n if not exit_status:\n libs = re.findall(lib_match,output)\n if libs:\n library_dirs = string.split(libs[0],':')\n self.get_version() # force version calculation\n compiler_home = os.path.dirname(library_dirs[0])\n library_dirs.append(os.path.join(compiler_home,\n self.version,'lib'))\n return library_dirs\n def get_runtime_library_dirs(self):\n return self.find_lib_dir()\n def get_extra_link_args(self):\n return ['-mimpure-text']\n\n\nclass mips_fortran_compiler(fortran_compiler_base):\n\n vendor = 'SGI'\n ver_match = r'MIPSpro Compilers: Version (?P[^\\s*,]*)'\n \n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc # not tested\n self.f77_switches = ' -n32 -KPIC '\n self.f77_opt = ' -O3 '\n\n self.f90_compiler = f90c\n self.f90_switches = ' -n32 -KPIC -fixedform ' # why fixed ???\n self.f90_opt = ' ' \n \n self.libraries = ['fortran', 'ftn', 'm']\n self.library_dirs = self.find_lib_dir()\n\n self.ver_cmd = self.f77_compiler + ' -version'\n\n def build_module_switch(self,module_dirs):\n res = ''\n return res \n def find_lib_dir(self):\n library_dirs = []\n return library_dirs\n def get_runtime_library_dirs(self):\n\treturn self.find_lib_dir() \n def get_extra_link_args(self):\n\treturn []\n\n\nclass gnu_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Gnu'\n ver_match = r'g77 version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if sys.platform == 'win32':\n self.libraries = ['gcc','g2c']\n self.library_dirs = self.find_lib_directories()\n\n if fc is None:\n fc = 'g77'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n\n switches = ' -Wall -fno-second-underscore '\n\n if os.name != 'nt':\n switches = switches + ' -fpic '\n\n self.f77_switches = switches\n\n self.ver_cmd = self.f77_compiler + ' -v '\n self.f77_opt = self.get_opt()\n\n def get_opt(self):\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n opt = ' -O3 -funroll-loops '\n \n # only check for more optimization if g77 can handle\n # it.\n if self.get_version():\n if self.version[0]=='3': # is g77 3.x.x\n if cpu.is_AthlonK6():\n opt = opt + ' -march=k6 '\n elif cpu.is_AthlonK7():\n opt = opt + ' -march=athlon '\n if cpu.is_i686():\n opt = opt + ' -march=i686 '\n elif cpu.is_i586():\n opt = opt + ' -march=i586 '\n elif cpu.is_i486():\n opt = opt + ' -march=i486 '\n elif cpu.is_i386():\n opt = opt + ' -march=i386 '\n if cpu.is_Intel():\n opt = opt + ' -malign-double ' \n return opt\n \n def find_lib_directories(self):\n lib_dir = []\n match = r'Reading specs from (.*)/specs'\n\n # works I think only for unix... \n exit_status, out_text = run_command('g77 -v')\n if not exit_status:\n m = re.findall(match,out_text)\n if m:\n lib_dir= m #m[0] \n return lib_dir\n\n def get_linker_so(self):\n # win32 linking should be handled by standard linker\n if sys.platform != 'win32':\n return [self.f77_compiler,'-shared']\n \n def f90_compile(self,source_files,module_files,temp_dir=''):\n raise DistutilsExecError, 'f90 not supported by Gnu'\n\n\n#http://developer.intel.com/software/products/compilers/f50/linux/\nclass intel_ia32_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Intel' # Intel(R) Corporation \n ver_match = r'Intel\\(R\\) Fortran Compiler for 32-bit applications, Version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'ifc'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n switches = ' -KPIC '\n\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n if cpu.has_fdiv_bug():\n switches = switches + ' -fdiv_check '\n if cpu.has_f00f_bug():\n switches = switches + ' -0f_check '\n self.f77_switches = self.f90_switches = switches\n self.f77_switches = self.f77_switches + ' -FI '\n\n self.f77_opt = self.f90_opt = self.get_opt()\n \n debug = ' -g -C '\n self.f77_debug = self.f90_debug = debug\n\n self.ver_cmd = self.f77_compiler+' -FI -V -c %s -o %s' %\\\n self.dummy_fortran_files()\n\n def get_opt(self):\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n opt = ' -O3 '\n if cpu.is_PentiumPro() or cpu.is_PentiumII():\n opt = opt + ' -tpp6 -xi '\n elif cpu.is_PentiumIII():\n opt = opt + ' -tpp6 '\n elif cpu.is_Pentium():\n opt = opt + ' -tpp5 '\n elif cpu.is_PentiumIV():\n opt = opt + ' -tpp7 -xW '\n elif cpu.has_mmx():\n opt = opt + ' -xM '\n return opt\n \n\n def get_linker_so(self):\n return [self.f77_compiler,'-shared']\n\n\nclass intel_itanium_fortran_compiler(intel_ia32_fortran_compiler):\n\n vendor = 'Itanium'\n ver_match = r'Intel\\(R\\) Fortran 90 Compiler Itanium\\(TM\\) Compiler for the Itanium\\(TM\\)-based applications, Version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n if fc is None:\n fc = 'efc'\n intel_ia32_fortran_compiler.__init__(self, fc, f90c)\n\n\nclass nag_fortran_compiler(fortran_compiler_base):\n\n vendor = 'NAG'\n ver_match = r'NAGWare Fortran 95 compiler Release (?P[^\\s]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'f95'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n switches = ''\n debug = ' -g -gline -g90 -nan -C '\n\n self.f77_switches = self.f90_switches = switches\n self.f77_switches = self.f77_switches + ' -fixed '\n self.f77_debug = self.f90_debug = debug\n self.f77_opt = self.f90_opt = self.get_opt()\n\n self.ver_cmd = self.f77_compiler+' -V '\n\n def get_opt(self):\n opt = ' -O4 -target=native '\n return opt\n\n def get_linker_so(self):\n return [self.f77_compiler,'-Wl,-shared']\n\n\nclass vast_fortran_compiler(fortran_compiler_base):\n\n vendor = 'VAST'\n ver_match = r'\\s*Pacific-Sierra Research vf90 (Personal|Professional)\\s+(?P[^\\s]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'g77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n d,b = os.path.split(f90c)\n vf90 = os.path.join(d,'v'+b)\n self.ver_cmd = vf90+' -v '\n\n gnu = gnu_fortran_compiler(fc)\n if not gnu.is_available(): # VAST compiler requires g77.\n self.version = ''\n return\n if not self.is_available():\n return\n\n self.f77_switches = gnu.f77_switches\n self.f77_debug = gnu.f77_debug\n self.f77_opt = gnu.f77_opt \n\n # XXX: need f90 switches, debug, opt\n\n def get_linker_so(self):\n return [self.f90_compiler,'-shared']\n\nclass compaq_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Compaq'\n ver_match = r'Compaq Fortran (?P[^\\s]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'fort'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n switches = ' -assume no2underscore -nomixed_str_len_arg '\n debug = ' -g -check_bounds '\n\n self.f77_switches = self.f90_switches = switches\n self.f77_debug = self.f90_debug = debug\n self.f77_opt = self.f90_opt = self.get_opt()\n\n # XXX: uncomment if required\n #self.libraries = ' -lUfor -lfor -lFutil -lcpml -lots -lc '\n\n # XXX: fix the version showing flag\n self.ver_cmd = self.f77_compiler+' -V '\n\n def get_opt(self):\n opt = ' -O4 -align dcommons -arch host -assume bigarrays -assume nozsize -math_library fast -tune host '\n return opt\n\n def get_linker_so(self):\n # XXX: is -shared needed?\n return [self.f77_compiler,'-shared']\n\n\ndef match_extension(files,ext):\n match = re.compile(r'.*[.]('+ext+r')\\Z',re.I).match\n return filter(lambda x,match = match: match(x),files)\n\ndef get_f77_files(files):\n return match_extension(files,'for|f77|ftn|f')\n\ndef get_f90_files(files):\n return match_extension(files,'f90|f95')\n\ndef get_fortran_files(files):\n return match_extension(files,'f90|f95|for|f77|ftn|f')\n\ndef find_fortran_compiler(vendor = None, fc = None, f90c = None):\n fcompiler = None\n for compiler_class in all_compilers:\n if vendor is not None and vendor != compiler_class.vendor:\n continue\n print compiler_class\n compiler = compiler_class(fc,f90c)\n if compiler.is_available():\n fcompiler = compiler\n break\n return fcompiler\n\nall_compilers = [absoft_fortran_compiler,\n mips_fortran_compiler,\n sun_fortran_compiler,\n intel_ia32_fortran_compiler,\n intel_itanium_fortran_compiler,\n nag_fortran_compiler,\n compaq_fortran_compiler,\n vast_fortran_compiler,\n gnu_fortran_compiler,\n ]\n\nif __name__ == \"__main__\":\n show_compilers()\n", "source_code_before": "\"\"\" Implements the build_flib command which should go into Distutils\n at some point.\n \n Note:\n Right now, we're dynamically linking to the Fortran libraries on \n some platforms (Sun for sure). This is fine for local installations\n but a bad thing for redistribution because these libraries won't\n live on any machine that doesn't have a fortran compiler installed.\n It is pretty hard (impossible?) to get gcc to pass the right compiler\n flags on Sun to get the linker to use static libs for the fortran\n stuff. Investigate further...\n\nBugs:\n *** Options -e and -x have no effect when used with --help-compiler\n options. E.g. \n ./setup.py build_flib --help-compiler -e g77-3.0\n finds g77-2.95.\n How to extract these options inside the show_compilers function?\n *** Option --force has no effect when switching a compiler. One must\n manually remove .o files that were generated earlier by a\n different compiler.\n *** compiler.is_available() method may not work correctly on nt\n because of lack of knowledge how to get exit status in\n run_command function. However, it may give reasonable results\n based on a version string.\n *** Some vendors provide different compilers for F77 and F90\n compilations. Currently, checking the availability of these\n compilers is based on only checking the availability of the\n corresponding F77 compiler. If it exists, then F90 is assumed\n to exist also.\n\nOpen issues:\n *** User-defined compiler flags. Do we need --fflags?\n\nFortran compilers (as to be used with --fcompiler= option):\n Absoft\n Sun\n SGI\n Gnu\n Intel\n Itanium\n NAG\n VAST\n\"\"\"\n\nimport distutils\nimport distutils.dep_util, distutils.dir_util\nimport os,sys,string\nimport commands,re\nfrom types import *\nfrom distutils.command.build_clib import build_clib\nfrom distutils.errors import *\n\nif os.name == 'nt':\n def run_command(command):\n \"\"\" not sure how to get exit status on nt. \"\"\"\n in_pipe,out_pipe = os.popen4(command)\n in_pipe.close()\n text = out_pipe.read()\n return 0, text\nelse:\n run_command = commands.getstatusoutput\n \ndef show_compilers():\n for compiler_class in all_compilers:\n compiler = compiler_class()\n if compiler.is_available():\n print compiler\n\nclass build_flib (build_clib):\n\n description = \"build f77/f90 libraries used by Python extensions\"\n\n user_options = [\n ('build-flib', 'b',\n \"directory to build f77/f90 libraries to\"),\n ('build-temp', 't',\n \"directory to put temporary build by-products\"),\n ('debug', 'g',\n \"compile with debugging information\"),\n ('force', 'f',\n \"forcibly build everything (ignore file timestamps)\"),\n ('fcompiler=', 'c',\n \"specify the compiler type\"),\n ('fcompiler-exec=', 'e',\n \"specify the path to F77 compiler\"),\n ('f90compiler-exec=', 'x',\n \"specify the path to F90 compiler\"),\n ]\n\n boolean_options = ['debug', 'force']\n\n help_options = [\n ('help-compiler', None,\n \"list available compilers\", show_compilers),\n ]\n\n def initialize_options (self):\n\n self.build_flib = None\n self.build_temp = None\n\n self.fortran_libraries = None\n self.define = None\n self.undef = None\n self.debug = None\n self.force = 0\n self.fcompiler = None\n self.fcompiler_exec = None\n self.f90compiler_exec = None\n\n # initialize_options()\n\n def finalize_options (self):\n self.set_undefined_options('build',\n ('build_temp', 'build_flib'),\n ('build_temp', 'build_temp'),\n ('debug', 'debug'),\n ('force', 'force'))\n fc = find_fortran_compiler(self.fcompiler,\n self.fcompiler_exec,\n self.f90compiler_exec)\n if not fc:\n raise DistutilsOptionError, 'Fortran compiler not available: %s'%(self.fcompiler)\n else:\n self.announce(' using %s Fortran compiler' % fc)\n self.fcompiler = fc\n if self.has_f_libraries():\n self.fortran_libraries = self.distribution.fortran_libraries\n self.check_library_list(self.fortran_libraries)\n\n # finalize_options()\n\n def has_f_libraries(self):\n return self.distribution.has_f_libraries()\n\n def run (self):\n if not self.has_f_libraries():\n return\n self.build_libraries(self.fortran_libraries)\n\n # run ()\n\n def get_library_names(self):\n if not self.has_f_libraries():\n return None\n\n lib_names = [] \n\n for (lib_name, build_info) in self.fortran_libraries:\n lib_names.append(lib_name)\n\n if self.fcompiler is not None:\n lib_names.extend(self.fcompiler.get_libraries())\n \n return lib_names\n\n # get_library_names ()\n\n def get_library_dirs(self):\n if not self.has_f_libraries():\n return []#None\n\n lib_dirs = [] \n\n if self.fcompiler is not None:\n lib_dirs.extend(self.fcompiler.get_library_dirs())\n \n return lib_dirs\n\n # get_library_dirs ()\n\n def get_runtime_library_dirs(self):\n if not self.has_f_libraries():\n return []#None\n\n lib_dirs = [] \n\n if self.fcompiler is not None:\n lib_dirs.extend(self.fcompiler.get_runtime_library_dirs())\n \n return lib_dirs\n\n # get_library_dirs ()\n\n def get_source_files (self):\n self.check_library_list(self.fortran_libraries)\n filenames = []\n\n # Gets source files specified \n for ext in self.fortran_libraries:\n filenames.extend(ext[1]['sources'])\n\n return filenames \n \n def build_libraries (self, fortran_libraries):\n \n fcompiler = self.fcompiler\n \n for (lib_name, build_info) in fortran_libraries:\n sources = build_info.get('sources')\n if sources is None or type(sources) not in (ListType, TupleType):\n raise DistutilsSetupError, \\\n (\"in 'fortran_libraries' option (library '%s'), \" +\n \"'sources' must be present and must be \" +\n \"a list of source filenames\") % lib_name\n sources = list(sources)\n module_dirs = build_info.get('module_dirs')\n module_files = build_info.get('module_files')\n self.announce(\" building '%s' library\" % lib_name)\n \n if module_files:\n fcompiler.build_library(lib_name, module_files,\n temp_dir=self.build_temp)\n \n fcompiler.build_library(lib_name, sources,\n module_dirs, temp_dir=self.build_temp)\n\n # for loop\n\n # build_libraries ()\n\n\nclass fortran_compiler_base:\n\n vendor = None\n ver_match = None\n \n def __init__(self):\n # Default initialization. Constructors of derived classes MUST\n # call this functions.\n self.version = None\n \n self.f77_switches = ''\n self.f77_opt = ''\n self.f77_debug = ''\n \n self.f90_switches = ''\n self.f90_opt = ''\n self.f90_debug = ''\n \n self.libraries = []\n self.library_dirs = []\n\n if self.vendor is None:\n raise DistutilsInternalError,\\\n '%s must define vendor attribute'%(self.__class__)\n if self.ver_match is None:\n raise DistutilsInternalError,\\\n '%s must define ver_match attribute'%(self.__class__)\n\n def to_object(self,dirty_files,module_dirs=None, temp_dir=''):\n files = string.join(dirty_files)\n f90_files = get_f90_files(dirty_files)\n f77_files = get_f77_files(dirty_files)\n if f90_files != []:\n obj1 = self.f90_compile(f90_files,module_dirs,temp_dir = temp_dir)\n else:\n obj1 = []\n if f77_files != []:\n obj2 = self.f77_compile(f77_files, temp_dir = temp_dir)\n else:\n obj2 = []\n return obj1 + obj2\n\n def source_to_object_names(self,source_files, temp_dir=''):\n file_list = map(lambda x: os.path.basename(x),source_files)\n file_base_ext = map(lambda x: os.path.splitext(x),file_list)\n object_list = map(lambda x: x[0] +'.o',file_base_ext)\n object_files = map(lambda x,td=temp_dir: os.path.join(td,x),object_list)\n return object_files\n \n def source_and_object_pairs(self,source_files, temp_dir=''):\n object_files = self.source_to_object_names(source_files,temp_dir)\n file_pairs = zip(source_files,object_files)\n return file_pairs\n \n def f_compile(self,compiler,switches, source_files,\n module_dirs=None, temp_dir=''):\n module_switch = self.build_module_switch(module_dirs)\n file_pairs = self.source_and_object_pairs(source_files,temp_dir)\n object_files = []\n for source,object in file_pairs:\n if distutils.dep_util.newer(source,object):\n cmd = compiler + ' ' + switches + \\\n module_switch + ' -c ' + source + ' -o ' + object \n print cmd\n failure = os.system(cmd)\n if failure:\n raise ValueError, 'failure during compile' \n object_files.append(object)\n return object_files\n #return all object files to make sure everything is archived \n #return map(lambda x: x[1], file_pairs)\n\n def f90_compile(self,source_files,module_dirs=None, temp_dir=''):\n switches = string.join((self.f90_switches, self.f90_opt))\n return self.f_compile(self.f90_compiler,switches,\n source_files, module_dirs,temp_dir)\n\n def f77_compile(self,source_files,module_dirs=None, temp_dir=''):\n switches = string.join((self.f77_switches, self.f77_opt))\n return self.f_compile(self.f77_compiler,switches,\n source_files, module_dirs,temp_dir)\n\n\n def build_module_switch(self, module_dirs):\n return ''\n\n def create_static_lib(self, object_files, library_name,\n output_dir='', debug=None):\n lib_file = os.path.join(output_dir,'lib'+library_name+'.a')\n newer = distutils.dep_util.newer\n # This doesn't work -- no way to know if the file is in the archive\n #object_files = filter(lambda o,lib=lib_file:\\\n # distutils.dep_util.newer(o,lib),object_files)\n objects = string.join(object_files)\n if objects:\n cmd = 'ar -cur %s %s' % (lib_file,objects)\n print cmd\n os.system(cmd)\n\n def build_library(self,library_name,source_list,module_dirs=None,\n temp_dir = ''):\n #make sure the temp directory exists before trying to build files\n import distutils.dir_util\n distutils.dir_util.mkpath(temp_dir)\n #this compiles the files\n object_list = self.to_object(source_list,module_dirs,temp_dir)\n # actually we need to use all the object file names here to\n # make sure the library is always built. It could occur that an\n # object file exists but hasn't been put in the archive. (happens\n # a lot when builds fail once and are restarted).\n object_list = self.source_to_object_names(source_list, temp_dir)\n #self.create_static_lib(object_list,library_name,temp_dir) \n # This is pure bunk...\n # Windows fails for long argument strings on the command line.\n # if objects is real long (> 2048 chars or so on my machine),\n # the command fails (cmd.exe /e:2048 on w2k)\n # for now we'll split linking into to steps which should work for\n objects = object_list[:]\n while objects:\n obj,objects = objects[:20],objects[20:]\n self.create_static_lib(obj,library_name,temp_dir)\n\n def dummy_fortran_files(self):\n import tempfile \n d = tempfile.gettempdir()\n dummy_name = os.path.join(d,'__dummy.f')\n dummy = open(dummy_name,'w')\n dummy.write(\" subroutine dummy()\\n end\\n\")\n dummy.close()\n return (os.path.join(d,'__dummy.f'),os.path.join(d,'__dummy.o'))\n \n def is_available(self):\n return self.get_version()\n \n def get_version(self):\n \"\"\"Return the compiler version. If compiler is not available,\n return empty string.\"\"\"\n # XXX: Is there compilers that have no version? If yes,\n # this test will fail even if the compiler is available.\n if self.version is not None:\n # Finding version is expensive, so return previously found\n # version string.\n return self.version\n self.version = ''\n # works I think only for unix... \n #print 'command:', self.ver_cmd\n exit_status, out_text = run_command(self.ver_cmd)\n #print exit_status, out_text\n if not exit_status:\n m = re.match(self.ver_match,out_text)\n if m:\n self.version = m.group('version')\n return self.version\n\n def get_libraries(self):\n return self.libraries\n def get_library_dirs(self):\n return self.library_dirs\n def get_extra_link_args(self):\n return []\n def get_runtime_library_dirs(self):\n return []\n def get_linker_so(self):\n \"\"\"\n If a compiler requires specific linker then return a list\n containing a linker executable name and linker options.\n Otherwise, return None.\n \"\"\"\n\n def __str__(self):\n return \"%s %s\" % (self.vendor, self.get_version())\n\n\nclass absoft_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Absoft'\n ver_match = r'FORTRAN 77 Compiler (?P[^\\s*,]*).*?Absoft Corp'\n \n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n # got rid of -B108 cause it was generating 2 underscores instead\n # of one on the newest version. Now we use -YEXT_SFX=_ to \n # specify the output format\n if os.name == 'nt':\n self.f90_switches = '-f fixed -YCFRL=1 -YCOM_NAMES=LCS' \\\n ' -YCOM_PFX -YEXT_PFX -YEXT_NAMES=LCS' \\\n ' -YCOM_SFX=_ -YEXT_SFX=_ -YEXT_NAMES=LCS' \n self.f90_opt = '-O -Q100'\n self.f77_switches = '-N22 -N90 -N110'\n self.f77_opt = '-O -Q100'\n self.libraries = ['fio', 'fmath', 'f90math', 'COMDLG32']\n else:\n self.f90_switches = '-ffixed -YCFRL=1 -YCOM_NAMES=LCS' \\\n ' -YCOM_PFX -YEXT_PFX -YEXT_NAMES=LCS' \\\n ' -YCOM_SFX=_ -YEXT_SFX=_ -YEXT_NAMES=LCS' \n self.f90_opt = '-O -B101' \n self.f77_switches = '-N22 -N90 -N110 -B108'\n self.f77_opt = '-O -B101'\n\n self.libraries = ['fio', 'f77math', 'f90math']\n \n try:\n dir = os.environ['ABSOFT'] \n self.library_dirs = [os.path.join(dir,'lib')]\n except KeyError:\n self.library_dirs = []\n\n self.ver_cmd = self.f77_compiler + ' -V -c %s -o %s' % \\\n self.dummy_fortran_files()\n\n def build_module_switch(self,module_dirs):\n res = ''\n if module_dirs:\n for mod in module_dirs:\n res = res + ' -p' + mod\n return res\n\n def get_extra_link_args(self):\n return []\n # Couldn't get this to link for anything using gcc.\n #dr = \"c:\\\\Absoft62\\\\lib\"\n #libs = ['fio.lib', 'COMDLG32.lib','fmath.lib', 'f90math.lib','libcomdlg32.a' ] \n #libs = map(lambda x,dr=dr:os.path.join(dr,x),libs)\n #return libs\n\n\nclass sun_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Sun'\n ver_match = r'f77: (?P[^\\s*,]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc # not tested\n self.f77_switches = ' -pic '\n self.f77_opt = ' -fast -dalign '\n\n self.f90_compiler = f90c\n self.f90_switches = ' -fixed ' # ??? why fixed?\n self.f90_opt = ' -fast -dalign '\n\n self.libraries = ['f90', 'F77', 'M77', 'sunmath', 'm']\n #threaded\n #self.libraries = ['f90', 'F77_mt', 'sunmath_mt', 'm', 'thread']\n #self.libraries = []\n self.library_dirs = self.find_lib_dir()\n #print 'sun:',self.library_dirs\n\n self.ver_cmd = self.f77_compiler + ' -V'\n\n def build_module_switch(self,module_dirs):\n res = ''\n if module_dirs:\n for mod in module_dirs:\n res = res + ' -M' + mod\n return res\n\n def find_lib_dir(self):\n library_dirs = []\n lib_match = r'### f90: Note: LD_RUN_PATH\\s*= '\\\n '(?P[^\\s.]*).*'\n cmd = self.f90_compiler + ' -dryrun dummy.f'\n exit_status, output = run_command(cmd)\n if not exit_status:\n libs = re.findall(lib_match,output)\n if libs:\n library_dirs = string.split(libs[0],':')\n self.get_version() # force version calculation\n compiler_home = os.path.dirname(library_dirs[0])\n library_dirs.append(os.path.join(compiler_home,\n self.version,'lib'))\n return library_dirs\n def get_runtime_library_dirs(self):\n return self.find_lib_dir()\n def get_extra_link_args(self):\n return ['-mimpure-text']\n\n\nclass mips_fortran_compiler(fortran_compiler_base):\n\n vendor = 'SGI'\n ver_match = r'MIPSpro Compilers: Version (?P[^\\s*,]*)'\n \n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if fc is None:\n fc = 'f77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc # not tested\n self.f77_switches = ' -n32 -KPIC '\n self.f77_opt = ' -O3 '\n\n self.f90_compiler = f90c\n self.f90_switches = ' -n32 -KPIC -fixedform ' # why fixed ???\n self.f90_opt = ' ' \n \n self.libraries = ['fortran', 'ftn', 'm']\n self.library_dirs = self.find_lib_dir()\n\n self.ver_cmd = self.f77_compiler + ' -version'\n\n def build_module_switch(self,module_dirs):\n res = ''\n return res \n def find_lib_dir(self):\n library_dirs = []\n return library_dirs\n def get_runtime_library_dirs(self):\n\treturn self.find_lib_dir() \n def get_extra_link_args(self):\n\treturn []\n\n\nclass gnu_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Gnu'\n ver_match = r'g77 version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n if sys.platform == 'win32':\n self.libraries = ['gcc','g2c']\n self.library_dirs = self.find_lib_directories()\n\n if fc is None:\n fc = 'g77'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n\n switches = ' -Wall -fno-second-underscore '\n\n if os.name != 'nt':\n switches = switches + ' -fpic '\n\n self.f77_switches = switches\n\n self.ver_cmd = self.f77_compiler + ' -v '\n self.f77_opt = self.get_opt()\n\n def get_opt(self):\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n opt = ' -O3 -funroll-loops '\n \n # only check for more optimization if g77 can handle\n # it.\n if self.get_version():\n if self.version[0]=='3': # is g77 3.x.x\n if cpu.is_AthlonK6():\n opt = opt + ' -march=k6 '\n elif cpu.is_AthlonK7():\n opt = opt + ' -march=athlon '\n if cpu.is_i686():\n opt = opt + ' -march=i686 '\n elif cpu.is_i586():\n opt = opt + ' -march=i586 '\n elif cpu.is_i486():\n opt = opt + ' -march=i486 '\n elif cpu.is_i386():\n opt = opt + ' -march=i386 '\n if cpu.is_Intel():\n opt = opt + ' -malign-double ' \n return opt\n \n def find_lib_directories(self):\n lib_dir = []\n match = r'Reading specs from (.*)/specs'\n\n # works I think only for unix... \n exit_status, out_text = run_command('g77 -v')\n if not exit_status:\n m = re.findall(match,out_text)\n if m:\n lib_dir= m #m[0] \n return lib_dir\n\n def get_linker_so(self):\n # win32 linking should be handled by standard linker\n if sys.platform != 'win32':\n return [self.f77_compiler,'-shared']\n \n def f90_compile(self,source_files,module_files,temp_dir=''):\n raise DistutilsExecError, 'f90 not supported by Gnu'\n\n\n#http://developer.intel.com/software/products/compilers/f50/linux/\nclass intel_ia32_fortran_compiler(fortran_compiler_base):\n\n vendor = 'Intel' # Intel(R) Corporation \n ver_match = r'Intel\\(R\\) Fortran Compiler for 32-bit applications, Version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'ifc'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n switches = ' -KPIC '\n\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n if cpu.has_fdiv_bug():\n switches = switches + ' -fdiv_check '\n if cpu.has_f00f_bug():\n switches = switches + ' -0f_check '\n self.f77_switches = self.f90_switches = switches\n self.f77_switches = self.f77_switches + ' -FI '\n\n self.f77_opt = self.f90_opt = self.get_opt()\n \n debug = ' -g -C '\n self.f77_debug = self.f90_debug = debug\n\n self.ver_cmd = self.f77_compiler+' -FI -V -c %s -o %s' %\\\n self.dummy_fortran_files()\n\n def get_opt(self):\n import cpuinfo\n cpu = cpuinfo.cpuinfo()\n opt = ' -O3 '\n if cpu.is_PentiumPro() or cpu.is_PentiumII():\n opt = opt + ' -tpp6 -xi '\n elif cpu.is_PentiumIII():\n opt = opt + ' -tpp6 '\n elif cpu.is_Pentium():\n opt = opt + ' -tpp5 '\n elif cpu.is_PentiumIV():\n opt = opt + ' -tpp7 -xW '\n elif cpu.has_mmx():\n opt = opt + ' -xM '\n return opt\n \n\n def get_linker_so(self):\n return [self.f77_compiler,'-shared']\n\n\nclass intel_itanium_fortran_compiler(intel_ia32_fortran_compiler):\n\n vendor = 'Itanium'\n ver_match = r'Intel\\(R\\) Fortran 90 Compiler Itanium\\(TM\\) Compiler for the Itanium\\(TM\\)-based applications, Version (?P[^\\s*]*)'\n\n def __init__(self, fc = None, f90c = None):\n if fc is None:\n fc = 'efc'\n intel_ia32_fortran_compiler.__init__(self, fc, f90c)\n\n\nclass nag_fortran_compiler(fortran_compiler_base):\n\n vendor = 'NAG'\n ver_match = r'NAGWare Fortran 95 compiler Release (?P[^\\s]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'f95'\n if f90c is None:\n f90c = fc\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n switches = ''\n debug = ' -g -gline -g90 -nan -C '\n\n self.f77_switches = self.f90_switches = switches\n self.f77_switches = self.f77_switches + ' -fixed '\n self.f77_debug = self.f90_debug = debug\n self.f77_opt = self.f90_opt = self.get_opt()\n\n self.ver_cmd = self.f77_compiler+' -V '\n\n def get_opt(self):\n opt = ' -O4 -target=native '\n return opt\n\n def get_linker_so(self):\n return [self.f77_compiler,'-Wl,-shared']\n\n\nclass vast_fortran_compiler(fortran_compiler_base):\n\n vendor = 'VAST'\n ver_match = r'\\s*Pacific-Sierra Research vf90 (Personal|Professional)\\s+(?P[^\\s]*)'\n\n def __init__(self, fc = None, f90c = None):\n fortran_compiler_base.__init__(self)\n\n if fc is None:\n fc = 'g77'\n if f90c is None:\n f90c = 'f90'\n\n self.f77_compiler = fc\n self.f90_compiler = f90c\n\n d,b = os.path.split(f90c)\n vf90 = os.path.join(d,'v'+b)\n self.ver_cmd = vf90+' -v '\n\n gnu = gnu_fortran_compiler(fc)\n if not gnu.is_available(): # VAST compiler requires g77.\n self.version = ''\n return\n if not self.is_available():\n return\n\n self.f77_switches = gnu.f77_switches\n self.f77_debug = gnu.f77_debug\n self.f77_opt = gnu.f77_opt \n\n # XXX: need f90 switches, debug, opt\n\n def get_linker_so(self):\n return [self.f90_compiler,'-shared']\n\n\ndef match_extension(files,ext):\n match = re.compile(r'.*[.]('+ext+r')\\Z',re.I).match\n return filter(lambda x,match = match: match(x),files)\n\ndef get_f77_files(files):\n return match_extension(files,'for|f77|ftn|f')\n\ndef get_f90_files(files):\n return match_extension(files,'f90|f95')\n\ndef get_fortran_files(files):\n return match_extension(files,'f90|f95|for|f77|ftn|f')\n\ndef find_fortran_compiler(vendor = None, fc = None, f90c = None):\n fcompiler = None\n for compiler_class in all_compilers:\n if vendor is not None and vendor != compiler_class.vendor:\n continue\n print compiler_class\n compiler = compiler_class(fc,f90c)\n if compiler.is_available():\n fcompiler = compiler\n break\n return fcompiler\n\nall_compilers = [absoft_fortran_compiler,\n mips_fortran_compiler,\n sun_fortran_compiler,\n gnu_fortran_compiler,\n intel_ia32_fortran_compiler,\n intel_itanium_fortran_compiler,\n nag_fortran_compiler,\n vast_fortran_compiler,\n ]\n\nif __name__ == \"__main__\":\n show_compilers()\n", "methods": [ { "name": "run_command", "long_name": "run_command( command )", "filename": "build_flib.py", "nloc": 5, "complexity": 1, "token_count": 32, "parameters": [ "command" ], "start_line": 56, "end_line": 61, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "show_compilers", "long_name": "show_compilers( )", "filename": "build_flib.py", "nloc": 5, "complexity": 3, "token_count": 23, "parameters": [], "start_line": 65, "end_line": 69, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 }, { "name": "initialize_options", "long_name": "initialize_options( self )", "filename": "build_flib.py", "nloc": 11, "complexity": 1, "token_count": 55, "parameters": [ "self" ], "start_line": 99, "end_line": 111, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "finalize_options", "long_name": "finalize_options( self )", "filename": "build_flib.py", "nloc": 17, "complexity": 3, "token_count": 104, "parameters": [ "self" ], "start_line": 115, "end_line": 131, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 1 }, { "name": "has_f_libraries", "long_name": "has_f_libraries( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 135, "end_line": 136, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "run", "long_name": "run( self )", "filename": "build_flib.py", "nloc": 4, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 138, "end_line": 141, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "get_library_names", "long_name": "get_library_names( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 4, "token_count": 58, "parameters": [ "self" ], "start_line": 145, "end_line": 157, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "get_library_dirs", "long_name": "get_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 42, "parameters": [ "self" ], "start_line": 161, "end_line": 170, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 42, "parameters": [ "self" ], "start_line": 174, "end_line": 183, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_source_files", "long_name": "get_source_files( self )", "filename": "build_flib.py", "nloc": 6, "complexity": 2, "token_count": 38, "parameters": [ "self" ], "start_line": 187, "end_line": 195, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "build_libraries", "long_name": "build_libraries( self , fortran_libraries )", "filename": "build_flib.py", "nloc": 18, "complexity": 5, "token_count": 122, "parameters": [ "self", "fortran_libraries" ], "start_line": 197, "end_line": 218, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self )", "filename": "build_flib.py", "nloc": 16, "complexity": 3, "token_count": 88, "parameters": [ "self" ], "start_line": 230, "end_line": 251, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "to_object", "long_name": "to_object( self , dirty_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 13, "complexity": 3, "token_count": 89, "parameters": [ "self", "dirty_files", "module_dirs", "temp_dir" ], "start_line": 253, "end_line": 265, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "source_to_object_names", "long_name": "source_to_object_names( self , source_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 6, "complexity": 1, "token_count": 89, "parameters": [ "self", "source_files", "temp_dir" ], "start_line": 267, "end_line": 272, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "source_and_object_pairs", "long_name": "source_and_object_pairs( self , source_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 31, "parameters": [ "self", "source_files", "temp_dir" ], "start_line": 274, "end_line": 277, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f_compile", "long_name": "f_compile( self , compiler , switches , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 15, "complexity": 4, "token_count": 103, "parameters": [ "self", "compiler", "switches", "source_files", "module_dirs", "temp_dir" ], "start_line": 279, "end_line": 293, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "f90_compile", "long_name": "f90_compile( self , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 48, "parameters": [ "self", "source_files", "module_dirs", "temp_dir" ], "start_line": 297, "end_line": 300, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f77_compile", "long_name": "f77_compile( self , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 48, "parameters": [ "self", "source_files", "module_dirs", "temp_dir" ], "start_line": 302, "end_line": 305, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self", "module_dirs" ], "start_line": 308, "end_line": 309, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "create_static_lib", "long_name": "create_static_lib( self , object_files , library_name , output_dir = '' , debug = None )", "filename": "build_flib.py", "nloc": 9, "complexity": 2, "token_count": 68, "parameters": [ "self", "object_files", "library_name", "output_dir", "debug" ], "start_line": 311, "end_line": 322, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 12, "top_nesting_level": 1 }, { "name": "build_library", "long_name": "build_library( self , library_name , source_list , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 10, "complexity": 2, "token_count": 85, "parameters": [ "self", "library_name", "source_list", "module_dirs", "temp_dir" ], "start_line": 324, "end_line": 345, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "dummy_fortran_files", "long_name": "dummy_fortran_files( self )", "filename": "build_flib.py", "nloc": 8, "complexity": 1, "token_count": 69, "parameters": [ "self" ], "start_line": 347, "end_line": 354, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "is_available", "long_name": "is_available( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 356, "end_line": 357, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_version", "long_name": "get_version( self )", "filename": "build_flib.py", "nloc": 10, "complexity": 4, "token_count": 66, "parameters": [ "self" ], "start_line": 359, "end_line": 377, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "get_libraries", "long_name": "get_libraries( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 379, "end_line": 380, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_library_dirs", "long_name": "get_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 381, "end_line": 382, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 383, "end_line": 384, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 385, "end_line": 386, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 1, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 387, "end_line": 392, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "__str__", "long_name": "__str__( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self" ], "start_line": 394, "end_line": 395, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 31, "complexity": 5, "token_count": 177, "parameters": [ "self", "fc", "f90c" ], "start_line": 403, "end_line": 441, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 39, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 6, "complexity": 3, "token_count": 27, "parameters": [ "self", "module_dirs" ], "start_line": 443, "end_line": 448, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 450, "end_line": 451, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 98, "parameters": [ "self", "fc", "f90c" ], "start_line": 464, "end_line": 486, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 6, "complexity": 3, "token_count": 27, "parameters": [ "self", "module_dirs" ], "start_line": 488, "end_line": 493, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "find_lib_dir", "long_name": "find_lib_dir( self )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 99, "parameters": [ "self" ], "start_line": 495, "end_line": 509, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 510, "end_line": 511, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 512, "end_line": 513, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 94, "parameters": [ "self", "fc", "f90c" ], "start_line": 521, "end_line": 539, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 12, "parameters": [ "self", "module_dirs" ], "start_line": 541, "end_line": 543, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "find_lib_dir", "long_name": "find_lib_dir( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 544, "end_line": 546, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 547, "end_line": 548, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 549, "end_line": 550, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 16, "complexity": 5, "token_count": 103, "parameters": [ "self", "fc", "f90c" ], "start_line": 558, "end_line": 579, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 21, "complexity": 10, "token_count": 120, "parameters": [ "self" ], "start_line": 581, "end_line": 604, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 24, "top_nesting_level": 1 }, { "name": "find_lib_directories", "long_name": "find_lib_directories( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 3, "token_count": 43, "parameters": [ "self" ], "start_line": 606, "end_line": 616, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 2, "token_count": 20, "parameters": [ "self" ], "start_line": 618, "end_line": 621, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f90_compile", "long_name": "f90_compile( self , source_files , module_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self", "source_files", "module_files", "temp_dir" ], "start_line": 623, "end_line": 624, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 22, "complexity": 5, "token_count": 140, "parameters": [ "self", "fc", "f90c" ], "start_line": 633, "end_line": 661, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 29, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 15, "complexity": 7, "token_count": 85, "parameters": [ "self" ], "start_line": 663, "end_line": 677, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 680, "end_line": 681, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 4, "complexity": 2, "token_count": 31, "parameters": [ "self", "fc", "f90c" ], "start_line": 689, "end_line": 692, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 100, "parameters": [ "self", "fc", "f90c" ], "start_line": 700, "end_line": 719, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 721, "end_line": 723, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 725, "end_line": 726, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 20, "complexity": 5, "token_count": 128, "parameters": [ "self", "fc", "f90c" ], "start_line": 734, "end_line": 758, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 762, "end_line": 763, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 14, "complexity": 3, "token_count": 91, "parameters": [ "self", "fc", "f90c" ], "start_line": 770, "end_line": 792, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 794, "end_line": 796, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 798, "end_line": 800, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "match_extension", "long_name": "match_extension( files , ext )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 44, "parameters": [ "files", "ext" ], "start_line": 803, "end_line": 805, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "get_f77_files", "long_name": "get_f77_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 807, "end_line": 808, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "get_f90_files", "long_name": "get_f90_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 810, "end_line": 811, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "get_fortran_files", "long_name": "get_fortran_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 813, "end_line": 814, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "find_fortran_compiler", "long_name": "find_fortran_compiler( vendor = None , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 11, "complexity": 5, "token_count": 59, "parameters": [ "vendor", "fc", "f90c" ], "start_line": 816, "end_line": 826, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 } ], "methods_before": [ { "name": "run_command", "long_name": "run_command( command )", "filename": "build_flib.py", "nloc": 5, "complexity": 1, "token_count": 32, "parameters": [ "command" ], "start_line": 55, "end_line": 60, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "show_compilers", "long_name": "show_compilers( )", "filename": "build_flib.py", "nloc": 5, "complexity": 3, "token_count": 23, "parameters": [], "start_line": 64, "end_line": 68, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 }, { "name": "initialize_options", "long_name": "initialize_options( self )", "filename": "build_flib.py", "nloc": 11, "complexity": 1, "token_count": 55, "parameters": [ "self" ], "start_line": 98, "end_line": 110, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "finalize_options", "long_name": "finalize_options( self )", "filename": "build_flib.py", "nloc": 17, "complexity": 3, "token_count": 104, "parameters": [ "self" ], "start_line": 114, "end_line": 130, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 1 }, { "name": "has_f_libraries", "long_name": "has_f_libraries( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 134, "end_line": 135, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "run", "long_name": "run( self )", "filename": "build_flib.py", "nloc": 4, "complexity": 2, "token_count": 22, "parameters": [ "self" ], "start_line": 137, "end_line": 140, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "get_library_names", "long_name": "get_library_names( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 4, "token_count": 58, "parameters": [ "self" ], "start_line": 144, "end_line": 156, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "get_library_dirs", "long_name": "get_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 42, "parameters": [ "self" ], "start_line": 160, "end_line": 169, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 7, "complexity": 3, "token_count": 42, "parameters": [ "self" ], "start_line": 173, "end_line": 182, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_source_files", "long_name": "get_source_files( self )", "filename": "build_flib.py", "nloc": 6, "complexity": 2, "token_count": 38, "parameters": [ "self" ], "start_line": 186, "end_line": 194, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "build_libraries", "long_name": "build_libraries( self , fortran_libraries )", "filename": "build_flib.py", "nloc": 18, "complexity": 5, "token_count": 122, "parameters": [ "self", "fortran_libraries" ], "start_line": 196, "end_line": 217, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self )", "filename": "build_flib.py", "nloc": 16, "complexity": 3, "token_count": 88, "parameters": [ "self" ], "start_line": 229, "end_line": 250, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "to_object", "long_name": "to_object( self , dirty_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 13, "complexity": 3, "token_count": 89, "parameters": [ "self", "dirty_files", "module_dirs", "temp_dir" ], "start_line": 252, "end_line": 264, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "source_to_object_names", "long_name": "source_to_object_names( self , source_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 6, "complexity": 1, "token_count": 89, "parameters": [ "self", "source_files", "temp_dir" ], "start_line": 266, "end_line": 271, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "source_and_object_pairs", "long_name": "source_and_object_pairs( self , source_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 31, "parameters": [ "self", "source_files", "temp_dir" ], "start_line": 273, "end_line": 276, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f_compile", "long_name": "f_compile( self , compiler , switches , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 15, "complexity": 4, "token_count": 103, "parameters": [ "self", "compiler", "switches", "source_files", "module_dirs", "temp_dir" ], "start_line": 278, "end_line": 292, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "f90_compile", "long_name": "f90_compile( self , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 48, "parameters": [ "self", "source_files", "module_dirs", "temp_dir" ], "start_line": 296, "end_line": 299, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f77_compile", "long_name": "f77_compile( self , source_files , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 4, "complexity": 1, "token_count": 48, "parameters": [ "self", "source_files", "module_dirs", "temp_dir" ], "start_line": 301, "end_line": 304, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self", "module_dirs" ], "start_line": 307, "end_line": 308, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "create_static_lib", "long_name": "create_static_lib( self , object_files , library_name , output_dir = '' , debug = None )", "filename": "build_flib.py", "nloc": 9, "complexity": 2, "token_count": 68, "parameters": [ "self", "object_files", "library_name", "output_dir", "debug" ], "start_line": 310, "end_line": 321, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 12, "top_nesting_level": 1 }, { "name": "build_library", "long_name": "build_library( self , library_name , source_list , module_dirs = None , temp_dir = '' )", "filename": "build_flib.py", "nloc": 10, "complexity": 2, "token_count": 85, "parameters": [ "self", "library_name", "source_list", "module_dirs", "temp_dir" ], "start_line": 323, "end_line": 344, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "dummy_fortran_files", "long_name": "dummy_fortran_files( self )", "filename": "build_flib.py", "nloc": 8, "complexity": 1, "token_count": 69, "parameters": [ "self" ], "start_line": 346, "end_line": 353, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "is_available", "long_name": "is_available( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 355, "end_line": 356, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_version", "long_name": "get_version( self )", "filename": "build_flib.py", "nloc": 10, "complexity": 4, "token_count": 66, "parameters": [ "self" ], "start_line": 358, "end_line": 376, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "get_libraries", "long_name": "get_libraries( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 378, "end_line": 379, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_library_dirs", "long_name": "get_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 380, "end_line": 381, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 382, "end_line": 383, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 384, "end_line": 385, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 1, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 386, "end_line": 391, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "__str__", "long_name": "__str__( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self" ], "start_line": 393, "end_line": 394, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 31, "complexity": 5, "token_count": 177, "parameters": [ "self", "fc", "f90c" ], "start_line": 402, "end_line": 440, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 39, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 6, "complexity": 3, "token_count": 27, "parameters": [ "self", "module_dirs" ], "start_line": 442, "end_line": 447, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 449, "end_line": 450, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 98, "parameters": [ "self", "fc", "f90c" ], "start_line": 463, "end_line": 485, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 6, "complexity": 3, "token_count": 27, "parameters": [ "self", "module_dirs" ], "start_line": 487, "end_line": 492, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "find_lib_dir", "long_name": "find_lib_dir( self )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 99, "parameters": [ "self" ], "start_line": 494, "end_line": 508, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 509, "end_line": 510, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [ "self" ], "start_line": 511, "end_line": 512, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 94, "parameters": [ "self", "fc", "f90c" ], "start_line": 520, "end_line": 538, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 1 }, { "name": "build_module_switch", "long_name": "build_module_switch( self , module_dirs )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 12, "parameters": [ "self", "module_dirs" ], "start_line": 540, "end_line": 542, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "find_lib_dir", "long_name": "find_lib_dir( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 543, "end_line": 545, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "get_runtime_library_dirs", "long_name": "get_runtime_library_dirs( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 546, "end_line": 547, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "get_extra_link_args", "long_name": "get_extra_link_args( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 548, "end_line": 549, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 16, "complexity": 5, "token_count": 103, "parameters": [ "self", "fc", "f90c" ], "start_line": 557, "end_line": 578, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 21, "complexity": 10, "token_count": 120, "parameters": [ "self" ], "start_line": 580, "end_line": 603, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 24, "top_nesting_level": 1 }, { "name": "find_lib_directories", "long_name": "find_lib_directories( self )", "filename": "build_flib.py", "nloc": 9, "complexity": 3, "token_count": 43, "parameters": [ "self" ], "start_line": 605, "end_line": 615, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 2, "token_count": 20, "parameters": [ "self" ], "start_line": 617, "end_line": 620, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "f90_compile", "long_name": "f90_compile( self , source_files , module_files , temp_dir = '' )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 17, "parameters": [ "self", "source_files", "module_files", "temp_dir" ], "start_line": 622, "end_line": 623, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 22, "complexity": 5, "token_count": 140, "parameters": [ "self", "fc", "f90c" ], "start_line": 632, "end_line": 660, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 29, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 15, "complexity": 7, "token_count": 85, "parameters": [ "self" ], "start_line": 662, "end_line": 676, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 679, "end_line": 680, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 4, "complexity": 2, "token_count": 31, "parameters": [ "self", "fc", "f90c" ], "start_line": 688, "end_line": 691, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 15, "complexity": 3, "token_count": 100, "parameters": [ "self", "fc", "f90c" ], "start_line": 699, "end_line": 718, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 720, "end_line": 722, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 724, "end_line": 725, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 20, "complexity": 5, "token_count": 128, "parameters": [ "self", "fc", "f90c" ], "start_line": 733, "end_line": 757, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 1 }, { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 761, "end_line": 762, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "match_extension", "long_name": "match_extension( files , ext )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 44, "parameters": [ "files", "ext" ], "start_line": 765, "end_line": 767, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "get_f77_files", "long_name": "get_f77_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 769, "end_line": 770, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "get_f90_files", "long_name": "get_f90_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 772, "end_line": 773, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "get_fortran_files", "long_name": "get_fortran_files( files )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "files" ], "start_line": 775, "end_line": 776, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "find_fortran_compiler", "long_name": "find_fortran_compiler( vendor = None , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 11, "complexity": 5, "token_count": 59, "parameters": [ "vendor", "fc", "f90c" ], "start_line": 778, "end_line": 788, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "get_linker_so", "long_name": "get_linker_so( self )", "filename": "build_flib.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self" ], "start_line": 798, "end_line": 800, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "get_opt", "long_name": "get_opt( self )", "filename": "build_flib.py", "nloc": 3, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 794, "end_line": 796, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "__init__", "long_name": "__init__( self , fc = None , f90c = None )", "filename": "build_flib.py", "nloc": 14, "complexity": 3, "token_count": 91, "parameters": [ "self", "fc", "f90c" ], "start_line": 770, "end_line": 792, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 } ], "nloc": 604, "complexity": 147, "token_count": 3459, "diff_parsed": { "added": [ " Compaq", " Gnu", "class compaq_fortran_compiler(fortran_compiler_base):", "", " vendor = 'Compaq'", " ver_match = r'Compaq Fortran (?P[^\\s]*)'", "", " def __init__(self, fc = None, f90c = None):", " fortran_compiler_base.__init__(self)", "", " if fc is None:", " fc = 'fort'", " if f90c is None:", " f90c = fc", "", " self.f77_compiler = fc", " self.f90_compiler = f90c", "", " switches = ' -assume no2underscore -nomixed_str_len_arg '", " debug = ' -g -check_bounds '", "", " self.f77_switches = self.f90_switches = switches", " self.f77_debug = self.f90_debug = debug", " self.f77_opt = self.f90_opt = self.get_opt()", "", " # XXX: uncomment if required", " #self.libraries = ' -lUfor -lfor -lFutil -lcpml -lots -lc '", "", " # XXX: fix the version showing flag", " self.ver_cmd = self.f77_compiler+' -V '", "", " def get_opt(self):", " opt = ' -O4 -align dcommons -arch host -assume bigarrays -assume nozsize -math_library fast -tune host '", " return opt", "", " def get_linker_so(self):", " # XXX: is -shared needed?", " return [self.f77_compiler,'-shared']", "", " compaq_fortran_compiler,", " gnu_fortran_compiler," ], "deleted": [ " Gnu", " gnu_fortran_compiler," ] } }, { "old_path": "scipy_distutils/misc_util.py", "new_path": "scipy_distutils/misc_util.py", "filename": "misc_util.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -1,4 +1,36 @@\n-import os,sys\n+import os,sys,string\n+\n+def get_version(major,minor,path = '.'):\n+ \"\"\"\n+ Return a version string calculated from a CVS tree starting at\n+ path. The micro version number is found as a sum of the last bits\n+ of the revision numbers listed in CVS/Entries. If /CVS does\n+ not exists, get_version tries to get the version from the\n+ /__version__.py file where __version__ variable should be\n+ defined. If that also fails, then return None.\n+ \"\"\"\n+ micro = get_micro_version(os.path.abspath(path))\n+ if micro is None:\n+ try:\n+ return __import__(os.path.join(path,'__version__.py')).__version__\n+ except:\n+ return\n+ return '%s.%s.%s'%(major,minor,micro)\n+\n+def get_micro_version(path):\n+ # micro version number should be increasing in time, unless a file\n+ # is removed from the CVS source tree. In that case one should\n+ # increase the minor version number.\n+ entries_file = os.path.join(path,'CVS','Entries')\n+ if os.path.exists(entries_file):\n+ micro = 0\n+ for line in open(entries_file).readlines():\n+ items = string.split(line,'/')\n+ if items[0] == 'D' and len(items)>1:\n+ micro = micro + get_micro_version(os.path.join(path,items[1]))\n+ elif items[0] == '' and len(items)>2:\n+ micro = micro + eval(string.split(items[2],'.')[-1])\n+ return micro\n \n def get_path(mod_name):\n \"\"\" This function makes sure installation is done from the\n@@ -90,4 +122,4 @@ def merge_config_dicts(config_list):\n result[key].extend(d.get(key,[]))\n for key in dict_keys:\n result[key].update(d.get(key,{}))\n- return result\n\\ No newline at end of file\n+ return result\n", "added_lines": 34, "deleted_lines": 2, "source_code": "import os,sys,string\n\ndef get_version(major,minor,path = '.'):\n \"\"\"\n Return a version string calculated from a CVS tree starting at\n path. The micro version number is found as a sum of the last bits\n of the revision numbers listed in CVS/Entries. If /CVS does\n not exists, get_version tries to get the version from the\n /__version__.py file where __version__ variable should be\n defined. If that also fails, then return None.\n \"\"\"\n micro = get_micro_version(os.path.abspath(path))\n if micro is None:\n try:\n return __import__(os.path.join(path,'__version__.py')).__version__\n except:\n return\n return '%s.%s.%s'%(major,minor,micro)\n\ndef get_micro_version(path):\n # micro version number should be increasing in time, unless a file\n # is removed from the CVS source tree. In that case one should\n # increase the minor version number.\n entries_file = os.path.join(path,'CVS','Entries')\n if os.path.exists(entries_file):\n micro = 0\n for line in open(entries_file).readlines():\n items = string.split(line,'/')\n if items[0] == 'D' and len(items)>1:\n micro = micro + get_micro_version(os.path.join(path,items[1]))\n elif items[0] == '' and len(items)>2:\n micro = micro + eval(string.split(items[2],'.')[-1])\n return micro\n\ndef get_path(mod_name):\n \"\"\" This function makes sure installation is done from the\n correct directory no matter if it is installed from the\n command line or from another package or run_setup function.\n \n \"\"\"\n if mod_name == '__main__':\n d = os.path.abspath('.')\n elif mod_name == '__builtin__':\n #builtin if/then added by Pearu for use in core.run_setup. \n d = os.path.dirname(os.path.abspath(sys.argv[0]))\n else:\n #import scipy_distutils.setup\n mod = __import__(mod_name)\n file = mod.__file__\n d = os.path.dirname(os.path.abspath(file))\n return d\n \ndef add_local_to_path(mod_name):\n local_path = get_path(mod_name)\n sys.path.insert(0,local_path)\n \ndef add_grandparent_to_path(mod_name):\n local_path = get_path(mod_name)\n gp_dir = os.path.split(local_path)[0]\n sys.path.insert(0,gp_dir)\n\ndef restore_path():\n del sys.path[0]\n\ndef append_package_dir_to_path(package_name): \n \"\"\" Search for a directory with package_name and append it to PYTHONPATH\n \n The local directory is searched first and then the parent directory.\n \"\"\"\n # first see if it is in the current path\n # then try parent. If it isn't found, fail silently\n # and let the import error occur.\n \n # not an easy way to clean up after this...\n import os,sys\n if os.path.exists(package_name):\n sys.path.append(package_name)\n elif os.path.exists(os.path.join('..',package_name)):\n sys.path.append(os.path.join('..',package_name))\n\ndef get_package_config(package_name):\n \"\"\" grab the configuration info from the setup_xxx.py file\n in a package directory. The package directory is searched\n from the current directory, so setting the path to the\n setup.py file directory of the file calling this is usually\n needed to get search the path correct.\n \"\"\"\n append_package_dir_to_path(package_name)\n mod = __import__('setup_'+package_name)\n config = mod.configuration()\n return config\n\ndef package_config(primary,dependencies=[]):\n \"\"\" Create a configuration dictionary ready for setup.py from\n a list of primary and dependent package names. Each\n package listed must have a directory with the same name\n in the current or parent working directory. Further, it\n should have a setup_xxx.py module within that directory that\n has a configuration() file in it. \n \"\"\"\n config = []\n config.extend([get_package_config(x) for x in primary])\n config.extend([get_package_config(x) for x in dependencies]) \n config_dict = merge_config_dicts(config)\n return config_dict\n \nlist_keys = ['packages', 'ext_modules', 'data_files',\n 'include_dirs', 'libraries', 'fortran_libraries',\n 'headers']\ndict_keys = ['package_dir'] \n\ndef default_config_dict():\n d={}\n for key in list_keys: d[key] = []\n for key in dict_keys: d[key] = {}\n return d\n\ndef merge_config_dicts(config_list):\n result = default_config_dict() \n for d in config_list:\n for key in list_keys:\n result[key].extend(d.get(key,[]))\n for key in dict_keys:\n result[key].update(d.get(key,{}))\n return result\n", "source_code_before": "import os,sys\n\ndef get_path(mod_name):\n \"\"\" This function makes sure installation is done from the\n correct directory no matter if it is installed from the\n command line or from another package or run_setup function.\n \n \"\"\"\n if mod_name == '__main__':\n d = os.path.abspath('.')\n elif mod_name == '__builtin__':\n #builtin if/then added by Pearu for use in core.run_setup. \n d = os.path.dirname(os.path.abspath(sys.argv[0]))\n else:\n #import scipy_distutils.setup\n mod = __import__(mod_name)\n file = mod.__file__\n d = os.path.dirname(os.path.abspath(file))\n return d\n \ndef add_local_to_path(mod_name):\n local_path = get_path(mod_name)\n sys.path.insert(0,local_path)\n \ndef add_grandparent_to_path(mod_name):\n local_path = get_path(mod_name)\n gp_dir = os.path.split(local_path)[0]\n sys.path.insert(0,gp_dir)\n\ndef restore_path():\n del sys.path[0]\n\ndef append_package_dir_to_path(package_name): \n \"\"\" Search for a directory with package_name and append it to PYTHONPATH\n \n The local directory is searched first and then the parent directory.\n \"\"\"\n # first see if it is in the current path\n # then try parent. If it isn't found, fail silently\n # and let the import error occur.\n \n # not an easy way to clean up after this...\n import os,sys\n if os.path.exists(package_name):\n sys.path.append(package_name)\n elif os.path.exists(os.path.join('..',package_name)):\n sys.path.append(os.path.join('..',package_name))\n\ndef get_package_config(package_name):\n \"\"\" grab the configuration info from the setup_xxx.py file\n in a package directory. The package directory is searched\n from the current directory, so setting the path to the\n setup.py file directory of the file calling this is usually\n needed to get search the path correct.\n \"\"\"\n append_package_dir_to_path(package_name)\n mod = __import__('setup_'+package_name)\n config = mod.configuration()\n return config\n\ndef package_config(primary,dependencies=[]):\n \"\"\" Create a configuration dictionary ready for setup.py from\n a list of primary and dependent package names. Each\n package listed must have a directory with the same name\n in the current or parent working directory. Further, it\n should have a setup_xxx.py module within that directory that\n has a configuration() file in it. \n \"\"\"\n config = []\n config.extend([get_package_config(x) for x in primary])\n config.extend([get_package_config(x) for x in dependencies]) \n config_dict = merge_config_dicts(config)\n return config_dict\n \nlist_keys = ['packages', 'ext_modules', 'data_files',\n 'include_dirs', 'libraries', 'fortran_libraries',\n 'headers']\ndict_keys = ['package_dir'] \n\ndef default_config_dict():\n d={}\n for key in list_keys: d[key] = []\n for key in dict_keys: d[key] = {}\n return d\n\ndef merge_config_dicts(config_list):\n result = default_config_dict() \n for d in config_list:\n for key in list_keys:\n result[key].extend(d.get(key,[]))\n for key in dict_keys:\n result[key].update(d.get(key,{}))\n return result", "methods": [ { "name": "get_version", "long_name": "get_version( major , minor , path = '.' )", "filename": "misc_util.py", "nloc": 8, "complexity": 3, "token_count": 61, "parameters": [ "major", "minor", "path" ], "start_line": 3, "end_line": 18, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 0 }, { "name": "get_micro_version", "long_name": "get_micro_version( path )", "filename": "misc_util.py", "nloc": 11, "complexity": 7, "token_count": 128, "parameters": [ "path" ], "start_line": 20, "end_line": 33, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 0 }, { "name": "get_path", "long_name": "get_path( mod_name )", "filename": "misc_util.py", "nloc": 10, "complexity": 3, "token_count": 80, "parameters": [ "mod_name" ], "start_line": 35, "end_line": 51, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 0 }, { "name": "add_local_to_path", "long_name": "add_local_to_path( mod_name )", "filename": "misc_util.py", "nloc": 3, "complexity": 1, "token_count": 21, "parameters": [ "mod_name" ], "start_line": 53, "end_line": 55, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "add_grandparent_to_path", "long_name": "add_grandparent_to_path( mod_name )", "filename": "misc_util.py", "nloc": 4, "complexity": 1, "token_count": 34, "parameters": [ "mod_name" ], "start_line": 57, "end_line": 60, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 0 }, { "name": "restore_path", "long_name": "restore_path( )", "filename": "misc_util.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [], "start_line": 62, "end_line": 63, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "append_package_dir_to_path", "long_name": "append_package_dir_to_path( package_name )", "filename": "misc_util.py", "nloc": 6, "complexity": 3, "token_count": 64, "parameters": [ "package_name" ], "start_line": 65, "end_line": 79, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "get_package_config", "long_name": "get_package_config( package_name )", "filename": "misc_util.py", "nloc": 5, "complexity": 1, "token_count": 27, "parameters": [ "package_name" ], "start_line": 81, "end_line": 91, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 }, { "name": "package_config", "long_name": "package_config( primary , dependencies = [ ] )", "filename": "misc_util.py", "nloc": 6, "complexity": 3, "token_count": 53, "parameters": [ "primary", "dependencies" ], "start_line": 93, "end_line": 105, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 0 }, { "name": "default_config_dict", "long_name": "default_config_dict( )", "filename": "misc_util.py", "nloc": 5, "complexity": 3, "token_count": 34, "parameters": [], "start_line": 112, "end_line": 116, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 }, { "name": "merge_config_dicts", "long_name": "merge_config_dicts( config_list )", "filename": "misc_util.py", "nloc": 8, "complexity": 4, "token_count": 61, "parameters": [ "config_list" ], "start_line": 118, "end_line": 125, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 0 } ], "methods_before": [ { "name": "get_path", "long_name": "get_path( mod_name )", "filename": "misc_util.py", "nloc": 10, "complexity": 3, "token_count": 80, "parameters": [ "mod_name" ], "start_line": 3, "end_line": 19, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 0 }, { "name": "add_local_to_path", "long_name": "add_local_to_path( mod_name )", "filename": "misc_util.py", "nloc": 3, "complexity": 1, "token_count": 21, "parameters": [ "mod_name" ], "start_line": 21, "end_line": 23, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "add_grandparent_to_path", "long_name": "add_grandparent_to_path( mod_name )", "filename": "misc_util.py", "nloc": 4, "complexity": 1, "token_count": 34, "parameters": [ "mod_name" ], "start_line": 25, "end_line": 28, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 0 }, { "name": "restore_path", "long_name": "restore_path( )", "filename": "misc_util.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [], "start_line": 30, "end_line": 31, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "append_package_dir_to_path", "long_name": "append_package_dir_to_path( package_name )", "filename": "misc_util.py", "nloc": 6, "complexity": 3, "token_count": 64, "parameters": [ "package_name" ], "start_line": 33, "end_line": 47, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "get_package_config", "long_name": "get_package_config( package_name )", "filename": "misc_util.py", "nloc": 5, "complexity": 1, "token_count": 27, "parameters": [ "package_name" ], "start_line": 49, "end_line": 59, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 }, { "name": "package_config", "long_name": "package_config( primary , dependencies = [ ] )", "filename": "misc_util.py", "nloc": 6, "complexity": 3, "token_count": 53, "parameters": [ "primary", "dependencies" ], "start_line": 61, "end_line": 73, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 0 }, { "name": "default_config_dict", "long_name": "default_config_dict( )", "filename": "misc_util.py", "nloc": 5, "complexity": 3, "token_count": 34, "parameters": [], "start_line": 80, "end_line": 84, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 }, { "name": "merge_config_dicts", "long_name": "merge_config_dicts( config_list )", "filename": "misc_util.py", "nloc": 8, "complexity": 4, "token_count": 61, "parameters": [ "config_list" ], "start_line": 86, "end_line": 93, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "merge_config_dicts", "long_name": "merge_config_dicts( config_list )", "filename": "misc_util.py", "nloc": 8, "complexity": 4, "token_count": 61, "parameters": [ "config_list" ], "start_line": 118, "end_line": 125, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 0 }, { "name": "get_version", "long_name": "get_version( major , minor , path = '.' )", "filename": "misc_util.py", "nloc": 8, "complexity": 3, "token_count": 61, "parameters": [ "major", "minor", "path" ], "start_line": 3, "end_line": 18, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 0 }, { "name": "get_micro_version", "long_name": "get_micro_version( path )", "filename": "misc_util.py", "nloc": 11, "complexity": 7, "token_count": 128, "parameters": [ "path" ], "start_line": 20, "end_line": 33, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 0 } ], "nloc": 73, "complexity": 30, "token_count": 613, "diff_parsed": { "added": [ "import os,sys,string", "", "def get_version(major,minor,path = '.'):", " \"\"\"", " Return a version string calculated from a CVS tree starting at", " path. The micro version number is found as a sum of the last bits", " of the revision numbers listed in CVS/Entries. If /CVS does", " not exists, get_version tries to get the version from the", " /__version__.py file where __version__ variable should be", " defined. If that also fails, then return None.", " \"\"\"", " micro = get_micro_version(os.path.abspath(path))", " if micro is None:", " try:", " return __import__(os.path.join(path,'__version__.py')).__version__", " except:", " return", " return '%s.%s.%s'%(major,minor,micro)", "", "def get_micro_version(path):", " # micro version number should be increasing in time, unless a file", " # is removed from the CVS source tree. In that case one should", " # increase the minor version number.", " entries_file = os.path.join(path,'CVS','Entries')", " if os.path.exists(entries_file):", " micro = 0", " for line in open(entries_file).readlines():", " items = string.split(line,'/')", " if items[0] == 'D' and len(items)>1:", " micro = micro + get_micro_version(os.path.join(path,items[1]))", " elif items[0] == '' and len(items)>2:", " micro = micro + eval(string.split(items[2],'.')[-1])", " return micro", " return result" ], "deleted": [ "import os,sys", " return result" ] } }, { "old_path": "scipy_distutils/setup.py", "new_path": "scipy_distutils/setup.py", "filename": "setup.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -1,8 +1,9 @@\n #!/usr/bin/env python\n import os\n+\n from distutils.core import setup\n-from misc_util import get_path \n- \n+from misc_util import get_path, get_version\n+\n def install_package():\n \"\"\" Install the scipy_distutils. The dance with the current directory is done\n to fool distutils into thinking it is run from the scipy_distutils directory\n@@ -12,10 +13,18 @@ def install_package():\n old_path = os.getcwd()\n os.chdir(path)\n try:\n+\n+ version = get_version(0,2)\n+ print 'scipy_distutils',version\n+ version_file = open('__version__.py','w')\n+ version_file.write('__version__ = %s\\n'%(repr(version)))\n+ version_file.close()\n+\n setup (name = \"scipy_distutils\",\n- version = \"0.2\",\n+ version = version,\n description = \"Changes to distutils needed for SciPy -- mostly Fortran support\",\n author = \"Travis Oliphant, Eric Jones, and Pearu Peterson\",\n+ author_email = \"scipy-devel@scipy.org\",\n licence = \"BSD Style\",\n url = 'http://www.scipy.org',\n packages = ['scipy_distutils','scipy_distutils.command'],\n", "added_lines": 12, "deleted_lines": 3, "source_code": "#!/usr/bin/env python\nimport os\n\nfrom distutils.core import setup\nfrom misc_util import get_path, get_version\n\ndef install_package():\n \"\"\" Install the scipy_distutils. The dance with the current directory is done\n to fool distutils into thinking it is run from the scipy_distutils directory\n even if it was invoked from another script located in a different location.\n \"\"\"\n path = get_path(__name__)\n old_path = os.getcwd()\n os.chdir(path)\n try:\n\n version = get_version(0,2)\n print 'scipy_distutils',version\n version_file = open('__version__.py','w')\n version_file.write('__version__ = %s\\n'%(repr(version)))\n version_file.close()\n\n setup (name = \"scipy_distutils\",\n version = version,\n description = \"Changes to distutils needed for SciPy -- mostly Fortran support\",\n author = \"Travis Oliphant, Eric Jones, and Pearu Peterson\",\n author_email = \"scipy-devel@scipy.org\",\n licence = \"BSD Style\",\n url = 'http://www.scipy.org',\n packages = ['scipy_distutils','scipy_distutils.command'],\n package_dir = {'scipy_distutils':path}\n )\n finally:\n os.chdir(old_path)\n \nif __name__ == '__main__':\n install_package()\n", "source_code_before": "#!/usr/bin/env python\nimport os\nfrom distutils.core import setup\nfrom misc_util import get_path \n \ndef install_package():\n \"\"\" Install the scipy_distutils. The dance with the current directory is done\n to fool distutils into thinking it is run from the scipy_distutils directory\n even if it was invoked from another script located in a different location.\n \"\"\"\n path = get_path(__name__)\n old_path = os.getcwd()\n os.chdir(path)\n try:\n setup (name = \"scipy_distutils\",\n version = \"0.2\",\n description = \"Changes to distutils needed for SciPy -- mostly Fortran support\",\n author = \"Travis Oliphant, Eric Jones, and Pearu Peterson\",\n licence = \"BSD Style\",\n url = 'http://www.scipy.org',\n packages = ['scipy_distutils','scipy_distutils.command'],\n package_dir = {'scipy_distutils':path}\n )\n finally:\n os.chdir(old_path)\n \nif __name__ == '__main__':\n install_package()\n", "methods": [ { "name": "install_package", "long_name": "install_package( )", "filename": "setup.py", "nloc": 22, "complexity": 2, "token_count": 118, "parameters": [], "start_line": 7, "end_line": 34, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 28, "top_nesting_level": 0 } ], "methods_before": [ { "name": "install_package", "long_name": "install_package( )", "filename": "setup.py", "nloc": 16, "complexity": 2, "token_count": 76, "parameters": [], "start_line": 6, "end_line": 25, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "install_package", "long_name": "install_package( )", "filename": "setup.py", "nloc": 22, "complexity": 2, "token_count": 118, "parameters": [], "start_line": 7, "end_line": 34, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 28, "top_nesting_level": 0 } ], "nloc": 27, "complexity": 2, "token_count": 141, "diff_parsed": { "added": [ "", "from misc_util import get_path, get_version", "", "", " version = get_version(0,2)", " print 'scipy_distutils',version", " version_file = open('__version__.py','w')", " version_file.write('__version__ = %s\\n'%(repr(version)))", " version_file.close()", "", " version = version,", " author_email = \"scipy-devel@scipy.org\"," ], "deleted": [ "from misc_util import get_path", "", " version = \"0.2\"," ] } } ] }, { "hash": "b908030c39e3c5c490540597e93c5dc4bbcd77c7", "msg": "fixed bug in tables that forced display width to certain number of pixels.", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-04T23:24:48+00:00", "author_timezone": 0, "committer_date": "2002-01-04T23:24:48+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "587e00a3ecd762fa58e04f7b46c29c654319f864" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 5, "insertions": 6, "lines": 11, "files": 1, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": "weave/doc/tutorial.html", "new_path": "weave/doc/tutorial.html", "filename": "tutorial.html", "extension": "html", "change_type": "MODIFY", "diff": "@@ -350,7 +350,7 @@

              Benchmarks

              \n compared to Numeric.\n

              \n

              \n-\n+
              \n \n \n@@ -369,15 +369,16 @@

              Benchmarks

              \n \n \n \n+
              \n

              inline and ext_tools

              Algorithm

              Speed up

              5 pt avg. filter, 2D Image 512x512   9.01
              Electromagnetics (FDTD) 100x100x100   8.61
              \n+
              \n+

              \n+\n The benchmarks shown blitz in the best possible light. Numeric \n (at least on my machine) is significantly worse for double precision than it is \n for single precision calculations. If your interested in single precision \n results, you can pretty much divide the double precision speed up by 3 and you'll\n be close.\n \n-\n-\n-

              \n \n

              Inline

              \n

              \n@@ -1574,7 +1575,7 @@

              Type Conversions

              \n

              \n \n

              \n-\n+
              \n \n
              \n

              Default Data Type Conversions

              \n", "added_lines": 6, "deleted_lines": 5, "source_code": "\n

              Weave Documentation

              \n

              \nBy Eric Jones eric@enthought.com\n

              \n

              Outline

              \n
              \n
              Introduction\n
              Requirements\n
              Installation\n
              Testing\n
              Benchmarks\n
              Inline\n
              \n
              More with printf\n
              \n More examples\n
              \n
              Binary search\n
              Dictionary sort\n
              Numeric -- cast/copy/transpose\n
              wxPython
              \n
              \n
              Keyword options\n
              Returning values\n
              \n
              \n The issue with locals()
              \n
              \n
              A quick look at the code\n
              \n Technical Details\n
              \n
              Converting Types\n
              \n
              \n Numeric Argument Conversion\n
              \n String, List, Tuple, and Dictionary Conversion\n
              File Conversion \n
              \n Callable, Instance, and Module Conversion \n
              Customizing Conversions\n
              \n
              Compiling Code\n
              \"Cataloging\" functions\n
              \n
              Function Storage\n
              The PYTHONCOMPILED evnironment variable
              \n
              \n
              \n
              \n
              \n
              \n
              Blitz\n
              \n
              Requirements\n
              Limitations\n
              Numeric Efficiency Issues\n
              The Tools \n
              \n
              Parser\n
              Blitz and Numeric\n
              \n
              Type defintions and coersion\n
              Cataloging Compiled Functions\n
              Checking Array Sizes\n
              Creating the Extension Module\n
              \n
              Extension Modules\n
              \n
              A Simple Example\n
              Fibonacci Example\n
              \n
              Customizing Type Conversions -- Type Factories (not written)\n
              \n
              Type Specifications\n
              Type Information\n
              The Conversion Process \n
              \n
              \n\n

              Introduction

              \n\n

              \nThe weave package provides tools for including C/C++ code within\nin Python code. This offers both another level of optimization to those who need \nit, and an easy way to modify and extend any supported extension libraries such \nas wxPython and hopefully VTK soon. Inlining C/C++ code within Python generally\nresults in speed ups of 1.5x to 30x speed-up over algorithms written in pure\nPython (However, it is also possible to slow things down...). Generally \nalgorithms that require a large number of calls to the Python API don't benefit\nas much from the conversion to C/C++ as algorithms that have inner loops \ncompletely convertable to C.\n

              \nThere are three basic ways to use weave. The \nweave.inline() function executes C code directly within Python, \nand weave.blitz() translates Python Numeric expressions to C++ \nfor fast execution. blitz() was the original reason \nweave was built. For those interested in building extension\nlibraries, the ext_tools module provides classes for building \nextension modules within Python. \n

              \nMost of weave's functionality should work on Windows and Unix, \nalthough some of its functionality requires gcc or a similarly \nmodern C++ compiler that handles templates well. Up to now, most testing has \nbeen done on Windows 2000 with Microsoft's C++ compiler (MSVC) and with gcc \n(mingw32 2.95.2 and 2.95.3-6). All tests also pass on Linux (RH 7.1 \nwith gcc 2.96), and I've had reports that it works on Debian also (thanks \nPearu).\n

              \nThe inline and blitz provide new functionality to \nPython (although I've recently learned about the PyInline project which may offer \nsimilar functionality to inline). On the other hand, tools for \nbuilding Python extension modules already exists (SWIG, SIP, pycpp, CXX, and \nothers). As of yet, I'm not sure where weave fits in this \nspectrum. It is closest in flavor to CXX in that it makes creating new C/C++ \nextension modules pretty easy. However, if you're wrapping a gaggle of legacy \nfunctions or classes, SWIG and friends are definitely the better choice. \nweave is set up so that you can customize how Python types are \nconverted to C types in weave. This is great for \ninline(), but, for wrapping legacy code, it is more flexible to \nspecify things the other way around -- that is how C types map to Python types. \nThis weave does not do. I guess it would be possible to build \nsuch a tool on top of weave, but with good tools like SWIG around, \nI'm not sure the effort produces any new capabilities. Things like function \noverloading are probably easily implemented in weave and it might \nbe easier to mix Python/C code in function calls, but nothing beyond this comes \nto mind. So, if you're developing new extension modules or optimizing Python \nfunctions in C, weave.ext_tools() might be the tool \nfor you. If you're wrapping legacy code, stick with SWIG.\n

              \nThe next several sections give the basics of how to use weave.\nWe'll discuss what's happening under the covers in more detail later \non. Serious users will need to at least look at the type conversion section to \nunderstand how Python variables map to C/C++ types and how to customize this \nbehavior. One other note. If you don't know C or C++ then these docs are \nprobably of very little help to you. Further, it'd be helpful if you know \nsomething about writing Python extensions. weave does quite a \nbit for you, but for anything complex, you'll need to do some conversions, \nreference counting, etc.\n

              \n\nNote: weave is actually part of the SciPy package. However, it works fine as a \nstandalone package. The examples here are given as if it is used as a stand \nalone package. If you are using from within scipy, you can use from \nscipy import weave and the examples will work identically.\n\n\n

              Requirements

              \n
                \n
              • Python\n

                \n I use 2.1.1. Probably 2.0 or higher should work.\n

                \n

                • \n \n
              • C++ compiler\n

                \n weave uses distutils to actually build \n extension modules, so it uses whatever compiler was originally used to \n build Python. weave itself requires a C++ compiler. If \n you used a C++ compiler to build Python, your probably fine.\n

                \n On Unix gcc is the preferred choice because I've done a little \n testing with it. All testing has been done with gcc, but I expect the \n majority of compilers should work for inline and \n ext_tools. The one issue I'm not sure about is that I've \n hard coded things so that compilations are linked with the \n stdc++ library. Is this standard across \n Unix compilers, or is this a gcc-ism?\n

                \n For blitz(), you'll need a reasonably recent version of \n gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n versions are likely to work. Its likely that KAI's C++ compiler and \n maybe some others will work, but I haven't tried. My advice is to use \n gcc for now unless your willing to tinker with the code some.\n

                \n On Windows, either MSVC or gcc (www.mingw.org\" > mingw32) should work. Again, \n you'll need gcc for blitz() as the\n MSVC compiler doesn't handle templates well.\n

                \n I have not tried Cygwin, so please report success if it works for you.\n

                \n

                • \n\n
              • Numeric (optional)\n

                \n The python Numeric module from here. is required for \n blitz() to work. Be sure and get NumPy, not NumArray\n which is the \"next generation\" implementation. This is not\n required for using inline() or ext_tools.\n

                \n

                • \n
              • scipy_distutils and scipy_test (packaged with weave)\n

                \n These two modules are packaged with weave in both\n the windows installer and the source distributions. If you are using\n CVS, however, you'll need to download these separately (also available\n through CVS at SciPy).\n

                \n

                • \n
              \n

              \n\n\n

              Installation

              \n

              \nThere are currently two ways to get weave. Fist, \nweave is part of SciPy and installed automatically (as a sub-\npackage) whenever SciPy is installed (although the latest version isn't in \nSciPy yet, so use this one for now). Second, since weave is \nuseful outside of the scientific community, it has been setup so that it can be\nused as a stand-alone module. \n\n

              \nThe stand-alone version can be downloaded from here. Unix users should grab the \ntar ball (.tgz file) and install it using the following commands.\n\n 

              \n    tar -xzvf weave-0.2.tar.gz\n    cd weave-0.2\n    python setup.py install\n
              \n\nThis will also install two other packages, scipy_distutils and \nscipy_test. The first is needed by the setup process itself and \nboth are used in the unit-testing process. Numeric is required if you want to \nuse blitz(), but isn't necessary for inline() or \next_tools\n

              \nFor Windows users, it's even easier. You can download the click-install .exe \nfile and run it for automatic installation. There is also a .zip file of the\nsource for those interested. It also includes a setup.py file to simplify\ninstallation. \n

              \nIf you're using the CVS version, you'll need to install \nscipy_distutils and scipy_test packages (also \navailable from CVS) on your own.\n

              \n \nNote: The dependency issue here is a little sticky. I hate to make people \ndownload more than one file (and so I haven't), but distutils doesn't have a \nway to do conditional installation -- at least that I know about. This can \nlead to undesired clobbering of the scipy_test and scipy_distutils modules. \nWhat to do, what to do... Right now it is a very minor issue.\n\n

              \n\n

              Testing

              \nOnce weave is installed, fire up python and run its unit tests.\n\n 
              \n    >>> import weave\n    >>> weave.test()\n    runs long time... spews tons of output and a few warnings\n    .\n    .\n    .\n    ..............................................................\n    ................................................................\n    ..................................................\n    ----------------------------------------------------------------------\n    Ran 184 tests in 158.418s\n\n    OK\n    \n    >>> \n
              \n\nThis takes a loooong time. On windows, it is usually several minutes. On Unix \nwith remote file systems, I've had it take 15 or so minutes. In the end, it \nshould run about 180 tests and spew some speed results along the way. If you \nget errors, they'll be reported at the end of the output. Please let me know\nwhat if this occurs.\n\nIf you don't have Numeric installed, you'll get some module import errors \nduring the test setup phase for modules that are Numeric specific (blitz_spec, \nblitz_tools, size_check, standard_array_spec, ast_tools), but all test should\npass (about 100 and they should complete in several minutes).\n

              \nIf you only want to test a single module of the package, you can do this by\nrunning test() for that specific module.\n\n 

              \n    >>> import weave.scalar_spec\n    >>> weave.scalar_spec.test()\n    .......\n    ----------------------------------------------------------------------\n    Ran 7 tests in 23.284s\n
              \n\nTesting Notes:\n
                \n
              • \n Windows 1\n

                \n I've had some test fail on windows machines where I have msvc, gcc-2.95.2 \n (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My \n environment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the \n path. The test process runs very smoothly until the end where several test \n using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') \n before running tests, I get gcc-2.95.3-6. If I check after running tests \n (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] \n still has c:\\gcc first in it and is not corrupted (msvc/distutils messes \n with the environment variables, so we have to undo its work in some \n places). If anyone else sees this, let me know - - it may just be an quirk \n on my machine (unlikely). Testing with the gcc- 2.95.2 installation always \n works.\n

                \n

                • \n
              • \n Windows 2\n

                \n If you run the tests from PythonWin or some other GUI tool, you'll get a\n ton of DOS windows popping up periodically as weave spawns\n the compiler multiple times. Very annoying. Anyone know how to fix this?\n

                \n

                • \n
              • \n wxPython\n

                \n wxPython tests are not enabled by default because importing wxPython on a \n Unix machine without access to a X-term will cause the program to exit. \n Anyone know of a safe way to detect whether wxPython can be imported and \n whether a display exists on a machine? \n

                \n

                • \n                \n\n

                \n

              \n\n\n

              Benchmarks

              \nThis section has a few benchmarks -- thats all people want to see anyway right? \nThese are mostly taken from running files in the weave/example \ndirectory and also from the test scripts. Without more information about what \nthe test actually do, their value is limited. Still, their here for the \ncurious. Look at the example scripts for more specifics about what problem was \nactually solved by each run. These examples are run under windows 2000 using \nMicrosoft Visual C++ and python2.1 on a 850 MHz PIII laptop with 320 MB of RAM.\nSpeed up is the improvement (degredation) factor of weave compared to \nconventional Python functions. The blitz() comparisons are shown\ncompared to Numeric.\n

              \n

              \n\n\n \n \n \n \n \n \n \n \n\n \n \n \n \n \n \n
              \n

              inline and ext_tools

              Algorithm

              Speed up

              binary search   1.50
              fibonacci (recursive)  82.10
              fibonacci (loop)   9.17
              return None   0.14
              map   1.20
              dictionary sort   2.54
              vector quantization  37.40
              \n

              blitz -- double precision

              Algorithm

              Speed up

              a = b + c 512x512   3.05
              a = b + c + d 512x512   4.59
              5 pt avg. filter, 2D Image 512x512   9.01
              Electromagnetics (FDTD) 100x100x100   8.61
              \n
              \n

              \n\nThe benchmarks shown blitz in the best possible light. Numeric \n(at least on my machine) is significantly worse for double precision than it is \nfor single precision calculations. If your interested in single precision \nresults, you can pretty much divide the double precision speed up by 3 and you'll\nbe close.\n\n\n

              Inline

              \n

              \ninline() compiles and executes C/C++ code on the fly. Variables \nin the local and global Python scope are also available in the C/C++ code. \nValues are passed to the C/C++ code by assignment much like variables \nare passed into a standard Python function. Values are returned from the C/C++ \ncode through a special argument called return_val. Also, the contents of \nmutable objects can be changed within the C/C++ code and the changes remain \nafter the C code exits and returns to Python. (more on this later)\n

              \nHere's a trivial printf example using inline():\n\n 

              \n    >>> import weave    \n    >>> a  = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n

              \nIn this, its most basic form, inline(c_code, var_list) requires two \narguments. c_code is a string of valid C/C++ code. \nvar_list is a list of variable names that are passed from \nPython into C/C++. Here we have a simple printf statement that \nwrites the Python variable a to the screen. The first time you run \nthis, there will be a pause while the code is written to a .cpp file, compiled \ninto an extension module, loaded into Python, cataloged for future use, and \nexecuted. On windows (850 MHz PIII), this takes about 1.5 seconds when using \nMicrosoft's C++ compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). \nAll subsequent executions of the code will happen very quickly because the code \nonly needs to be compiled once. If you kill and restart the interpreter and then \nexecute the same code fragment again, there will be a much shorter delay in the \nfractions of seconds range. This is because weave stores a \ncatalog of all previously compiled functions in an on disk cache. When it sees \na string that has been compiled, it loads the already compiled module and \nexecutes the appropriate function. \n

              \n\nNote: If you try the printf example in a GUI shell such as IDLE, \nPythonWin, PyShell, etc., you're unlikely to see the output. This is because the \nC code is writing to stdout, instead of to the GUI window. This doesn't mean \nthat inline doesn't work in these environments -- it only means that standard \nout in C is not the same as the standard out for Python in these cases. Non \ninput/output functions will work as expected.\n\n

              \nAlthough effort has been made to reduce the overhead associated with calling \ninline, it is still less efficient for simple code snippets than using \nequivalent Python code. The simple printf example is actually \nslower by 30% or so than using Python print statement. And, it is \nnot difficult to create code fragments that are 8-10 times slower using inline \nthan equivalent Python. However, for more complicated algorithms, \nthe speed up can be worth while -- anywhwere from 1.5- 30 times faster. \nAlgorithms that have to manipulate Python objects (sorting a list) usually only \nsee a factor of 2 or so improvement. Algorithms that are highly computational \nor manipulate Numeric arrays can see much larger improvements. The \nexamples/vq.py file shows a factor of 30 or more improvement on the vector \nquantization algorithm that is used heavily in information theory and \nclassification problems.\n

              \n\n\n

              More with printf

              \n

              \nMSVC users will actually see a bit of compiler output that distutils does not\nsupress the first time the code executes:\n\n 

                  \n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    sc_e013937dbc8c647ac62438874e5795131.cpp\n       Creating library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\n       \\Release\\sc_e013937dbc8c647ac62438874e5795131.lib and object C:\\DOCUME\n       ~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_e013937dbc8c64\n       7ac62438874e5795131.exp\n    1\n
              \n

              \nNothing bad is happening, its just a bit annoying. Anyone know how to \nturn this off? \n

              \nThis example also demonstrates using 'raw strings'. The r \npreceeding the code string in the last example denotes that this is a 'raw \nstring'. In raw strings, the backslash character is not interpreted as an \nescape character, and so it isn't necessary to use a double backslash to \nindicate that the '\\n' is meant to be interpreted in the C printf \nstatement instead of by Python. If your C code contains a lot\nof strings and control characters, raw strings might make things easier.\nMost of the time, however, standard strings work just as well.\n\n

              \nThe printf statement in these examples is formatted to print \nout integers. What happens if a is a string? inline\nwill happily, compile a new version of the code to accept strings as input,\nand execute the code. The result?\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    32956972\n
              \n

              \nIn this case, the result is non-sensical, but also non-fatal. In other \nsituations, it might produce a compile time error because a is \nrequired to be an integer at some point in the code, or it could produce a \nsegmentation fault. Its possible to protect against passing \ninline arguments of the wrong data type by using asserts in \nPython.\n\n 

                  \n    >>> a = 'string'\n    >>> def protected_printf(a):    \n    ...     assert(type(a) == type(1))\n    ...     weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    >>> protected_printf(1)\n     1\n    >>> protected_printf('string')\n    AssertError...\n
              \n\n

              \nFor printing strings, the format statement needs to be changed.\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%s\\n\",a);',['a'])\n    string\n
              \n\n

              \nAs in this case, C/C++ code fragments often have to change to accept different \ntypes. For the given printing task, however, C++ streams provide a way of a \nsingle statement that works for integers and strings. By default, the stream \nobjects live in the std (standard) namespace and thus require the use of \nstd::.\n\n 

                  \n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    1    \n    >>> a = 'string'\n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    string\n
              \n \n

              \nExamples using printf and cout are included in \nexamples/print_example.py.\n\n\n

              More examples

              \n\nThis section shows several more advanced uses of inline. It \nincludes a few algorithms from the Python Cookbook \nthat have been re-written in inline C to improve speed as well as a couple \nexamples using Numeric and wxPython.\n\n\n

              Binary search

              \nLets look at the example of searching a sorted list of integers for a value. \nFor inspiration, we'll use Kalle Svensson's \nbinary_search() algorithm from the Python Cookbook. His recipe follows:\n\n 
              \n    def binary_search(seq, t):\n        min = 0; max = len(seq) - 1\n        while 1:\n            if max < min:\n                return -1\n            m = (min  + max)  / 2\n            if seq[m] < t: \n                min = m  + 1 \n            elif seq[m] > t: \n                max = m  - 1 \n            else:\n                return m    \n
              \n\nThis Python version works for arbitrary Python data types. The C version below is \nspecialized to handle integer values. There is a little type checking done in \nPython to assure that we're working with the correct data types before heading \ninto C. The variables seq and t don't need to be \ndeclared beacuse weave handles converting and declaring them in \nthe C code. All other temporary variables such as min, max, etc. \nmust be declared -- it is C after all. Here's the new mixed Python/C function:\n\n 
                  \n    def c_int_binary_search(seq,t):\n        # do a little type checking in Python\n        assert(type(t) == type(1))\n        assert(type(seq) == type([]))\n        \n        # now the C code\n        code = \"\"\"\n               #line 29 \"binary_search.py\"\n               int val, m, min = 0;  \n               int max = seq.length() - 1;\n               PyObject *py_val; \n               for(;;)\n               {\n                   if (max < min  ) \n                   { \n                       return_val =  Py::new_reference_to(Py::Int(-1)); \n                       break;\n                   } \n                   m =  (min + max) /2;\n                   val =    py_to_int(PyList_GetItem(seq.ptr(),m),\"val\"); \n                   if (val  < t) \n                       min = m  + 1;\n                   else if (val >  t)\n                       max = m - 1;\n                   else\n                   {\n                       return_val = Py::new_reference_to(Py::Int(m));\n                       break;\n                   }\n               }\n               \"\"\"\n        return inline(code,['seq','t'])\n
              \n

              \nWe have two variables seq and t passed in. \nt is guaranteed (by the assert) to be an integer. \nPython integers are converted to C int types in the transition from Python to \nC. seq is a Python list. By default, it is translated to a CXX \nlist object. Full documentation for the CXX library can be found at its website. The basics are that the CXX \nprovides C++ class equivalents for Python objects that simplify, or at \nleast object orientify, working with Python objects in C/C++. For example, \nseq.length() returns the length of the list. A little more about\nCXX and its class methods, etc. is in the ** type conversions ** section.\n

              \n\nNote: CXX uses templates and therefore may be a little less portable than \nanother alternative by Gordan McMillan called SCXX which was inspired by\nCXX. It doesn't use templates so it should compile faster and be more portable.\nSCXX has a few less features, but it appears to me that it would mesh with\nthe needs of weave quite well. Hopefully xxx_spec files will be written\nfor SCXX in the future, and we'll be able to compare on a more empirical\nbasis. Both sets of spec files will probably stick around, it just a question\nof which becomes the default.\n\n

              \nMost of the algorithm above looks similar in C to the original Python code. \nThere are two main differences. The first is the setting of \nreturn_val instead of directly returning from the C code with a \nreturn statement. return_val is an automatically \ndefined variable of type PyObject* that is returned from the C \ncode back to Python. You'll have to handle reference counting issues when \nsetting this variable. In this example, CXX classes and functions handle the \ndirty work. All CXX functions and classes live in the namespace \nPy::. The following code converts the integer m to a \nCXX Int() object and then to a PyObject* with an \nincremented reference count using Py::new_reference_to().\n\n 

                 \n    return_val = Py::new_reference_to(Py::Int(m));\n
              \n

              \nThe second big differences shows up in the retrieval of integer values from the \nPython list. The simple Python seq[i] call balloons into a C \nPython API call to grab the value out of the list and then a separate call to \npy_to_int() that converts the PyObject* to an integer. \npy_to_int() includes both a NULL cheack and a \nPyInt_Check() call as well as the conversion call. If either of \nthe checks fail, an exception is raised. The entire C++ code block is executed \nwith in a try/catch block that handles exceptions much like Python \ndoes. This removes the need for most error checking code.\n

              \nIt is worth note that CXX lists do have indexing operators that result \nin code that looks much like Python. However, the overhead in using them \nappears to be relatively high, so the standard Python API was used on the \nseq.ptr() which is the underlying PyObject* of the \nList object.\n

              \nThe #line directive that is the first line of the C code \nblock isn't necessary, but it's nice for debugging. If the compilation fails \nbecause of the syntax error in the code, the error will be reported as an error \nin the Python file \"binary_search.py\" with an offset from the given line number \n(29 here).\n

              \nSo what was all our effort worth in terms of efficiency? Well not a lot in \nthis case. The examples/binary_search.py file runs both Python and C versions \nof the functions As well as using the standard bisect module. If \nwe run it on a 1 million element list and run the search 3000 times (for 0-\n2999), here are the results we get:\n\n 

                 \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python binary_search.py\n    Binary search for 3000 items in 1000000 length list of integers:\n     speed in python: 0.159999966621\n     speed of bisect: 0.121000051498\n     speed up: 1.32\n     speed in c: 0.110000014305\n     speed up: 1.45\n     speed in c(no asserts): 0.0900000333786\n     speed up: 1.78\n
              \n

              \nSo, we get roughly a 50-75% improvement depending on whether we use the Python \nasserts in our C version. If we move down to searching a 10000 element list, \nthe advantage evaporates. Even smaller lists might result in the Python \nversion being faster. I'd like to say that moving to Numeric lists (and \ngetting rid of the GetItem() call) offers a substantial speed up, but my \npreliminary efforts didn't produce one. I think the log(N) algorithm is to \nblame. Because the algorithm is nice, there just isn't much time spent \ncomputing things, so moving to C isn't that big of a win. If there are ways to \nreduce conversion overhead of values, this may improve the C/Python speed \nup. Anyone have other explanations or faster code, please let me know.\n\n\n

              Dictionary Sort

              \n

              \nThe demo in examples/dict_sort.py is another example from the Python CookBook. \nThis \nsubmission, by Alex Martelli, demonstrates how to return the values from a \ndictionary sorted by their keys:\n\n 

                     \n    def sortedDictValues3(adict):\n        keys = adict.keys()\n        keys.sort()\n        return map(adict.get, keys)\n
              \n

              \nAlex provides 3 algorithms and this is the 3rd and fastest of the set. The C \nversion of this same algorithm follows:\n\n 

                     \n    def c_sort(adict):\n        assert(type(adict) == type({}))\n        code = \"\"\"     \n        #line 21 \"dict_sort.py\"  \n        Py::List keys = adict.keys();\n        Py::List items(keys.length()); keys.sort();     \n        PyObject* item = NULL; \n        for(int i = 0;  i < keys.length();i++)\n        {\n            item = PyList_GET_ITEM(keys.ptr(),i);\n            item = PyDict_GetItem(adict.ptr(),item);\n            Py_XINCREF(item);\n            PyList_SetItem(items.ptr(),i,item);              \n        }           \n        return_val = Py::new_reference_to(items);\n        \"\"\"   \n        return inline_tools.inline(code,['adict'],verbose=1)\n
              \n

              \nLike the original Python function, the C++ version can handle any Python \ndictionary regardless of the key/value pair types. It uses CXX objects for the \nmost part to declare python types in C++, but uses Python API calls to manipulate \ntheir contents. Again, this choice is made for speed. The C++ version, while\nmore complicated, is about a factor of 2 faster than Python.\n\n 

                     \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python dict_sort.py\n    Dict sort of 1000 items for 300 iterations:\n     speed in python: 0.319999933243\n    [0, 1, 2, 3, 4]\n     speed in c: 0.151000022888\n     speed up: 2.12\n    [0, 1, 2, 3, 4]\n
              \n

              \n\n

              Numeric -- cast/copy/transpose

              \n\nCastCopyTranspose is a function called quite heavily by Linear Algebra routines\nin the Numeric library. Its needed in part because of the row-major memory layout\nof multi-demensional Python (and C) arrays vs. the col-major order of the underlying\nFortran algorithms. For small matrices (say 100x100 or less), a significant\nportion of the common routines such as LU decompisition or singular value decompostion\nare spent in this setup routine. This shouldn't happen. Here is the Python\nversion of the function using standard Numeric operations.\n\n 
                     \n    def _castCopyAndTranspose(type, array):\n        if a.typecode() == type:\n            cast_array = copy.copy(Numeric.transpose(a))\n        else:\n            cast_array = copy.copy(Numeric.transpose(a).astype(type))\n        return cast_array\n
              \n\nAnd the following is a inline C version of the same function:\n\n 
              \n    from weave.blitz_tools import blitz_type_factories\n    from weave import scalar_spec\n    from weave import inline\n    def _cast_copy_transpose(type,a_2d):\n        assert(len(shape(a_2d)) == 2)\n        new_array = zeros(shape(a_2d),type)\n        numeric_type = scalar_spec.numeric_to_blitz_type_mapping[type]\n        code = \\\n        \"\"\"  \n        for(int i = 0;i < _Na_2d[0]; i++)  \n            for(int j = 0;  j < _Na_2d[1]; j++)\n                new_array(i,j) = (%s) a_2d(j,i);\n        \"\"\" % numeric_type\n        inline(code,['new_array','a_2d'],\n               type_factories = blitz_type_factories,compiler='gcc')\n        return new_array\n
              \n\nThis example uses blitz++ arrays instead of the standard representation of \nNumeric arrays so that indexing is simplier to write. This is accomplished by \npassing in the blitz++ \"type factories\" to override the standard Python to C++ \ntype conversions. Blitz++ arrays allow you to write clean, fast code, but they \nalso are sloooow to compile (20 seconds or more for this snippet). This is why \nthey aren't the default type used for Numeric arrays (and also because most \ncompilers can't compile blitz arrays...). inline() is also forced \nto use 'gcc' as the compiler because the default compiler on Windows (MSVC) \nwill not compile blitz code. 'gcc' I think will use the standard compiler \non Unix machine instead of explicitly forcing gcc (check this) \n\nComparisons of the Python vs inline C++ code show a factor of 3 speed up. Also \nshown are the results of an \"inplace\" transpose routine that can be used if the \noutput of the linear algebra routine can overwrite the original matrix (this is \noften appropriate). This provides another factor of 2 improvement.\n\n 
              \n     #C:\\home\\ej\\wrk\\scipy\\weave\\examples> python cast_copy_transpose.py\n    # Cast/Copy/Transposing (150,150)array 1 times\n    #  speed in python: 0.870999932289\n    #  speed in c: 0.25\n    #  speed up: 3.48\n    #  inplace transpose c: 0.129999995232\n    #  speed up: 6.70\n
              \n\n\n

              wxPython

              \n\ninline knows how to handle wxPython objects. Thats nice in and of\nitself, but it also demonstrates that the type conversion mechanism is reasonably \nflexible. Chances are, it won't take a ton of effort to support special types\nyou might have. The examples/wx_example.py borrows the scrolled window\nexample from the wxPython demo, accept that it mixes inline C code in the middle\nof the drawing function.\n\n 
              \n    def DoDrawing(self, dc):\n        \n        red = wxNamedColour(\"RED\");\n        blue = wxNamedColour(\"BLUE\");\n        grey_brush = wxLIGHT_GREY_BRUSH;\n        code = \\\n        \"\"\"\n        #line 108 \"wx_example.py\" \n        dc->BeginDrawing();\n        dc->SetPen(wxPen(*red,4,wxSOLID));\n        dc->DrawRectangle(5,5,50,50);\n        dc->SetBrush(*grey_brush);\n        dc->SetPen(wxPen(*blue,4,wxSOLID));\n        dc->DrawRectangle(15, 15, 50, 50);\n        \"\"\"\n        inline(code,['dc','red','blue','grey_brush'])\n        \n        dc.SetFont(wxFont(14, wxSWISS, wxNORMAL, wxNORMAL))\n        dc.SetTextForeground(wxColour(0xFF, 0x20, 0xFF))\n        te = dc.GetTextExtent(\"Hello World\")\n        dc.DrawText(\"Hello World\", 60, 65)\n\n        dc.SetPen(wxPen(wxNamedColour('VIOLET'), 4))\n        dc.DrawLine(5, 65+te[1], 60+te[0], 65+te[1])\n        ...\n
              \n\nHere, some of the Python calls to wx objects were just converted to C++ calls. There\nisn't any benefit, it just demonstrates the capabilities. You might want to use this\nif you have a computationally intensive loop in your drawing code that you want to \nspeed up.\n\nOn windows, you'll have to use the MSVC compiler if you use the standard wxPython\nDLLs distributed by Robin Dunn. Thats because MSVC and gcc, while binary\ncompatible in C, are not binary compatible for C++. In fact, its probably best, no \nmatter what platform you're on, to specify that inline use the same\ncompiler that was used to build wxPython to be on the safe side. There isn't currently\na way to learn this info from the library -- you just have to know. Also, at least\non the windows platform, you'll need to install the wxWindows libraries and link to \nthem. I think there is a way around this, but I haven't found it yet -- I get some\nlinking errors dealing with wxString. One final note. You'll probably have to\ntweak weave/wx_spec.py or weave/wx_info.py for your machine's configuration to\npoint at the correct directories etc. There. That should sufficiently scare people\ninto not even looking at this... :)\n\n              \n

              Keyword Options

              \n

              \nThe basic definition of the inline() function has a slew of \noptional variables. It also takes keyword arguments that are passed to \ndistutils as compiler options. The following is a formatted \ncut/paste of the argument section of inline's doc-string. It \nexplains all of the variables. Some examples using various options will \nfollow.\n\n 

                     \n    def inline(code,arg_names,local_dict = None, global_dict = None, \n               force = 0, \n               compiler='',\n               verbose = 0, \n               support_code = None,\n               customize=None, \n               type_factories = None, \n               auto_downcast=1,\n               **kw):\n
              \n\n \ninline has quite \na few options as listed below. Also, the keyword arguments for distutils \nextension modules are accepted to specify extra information needed for \ncompiling. \n
              \n

              inline Arguments:

              \n
              \n
              \n
              code
              \n \n
              \nstring. A string of valid C++ code. It should not \n specify a return statement. Instead it should assign results that need to be \n returned to Python in the return_val. \n
              \n\n
              arg_names
              \n \n
              \nlist of strings. A list of Python variable names \n that should be transferred from Python into the C/C++ code. \n
              \n\n
              local_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the local scope for the C/C++ \n code. If local_dict is not specified the local dictionary of the calling \n function is used. \n
              \n\n
              global_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the global scope for the C/C++ \n code. If global_dict is not specified the global dictionary of the calling \n function is used. \n
              \n\n
              force
              \n \n
              \noptional. 0 or 1. default 0. If 1, the C++ code is \n compiled every time inline is called. This is really only useful for \n debugging, and probably only useful if you're editing support_code a lot. \n
              \n\n
              compiler
              \n \n
              \noptional. string. The name of compiler to use when compiling. On windows, it \nunderstands 'msvc' and 'gcc' as well as all the compiler names understood by \ndistutils. On Unix, it'll only understand the values understoof by distutils. \n(I should add 'gcc' though to this).\n

              \nOn windows, the compiler defaults to the Microsoft C++ compiler. If this isn't \navailable, it looks for mingw32 (the gcc compiler).\n

              \nOn Unix, it'll probably use the same compiler that was used when compiling \nPython. Cygwin's behavior should be similar.

              \n
              \n\n
              verbose
              \n \n
              \noptional. 0,1, or 2. defualt 0. Speficies how much \n much information is printed during the compile phase of inlining code. 0 is \n silent (except on windows with msvc where it still prints some garbage). 1 \n informs you when compiling starts, finishes, and how long it took. 2 prints \n out the command lines for the compilation process and can be useful if you're \n having problems getting code to work. Its handy for finding the name of the \n .cpp file if you need to examine it. verbose has no affect if the \n compilation isn't necessary. \n
              \n\n
              support_code
              \n \n
              \noptional. string. A string of valid C++ code \n declaring extra code that might be needed by your compiled function. This \n could be declarations of functions, classes, or structures. \n
              \n\n
              customize
              \n \n
              \noptional. base_info.custom_info object. An \n alternative way to specifiy support_code, headers, etc. needed by the \n function see the weave.base_info module for more details. (not sure \n this'll be used much). \n \n
              \n
              type_factories
              \n \n
              \noptional. list of type specification factories. These guys are what convert \nPython data types to C/C++ data types. If you'd like to use a different set of \ntype conversions than the default, specify them here. Look in the type \nconversions section of the main documentation for examples.\n
              \n
              auto_downcast
              \n \n
              \noptional. 0 or 1. default 1. This only affects functions that have Numeric \narrays as input variables. Setting this to 1 will cause all floating point \nvalues to be cast as float instead of double if all the Numeric arrays are of \ntype float. If even one of the arrays has type double or double complex, all \nvariables maintain there standard types.\n
              \n
              \n
              \n\n

              Distutils keywords:

              \n
              \ninline() also accepts a number of distutils keywords \nfor controlling how the code is compiled. The following descriptions have been \ncopied from Greg Ward's distutils.extension.Extension class doc-\nstrings for convenience:\n\n
              \n
              sources
              \n \n
              \n[string] list of source filenames, relative to the \n distribution root (where the setup script lives), in Unix form \n (slash-separated) for portability. Source files may be C, C++, SWIG (.i), \n platform-specific resource files, or whatever else is recognized by the \n \"build_ext\" command as source for a Python extension. Note: The module_path \n file is always appended to the front of this list \n
              \n\n
              include_dirs
              \n \n
              \n[string] list of directories to search for C/C++ \n header files (in Unix form for portability) \n
              \n\n
              define_macros
              \n \n
              \n[(name : string, value : string|None)] list of \n macros to define; each macro is defined using a 2-tuple, where 'value' is \n either the string to define it to or None to define it without a particular \n value (equivalent of \"#define FOO\" in source or -DFOO on Unix C compiler \n command line) \n
              \n
              undef_macros
              \n \n
              \n[string] list of macros to undefine explicitly \n
              \n
              library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at link time \n
              \n
              libraries
              \n
              \n[string] list of library names (not filenames or paths) to link against \n
              \n
              runtime_library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at run time (for \nshared extensions, this is when the extension is loaded) \n
              \n\n
              extra_objects
              \n \n
              \n[string] list of extra files to link with (eg. \n object files not implied by 'sources', static library that must be \n explicitly specified, binary resource files, etc.) \n
              \n\n
              extra_compile_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when compiling the source files in 'sources'. For \n platforms and compilers where \"command line\" makes sense, this is typically \n a list of command-line arguments, but for other platforms it could be \n anything. \n
              \n
              extra_link_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when linking object files together to create the \n extension (or to create a new static Python interpreter). Similar \n interpretation as for 'extra_compile_args'. \n
              \n
              export_symbols
              \n \n
              \n[string] list of symbols to be exported from a shared extension. Not used on \nall platforms, and not generally necessary for Python extensions, which \ntypically export exactly one symbol: \"init\" + extension_name. \n
              \n
              \n
              \n\n\n

              Keyword Option Examples

              \nWe'll walk through several examples here to demonstrate the behavior of \ninline and also how the various arguments are used.\n\nIn the simplest (most) cases, code and arg_names\nare the only arguments that need to be specified. Here's a simple example\nrun on Windows machine that has Microsoft VC++ installed.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'string'\n    >>> code = \"\"\"\n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));\n    ...        \"\"\"\n    >>> inline(code,['a'])\n     sc_86e98826b65b047ffd2cd5f479c627f12.cpp\n    Creating\n       library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f12.lib\n    and object C:\\DOCUME~ 1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ff\n    d2cd5f479c627f12.exp\n    6\n    >>> inline(code,['a'])\n    6\n
              \n \nWhen inline is first run, you'll notice that pause and some \ntrash printed to the screen. The \"trash\" is acutually part of the compilers\noutput that distutils does not supress. The name of the extension file, \nsc_bighonkingnumber.cpp, is generated from the md5 check sum\nof the C/C++ code fragment. On Unix or windows machines with only\ngcc installed, the trash will not appear. On the second call, the code \nfragment is not compiled since it already exists, and only the answer is \nreturned. Now kill the interpreter and restart, and run the same code with\na different string.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'a longer string' \n    >>> code = \"\"\" \n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));  \n    ...        \"\"\"\n    >>> inline(code,['a'])\n    15\n
              \n

              \nNotice this time, inline() did not recompile the code because it\nfound the compiled function in the persistent catalog of functions. There is\na short pause as it looks up and loads the function, but it is much shorter \nthan compiling would require.\n

              \nYou can specify the local and global dictionaries if you'd like (much like \nexec or eval() in Python), but if they aren't \nspecified, the \"expected\" ones are used -- i.e. the ones from the function that \ncalled inline() . This is accomplished through a little call \nframe trickery. Here is an example where the local_dict is specified using\nthe same code example from above:\n\n 

              \n    >>> a = 'a longer string'\n    >>> b = 'an even  longer string' \n    >>> my_dict = {'a':b}\n    >>> inline(code,['a'])\n    15\n    >>> inline(code,['a'],my_dict)\n    21\n
              \n \n

              \nEverytime, the code is changed, inline does a \nrecompile. However, changing any of the other options in inline does not\nforce a recompile. The force option was added so that one\ncould force a recompile when tinkering with other variables. In practice,\nit is just as easy to change the code by a single character\n(like adding a space some place) to force the recompile. Note: It also \nmight be nice to add some methods for purging the cache and on disk \ncatalogs.\n

              \nI use verbose sometimes for debugging. When set to 2, it'll \noutput all the information (including the name of the .cpp file) that you'd\nexpect from running a make file. This is nice if you need to examine the\ngenerated code to see where things are going haywire. Note that error\nmessages from failed compiles are printed to the screen even if verbose\n is set to 0.\n

              \nThe following example demonstrates using gcc instead of the standard msvc \ncompiler on windows using same code fragment as above. Because the example has \nalready been compiled, the force=1 flag is needed to make \ninline() ignore the previously compiled version and recompile \nusing gcc. The verbose flag is added to show what is printed out:\n\n 

              \n    >>>inline(code,['a'],compiler='gcc',verbose=2,force=1)\n    running build_ext    \n    building 'sc_86e98826b65b047ffd2cd5f479c627f13' extension \n    c:\\gcc-2.95.2\\bin\\g++.exe -mno-cygwin -mdll -O2 -w -Wstrict-prototypes -IC:\n    \\home\\ej\\wrk\\scipy\\weave -IC:\\Python21\\Include -c C:\\DOCUME~1\\eric\\LOCAL\n    S~1\\Temp\\python21_compiled\\sc_86e98826b65b047ffd2cd5f479c627f13.cpp -o C:\\D\n    OCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b04\n    7ffd2cd5f479c627f13.o    \n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxextensions.c (C:\\DOCUME~1\\eri\n    c\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxextensions.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxsupport.cxx (C:\\DOCUME~1\\eric\n    \\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxsupport.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\IndirectPythonInterface.cxx (C:\\\n    DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\indirectpythonin\n    terface.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxx_extensions.cxx (C:\\DOCUME~1\\\n    eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxx_extensions.o up-to-da\n    te)\n    writing C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86\n    e98826b65b047ffd2cd5f479c627f13.def\n    c:\\gcc-2.95.2\\bin\\dllwrap.exe --driver-name g++ -mno-cygwin -mdll -static -\n    -output-lib C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\l\n    ibsc_86e98826b65b047ffd2cd5f479c627f13.a --def C:\\DOCUME~1\\eric\\LOCALS~1\\Te\n    mp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f13.def \n    -s C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e9882\n    6b65b047ffd2cd5f479c627f13.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compil\n    ed\\temp\\Release\\cxxextensions.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\cxxsupport.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\indirectpythoninterface.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\n    \\python21_compiled\\temp\\Release\\cxx_extensions.o -LC:\\Python21\\libs -lpytho\n    n21 -o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\sc_86e98826b65b047f\n    fd2cd5f479c627f13.pyd\n    15\n
              \n\nThat's quite a bit of output. verbose=1 just prints the compile\ntime.\n\n 
              \n    >>>inline(code,['a'],compiler='gcc',verbose=1,force=1)\n    Compiling code...\n    finished compiling (sec):  6.00800001621\n    15\n
              \n\n

              \n Note: I've only used the compiler option for switching between 'msvc'\nand 'gcc' on windows. It may have use on Unix also, but I don't know yet.\n\n\n

              \nThe support_code argument is likely to be used a lot. It allows \nyou to specify extra code fragments such as function, structure or class \ndefinitions that you want to use in the code string. Note that \nchanges to support_code do not force a recompile. The \ncatalog only relies on code (for performance reasons) to determine \nwhether recompiling is necessary. So, if you make a change to support_code, \nyou'll need to alter code in some way or use the \nforce argument to get the code to recompile. I usually just add \nsome inocuous whitespace to the end of one of the lines in code \nsomewhere. Here's an example of defining a separate method for calculating\nthe string length:\n\n 

              \n    >>> from weave import inline\n    >>> a = 'a longer string'\n    >>> support_code = \"\"\"\n    ...                PyObject* length(Py::String a)\n    ...                {\n    ...                    int l = a.length();  \n    ...                    return Py::new_reference_to(Py::Int(l)); \n    ...                }\n    ...                \"\"\"        \n    >>> inline(\"return_val = length(a);\",['a'],\n    ...        support_code = support_code)\n    15\n
              \n

              \ncustomize is a left over from a previous way of specifying \ncompiler options. It is a custom_info object that can specify \nquite a bit of information about how a file is compiled. These \ninfo objects are the standard way of defining compile information \nfor type conversion classes. However, I don't think they are as handy here, \nespecially since we've exposed all the keyword arguments that distutils can \nhandle. Between these keywords, and the support_code option, I \nthink customize may be obsolete. We'll see if anyone cares to use \nit. If not, it'll get axed in the next version.\n

              \nThe type_factories variable is important to people who want to\ncustomize the way arguments are converted from Python to C. We'll talk about\nthis in the next chapter **xx** of this document when we discuss type\nconversions.\n

              \nauto_downcast handles one of the big type conversion issues that\nis common when using Numeric arrays in conjunction with Python scalar values.\nIf you have an array of single precision values and multiply that array by a \nPython scalar, the result is upcast to a double precision array because the\nscalar value is double precision. This is not usually the desired behavior\nbecause it can double your memory usage. auto_downcast goes\nsome distance towards changing the casting precedence of arrays and scalars.\nIf your only using single precision arrays, it will automatically downcast all\nscalar values from double to single precision when they are passed into the\nC++ code. This is the default behavior. If you want all values to keep there\ndefault type, set auto_downcast to 0.\n

              \n\n\n\n

              Returning Values

              \n\nPython variables in the local and global scope transfer seemlessly from Python \ninto the C++ snippets. And, if inline were to completely live up\nto its name, any modifications to variables in the C++ code would be reflected\nin the Python variables when control was passed back to Python. For example,\nthe desired behavior would be something like:\n\n 
              \n    # THIS DOES NOT WORK\n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    2\n
              \n\nInstead you get:\n\n 
              \n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    1\n
              \n \nVariables are passed into C++ as if you are calling a Python function. Python's \ncalling convention is sometimes called \"pass by assignment\". This means its as \nif a c_a = a assignment is made right before inline \ncall is made and the c_a variable is used within the C++ code. \nThus, any changes made to c_a are not reflected in Python's \na variable. Things do get a little more confusing, however, when \nlooking at variables with mutable types. Changes made in C++ to the contents \nof mutable types are reflected in the Python variables.\n\n 
              \n    >>> a= [1,2]\n    >>> weave.inline(\"PyList_SetItem(a.ptr(),0,PyInt_FromLong(3));\",['a'])\n    >>> print a\n    [3, 2]\n
              \n\nSo modifications to the contents of mutable types in C++ are seen when control\nis returned to Python. Modifications to immutable types such as tuples,\nstrings, and numbers do not alter the Python variables.\n\nIf you need to make changes to an immutable variable, you'll need to assign\nthe new value to the \"magic\" variable return_val in C++. This\nvalue is returned by the inline() function:\n\n 
              \n    >>> a = 1\n    >>> a = weave.inline(\"return_val = Py::new_reference_to(Py::Int(a+1));\",['a'])  \n    >>> a\n    2\n
              \n\nThe return_val variable can also be used to return newly created \nvalues. This is possible by returning a tuple. The following trivial example \nillustrates how this can be done:\n\n 
                     \n    # python version\n    def multi_return():\n        return 1, '2nd'\n    \n    # C version.\n    def c_multi_return():    \n        code =  \"\"\"\n     \t        Py::Tuple results(2);\n     \t        results[0] = Py::Int(1);\n     \t        results[1] = Py::String(\"2nd\");\n     \t        return_val = Py::new_reference_to(results); \t        \n                \"\"\"\n        return inline_tools.inline(code)\n
              \n

              \nThe example is available in examples/tuple_return.py. It also\nhas the dubious honor of demonstrating how much inline() can \nslow things down. The C version here is about 10 times slower than the Python\nversion. Of course, something so trivial has no reason to be written in\nC anyway.\n\n\n

              The issue with locals()

              \n

              \ninline passes the locals() and globals() \ndictionaries from Python into the C++ function from the calling function. It \nextracts the variables that are used in the C++ code from these dictionaries, \nconverts then to C++ variables, and then calculates using them. It seems like \nit would be trivial, then, after the calculations were finished to then insert \nthe new values back into the locals() and globals() \ndictionaries so that the modified values were reflected in Python. \nUnfortunately, as pointed out by the Python manual, the locals() dictionary is \nnot writable. \n

              \n\nI suspect locals() is not writable because there are some \noptimizations done to speed lookups of the local namespace. I'm guessing local \nlookups don't always look at a dictionary to find values. Can someone \"in the \nknow\" confirm or correct this? Another thing I'd like to know is whether there \nis a way to write to the local namespace of another stack frame from C/C++. If \nso, it would be possible to have some clean up code in compiled functions that \nwrote final values of variables in C++ back to the correct Python stack frame. \nI think this goes a long way toward making inline truely live up \nto its name. I don't think we'll get to the point of creating variables in \nPython for variables created in C -- although I suppose with a C/C++ parser you \ncould do that also.\n\n

              \n\n\n

              A quick look at the code

              \n\nweave generates a C++ file holding an extension function for \neach inline code snippet. These file names are generated using \nfrom the md5 signature of the code snippet and saved to a location specified by \nthe PYTHONCOMPILED environment variable (discussed later). The cpp files are \ngenerally about 200-400 lines long and include quite a few functions to support \ntype conversions, etc. However, the actual compiled function is pretty simple. \nBelow is the familiar printf example:\n\n 
              \n    >>> import weave    \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n\nAnd here is the extension function generated by inline:\n\n 
              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        // The Py_None needs an incref before returning\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n        \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try                              \n        {                                \n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n            /* Here is the inline code */            \n            printf(\"%d\\n\",a);\n            /* I would like to fill in changed locals and globals here... */\n        }                                       \n        catch( Py::Exception& e)           \n        {                                \n            return_val =  Py::Null();    \n            exception_occured = 1;       \n        }                                 \n        if(!return_val && !exception_occured)\n        {\n                                      \n            Py_INCREF(Py_None);              \n            return_val = Py_None;            \n        }\n        /* clean up code */\n        \n        /* return */                              \n        return return_val;           \n    }                                \n
              \n\nEvery inline function takes exactly two arguments -- the local and global\ndictionaries for the current scope. All variable values are looked up out\nof these dictionaries. The lookups, along with all inline code \nexecution, are done within a C++ try block. If the variables\naren't found, or there is an error converting a Python variable to the \nappropriate type in C++, an exception is raised. The C++ exception\nis automatically converted to a Python exception by CXX and returned to Python.\n\nThe py_to_int() function illustrates how the conversions and\nexception handling works. py_to_int first checks that the given PyObject*\npointer is not NULL and is a Python integer. If all is well, it calls the\nPython API to convert the value to an int. Otherwise, it calls\nhandle_bad_type() which gathers information about what went wrong\nand then raises a CXX TypeError which returns to Python as a TypeError.\n\n 
              \n    int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\n 
              \n    void handle_bad_type(PyObject* py_obj, char* good_type, char*  var_name)\n    {\n        char msg[500];\n        sprintf(msg,\"received '%s' type instead of '%s' for variable '%s'\",\n                find_type(py_obj),good_type,var_name);\n        throw Py::TypeError(msg);\n    }\n    \n    char* find_type(PyObject* py_obj)\n    {\n        if(py_obj == NULL) return \"C NULL value\";\n        if(PyCallable_Check(py_obj)) return \"callable\";\n        if(PyString_Check(py_obj)) return \"string\";\n        if(PyInt_Check(py_obj)) return \"int\";\n        if(PyFloat_Check(py_obj)) return \"float\";\n        if(PyDict_Check(py_obj)) return \"dict\";\n        if(PyList_Check(py_obj)) return \"list\";\n        if(PyTuple_Check(py_obj)) return \"tuple\";\n        if(PyFile_Check(py_obj)) return \"file\";\n        if(PyModule_Check(py_obj)) return \"module\";\n        \n        //should probably do more interagation (and thinking) on these.\n        if(PyCallable_Check(py_obj) && PyInstance_Check(py_obj)) return \"callable\";\n        if(PyInstance_Check(py_obj)) return \"instance\"; \n        if(PyCallable_Check(py_obj)) return \"callable\";\n        return \"unkown type\";\n    }\n
              \n\nSince the inline is also executed within the try/catch\nblock, you can use CXX exceptions within your code. It is usually a bad idea\nto directly return from your code, even if an error occurs. This\nskips the clean up section of the extension function. In this simple example,\nthere isn't any clean up code, but in more complicated examples, there may\nbe some reference counting that needs to be taken care of here on converted\nvariables. To avoid this, either uses exceptions or set \nreturn_val to NULL and use if/then's to skip code\nafter errors.\n\n\n

              Technical Details

              \n

              \nThere are several main steps to using C/C++ code withing Python:\n

                \n
              1. Type conversion \n
              2. Generating C/C++ code \n
              3. Compile the code to an extension module \n
              4. Catalog (and cache) the function for future use
                5. \n
              \n

              \nItems 1 and 2 above are related, but most easily discussed separately. Type \nconversions are customizable by the user if needed. Understanding them is \npretty important for anything beyond trivial uses of inline. \nGenerating the C/C++ code is handled by ext_function and \next_module classes and . For the most part, compiling the code is \nhandled by distutils. Some customizations were needed, but they were \nrelatively minor and do not require changes to distutils itself. Cataloging is \npretty simple in concept, but surprisingly required the most code to implement \n(and still likely needs some work). So, this section covers items 1 and 4 from \nthe list. Item 2 is covered later in the chapter covering the \next_tools module, and distutils is covered by a completely \nseparate document xxx.\n\n

              Passing Variables in/out of the C/C++ code

              \n\nNote: Passing variables into the C code is pretty straight forward, but there \nare subtlties to how variable modifications in C are returned to Python. see Returning Values for a more thorough discussion of \nthis issue.\n \n \n\n

              Type Conversions

              \n\n\nNote: Maybe xxx_converter instead of \nxxx_specification is a more descriptive name. Might change in \nfuture version?\n\n\n

              \nBy default, inline() makes the following type conversions between\nPython and C++ types.\n

              \n\n

              \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
              \n

              Default Data Type Conversions

              \n

              Python

              		\n

              C++

                 int   int
                 float   double
                 complex   std::complex
                 string   Py::String
                 list   Py::List
                 dict   Py::Dict
                 tuple   Py::Tuple
                 file   FILE*
                 callable   PyObject*
                 instance   PyObject*
                 Numeric.array   PyArrayObject*
                 wxXXX   wxXXX*
              \n
              \n

              \nThe Py:: namespace is defined by the \nCXX library which has C++ class\nequivalents for many Python types. std:: is the namespace of the\nstandard library in C++.\n

              \n\nNote: \n

                \n
              • I haven't figured out how to handle long int yet (I think they are currenlty converted \n to int - - check this). \n \n
              • \nHopefully VTK will be added to the list soon
                • \n
              \n\n

              \n\nPython to C++ conversions fill in code in several locations in the generated\ninline extension function. Below is the basic template for the\nfunction. This is actually the exact code that is generated by calling\nweave.inline(\"\").\n\n 

              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n    \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try\n        {\n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            /* argument conversion code */\n            /* inline code */\n            /*I would like to fill in changed locals and globals here...*/\n    \n        }\n        catch( Py::Exception& e)\n        {\n            return_val =  Py::Null();\n            exception_occured = 1;\n        }\n        /* cleanup code */\n        if(!return_val && !exception_occured)\n        {\n    \n            Py_INCREF(Py_None);\n            return_val = Py_None;\n        }\n    \n        return return_val;\n    }\n
              \n\nThe /* inline code */ section is filled with the code passed to\nthe inline() function call. The \n/*argument convserion code*/ and /* cleanup code */\nsections are filled with code that handles conversion from Python to C++\ntypes and code that deallocates memory or manipulates reference counts before\nthe function returns. The following sections demostrate how these two areas\nare filled in by the default conversion methods.\n\n \nNote: I'm not sure I have reference counting correct on a few of these. The \nonly thing I increase/decrease the ref count on is Numeric arrays. If you\nsee an issue, please let me know.\n\n\n\n

              Numeric Argument Conversion

              \n\nInteger, floating point, and complex arguments are handled in a very similar\nfashion. Consider the following inline function that has a single integer \nvariable passed in:\n\n 
              \n    >>> a = 1\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_int() has the following\nform:\n\n 
              \n    static int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\nSimilarly, the float and complex conversion routines look like:\n\n 
                  \n    static double py_to_float(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyFloat_Check(py_obj))\n            handle_bad_type(py_obj,\"float\", name);\n        return PyFloat_AsDouble(py_obj);\n    }\n    \n    static std::complex py_to_complex(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyComplex_Check(py_obj))\n            handle_bad_type(py_obj,\"complex\", name);\n        return std::complex(PyComplex_RealAsDouble(py_obj),\n                                    PyComplex_ImagAsDouble(py_obj));    \n    }\n
              \n\nNumeric conversions do not require any clean up code.\n\n\n

              String, List, Tuple, and Dictionary Conversion

              \n\nStrings, Lists, Tuples and Dictionary conversions are all converted to \nCXX types by default.\n\nFor the following code, \n\n 
              \n    >>> a = [1]\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    Py::List a = py_to_list (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_list() and its\nfriends has the following form:\n\n 
                  \n    static Py::List py_to_list(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyList_Check(py_obj))\n            handle_bad_type(py_obj,\"list\", name);\n        return Py::List(py_obj);\n    }\n    \n    static Py::String py_to_string(PyObject* py_obj,char* name)\n    {\n        if (!PyString_Check(py_obj))\n            handle_bad_type(py_obj,\"string\", name);\n        return Py::String(py_obj);\n    }\n\n    static Py::Dict py_to_dict(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyDict_Check(py_obj))\n            handle_bad_type(py_obj,\"dict\", name);\n        return Py::Dict(py_obj);\n    }\n    \n    static Py::Tuple py_to_tuple(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyTuple_Check(py_obj))\n            handle_bad_type(py_obj,\"tuple\", name);\n        return Py::Tuple(py_obj);\n    }\n
              \n\nCXX handles reference counts on for strings, lists, tuples, and dictionaries,\nso clean up code isn't necessary.\n\n\n

              File Conversion

              \n\nFor the following code, \n\n 
              \n    >>> a = open(\"bob\",'w')  \n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code is:\n\n 
              \n    /* argument conversion code */\n    PyObject* py_a = get_variable(\"a\",raw_locals,raw_globals);\n    FILE* a = py_to_file(py_a,\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_file() converts\nPyObject* to a FILE* and increments the reference count of the PyObject*:\n\n 
              \n    FILE* py_to_file(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"file\", name);\n    \n        Py_INCREF(py_obj);\n        return PyFile_AsFile(py_obj);\n    }\n
              \n\nBecause the PyObject* was incremented, the clean up code needs to decrement\nthe counter\n\n 
              \n    /* cleanup code */\n    Py_XDECREF(py_a);\n
              \n\nIts important to understand that file conversion only works on actual files --\ni.e. ones created using the open() command in Python. It does\nnot support converting arbitrary objects that support the file interface into\nC FILE* pointers. This can affect many things. For example, in\ninitial printf() examples, one might be tempted to solve the \nproblem of C and Python IDE's (PythonWin, PyCrust, etc.) writing to different\nstdout and stderr by using fprintf() and passing in \nsys.stdout and sys.stderr. For example, instead of\n\n 
              \n    >>> weave.inline('printf(\"hello\\\\n\");')\n
              \n \nYou might try:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n
              \n\nThis will work as expected from a standard python interpreter, but in PythonWin,\nthe following occurs:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n    Traceback (most recent call last):\n        File \"\", line 1, in ?\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 315, in inline\n            auto_downcast = auto_downcast,\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 386, in compile_function\n            type_factories = type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 197, in __init__\n            auto_downcast, type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 390, in assign_variable_types\n            raise TypeError, format_error_msg(errors)\n        TypeError: {'buf': \"Unable to convert variable 'buf' to a C++ type.\"}\n
              \n\nThe traceback tells us that inline() was unable to convert 'buf' to a\nC++ type (If instance conversion was implemented, the error would have occurred at \nruntime instead). Why is this? Let's look at what the buf object \nreally is:\n\n 
              \n    >>> buf\n    pywin.framework.interact.InteractiveView instance at 00EAD014\n
              \n\nPythonWin has reassigned sys.stdout to a special object that \nimplements the Python file interface. This works great in Python, but since \nthe special object doesn't have a FILE* pointer underlying it, fprintf doesn't \nknow what to do with it (well this will be the problem when instance conversion \nis implemented...).\n\n\n

              Callable, Instance, and Module Conversion

              \n\nNote: Need to look into how ref counts should be handled. Also,\nInstance and Module conversion are not currently implemented.\n\n\n 
              \n    >>> def a(): \n        pass\n    >>> inline(\"\",['a'])\n
              \n\nCallable and instance variables are converted to PyObject*. Nothing is done\nto there reference counts.\n\n 
              \n    /* argument conversion code */\n    PyObject* a = py_to_callable(get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. The py_to_callable() and\npy_to_instance() don't currently increment the ref count.\n\n 
                  \n    PyObject* py_to_callable(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyCallable_Check(py_obj))\n            handle_bad_type(py_obj,\"callable\", name);    \n        return py_obj;\n    }\n\n    PyObject* py_to_instance(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"instance\", name);    \n        return py_obj;\n    }\n
              \n \nThere is no cleanup code for callables, modules, or instances.\n\n\n

              Customizing Conversions

              \n

              \nConverting from Python to C++ types is handled by xxx_specification classes. A \ntype specification class actually serve in two related but different \nroles. The first is in determining whether a Python variable that needs to be \nconverted should be represented by the given class. The second is as a code \ngenerator that generate C++ code needed to convert from Python to C++ types for \na specific variable.\n

              \nWhen \n\n 

              \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\",a);',['a'])\n
              \n \nis called for the first time, the code snippet has to be compiled. In this \nprocess, the variable 'a' is tested against a list of type specifications (the \ndefault list is stored in weave/ext_tools.py). The first \nspecification in the list is used to represent the variable. \n\n

              \nExamples of xxx_specification are scattered throughout numerous \n\"xxx_spec.py\" files in the weave package. Closely related to \nthe xxx_specification classes are yyy_info classes. \nThese classes contain compiler, header, and support code information necessary \nfor including a certain set of capabilities (such as blitz++ or CXX support)\nin a compiled module. xxx_specification classes have one or more\nyyy_info classes associated with them.\n\nIf you'd like to define your own set of type specifications, the current best route\nis to examine some of the existing spec and info files. Maybe looking over\nsequence_spec.py and cxx_info.py are a good place to start. After defining \nspecification classes, you'll need to pass them into inline using the \ntype_factories argument. \n\nA lot of times you may just want to change how a specific variable type is \nrepresented. Say you'd rather have Python strings converted to \nstd::string or maybe char* instead of using the CXX \nstring object, but would like all other type conversions to have default \nbehavior. This requires that a new specification class that handles strings\nis written and then prepended to a list of the default type specifications. Since\nit is closer to the front of the list, it effectively overrides the default\nstring specification.\n\nThe following code demonstrates how this is done:\n\n...\n\n\n

              The Catalog

              \n

              \ncatalog.py has a class called catalog that helps keep \ntrack of previously compiled functions. This prevents inline() \nand related functions from having to compile functions everytime they are \ncalled. Instead, catalog will check an in memory cache to see if the function \nhas already been loaded into python. If it hasn't, then it starts searching \nthrough persisent catalogs on disk to see if it finds an entry for the given \nfunction. By saving information about compiled functions to disk, it isn't\nnecessary to re-compile functions everytime you stop and restart the interpreter.\nFunctions are compiled once and stored for future use.\n\n

              \nWhen inline(cpp_code) is called the following things happen:\n

                \n
              1. \n A fast local cache of functions is checked for the last function called for \n cpp_code. If an entry for cpp_code doesn't exist in the \n cache or the cached function call fails (perhaps because the function doesn't \n have compatible types) then the next step is to check the catalog. \n
              2. \n The catalog class also keeps an in-memory cache with a list of all the \n functions compiled for cpp_code. If cpp_code has\n ever been called, then this cache will be present (loaded from disk). If\n the cache isn't present, then it is loaded from disk.\n

                \n If the cache is present, each function in the cache is \n called until one is found that was compiled for the correct argument types. If \n none of the functions work, a new function is compiled with the given argument \n types. This function is written to the on-disk catalog as well as into the \n in-memory cache.

                \n
              3. \n When a lookup for cpp_code fails, the catalog looks through \n the on-disk function catalogs for the entries. The PYTHONCOMPILED variable \n determines where to search for these catalogs and in what order. If \n PYTHONCOMPILED is not present several platform dependent locations are \n searched. All functions found for cpp_code in the path are \n loaded into the in-memory cache with functions found earlier in the search \n path closer to the front of the call list.\n

                \n If the function isn't found in the on-disk catalog, \n then the function is compiled, written to the first writable directory in the \n PYTHONCOMPILED path, and also loaded into the in-memory cache.

                \n
                4. \n
              \n\n\n

              Function Storage: How functions are stored in caches and on disk

              \n

              \nFunction caches are stored as dictionaries where the key is the entire C++\ncode string and the value is either a single function (as in the \"level 1\"\ncache) or a list of functions (as in the main catalog cache). On disk\ncatalogs are stored in the same manor using standard Python shelves.\n

              \nEarly on, there was a question as to whether md5 check sums of the C++\ncode strings should be used instead of the actual code strings. I think this\nis the route inline Perl took. Some (admittedly quick) tests of the md5 vs.\nthe entire string showed that using the entire string was at least a\nfactor of 3 or 4 faster for Python. I think this is because it is more\ntime consuming to compute the md5 value than it is to do look-ups of long\nstrings in the dictionary. Look at the examples/md5_speed.py file for the\ntest run. \n\n\n

              Catalog search paths and the PYTHONCOMPILED variable

              \n

              \nThe default location for catalog files on Unix is is ~/.pythonXX_compiled where \nXX is version of Python being used. If this directory doesn't exist, it is \ncreated the first time a catalog is used. The directory must be writable. If, \nfor any reason it isn't, then the catalog attempts to create a directory based \non your user id in the /tmp directory. The directory permissions are set so \nthat only you have access to the directory. If this fails, I think you're out of \nluck. I don't think either of these should ever fail though. On Windows, a \ndirectory called pythonXX_compiled is created in the user's temporary \ndirectory. \n

              \nThe actual catalog file that lives in this directory is a Python shelve with\na platform specific name such as \"nt21compiled_catalog\" so that multiple OSes\ncan share the same file systems without trampling on each other. Along with\nthe catalog file, the .cpp and .so or .pyd files created by inline will live\nin this directory. The catalog file simply contains keys which are the C++\ncode strings with values that are lists of functions. The function lists point\nat functions within these compiled modules. Each function in the lists \nexecutes the same C++ code string, but compiled for different input variables.\n

              \nYou can use the PYTHONCOMPILED environment variable to specify alternative\nlocations for compiled functions. On Unix this is a colon (':') separated\nlist of directories. On windows, it is a (';') separated list of directories.\nThese directories will be searched prior to the default directory for a\ncompiled function catalog. Also, the first writable directory in the list\nis where all new compiled function catalogs, .cpp and .so or .pyd files are\nwritten. Relative directory paths ('.' and '..') should work fine in the\nPYTHONCOMPILED variable as should environement variables.\n

              \nThere is a \"special\" path variable called MODULE that can be placed in the \nPYTHONCOMPILED variable. It specifies that the compiled catalog should\nreside in the same directory as the module that called it. This is useful\nif an admin wants to build a lot of compiled functions during the build\nof a package and then install them in site-packages along with the package.\nUser's who specify MODULE in their PYTHONCOMPILED variable will have access\nto these compiled functions. Note, however, that if they call the function\nwith a set of argument types that it hasn't previously been built for, the\nnew function will be stored in their default directory (or some other writable\ndirectory in the PYTHONCOMPILED path) because the user will not have write\naccess to the site-packages directory.\n

              \nAn example of using the PYTHONCOMPILED path on bash follows:\n\n 

              \n    PYTHONCOMPILED=MODULE:/some/path;export PYTHONCOMPILED;\n
              \n\nIf you are using python21 on linux, and the module bob.py in site-packages\nhas a compiled function in it, then the catalog search order when calling that\nfunction for the first time in a python session would be:\n\n 
              \n    /usr/lib/python21/site-packages/linuxpython_compiled\n    /some/path/linuxpython_compiled\n    ~/.python21_compiled/linuxpython_compiled\n
              \n\nThe default location is always included in the search path.\n

              \n \nNote: hmmm. see a possible problem here. I should probably make a sub-\ndirectory such as /usr/lib/python21/site-\npackages/python21_compiled/linuxpython_compiled so that library files compiled \nwith python21 are tried to link with python22 files in some strange scenarios. \nNeed to check this.\n\n\n

              \nThe in-module cache (in weave.inline_tools reduces the overhead \nof calling inline functions by about a factor of 2. It can be reduced a little \nmore for type loop calls where the same function is called over and over again \nif the cache was a single value instead of a dictionary, but the benefit is \nvery small (less than 5%) and the utility is quite a bit less. So, we'll stick \nwith a dictionary as the cache.\n

              \n\n\n

              Blitz

              \n Note: most of this section is lifted from old documentation. It should be\npretty accurate, but there may be a few discrepancies.\n

              \nweave.blitz() compiles Numeric Python expressions for fast \nexecution. For most applications, compiled expressions should provide a \nfactor of 2-10 speed-up over Numeric arrays. Using compiled \nexpressions is meant to be as unobtrusive as possible and works much like \npythons exec statement. As an example, the following code fragment takes a 5 \npoint average of the 512x512 2d image, b, and stores it in array, a:\n\n 

              \n    from scipy import *  # or from Numeric import *\n    a = ones((512,512), Float64) \n    b = ones((512,512), Float64) \n    # ...do some stuff to fill in b...\n    # now average\n    a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] \\\n                   + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n
              \n \nTo compile the expression, convert the expression to a string by putting\nquotes around it and then use weave.blitz:\n\n 
              \n    import weave\n    expr = \"a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n                          \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n    weave.blitz(expr)\n
              \n\nThe first time weave.blitz is run for a given expression and \nset of arguements, C++ code that accomplishes the exact same task as the Python \nexpression is generated and compiled to an extension module. This can take up \nto a couple of minutes depending on the complexity of the function. Subsequent \ncalls to the function are very fast. Futher, the generated module is saved \nbetween program executions so that the compilation is only done once for a \ngiven expression and associated set of array types. If the given expression\nis executed with a new set of array types, the code most be compiled again. This\ndoes not overwrite the previously compiled function -- both of them are saved and\navailable for exectution. \n

              \nThe following table compares the run times for standard Numeric code and \ncompiled code for the 5 point averaging.\n

              \n

              \n\n\n\n\n\n
              Method Run Time (seconds)
              Standard Numeric 0.46349
              blitz (1st time compiling) 78.95526
              blitz (subsequent calls) 0.05843 (factor of 8 speedup)
              \n
              \n

              \nThese numbers are for a 512x512 double precision image run on a 400 MHz Celeron \nprocessor under RedHat Linux 6.2.\n

              \nBecause of the slow compile times, its probably most effective to develop \nalgorithms as you usually do using the capabilities of scipy or the Numeric \nmodule. Once the algorithm is perfected, put quotes around it and execute it \nusing weave.blitz. This provides the standard rapid \nprototyping strengths of Python and results in algorithms that run close to \nthat of hand coded C or Fortran.\n\n\n

              Requirements

              \n\nCurrently, the weave.blitz has only been tested under Linux \nwith gcc-2.95-3 and on Windows with Mingw32 (2.95.2). Its compiler \nrequirements are pretty heavy duty (see the \nblitz++ home page), so it won't \nwork with just any compiler. Particularly MSVC++ isn't up to snuff. A number \nof other compilers such as KAI++ will also work, but my suspicions are that gcc \nwill get the most use.\n\n\n

              Limitations

              \n
                \n
              1. \nCurrently, weave.blitz handles all standard mathematic \noperators except for the ** power operator. The built-in trigonmetric, log, \nfloor/ceil, and fabs functions might work (but haven't been tested). It also \nhandles all types of array indexing supported by the Numeric module. \n

                \nweave.blitz does not currently support operations that use \narray broadcasting, nor have any of the special purpose functions in Numeric \nsuch as take, compress, etc. been implemented. Note that there are no obvious \nreasons why most of this functionality cannot be added to scipy.weave, so it \nwill likely trickle into future versions. Using slice() objects \ndirectly instead of start:stop:step is also not supported.\n

                2. \n
              2. \nCurrently Python only works on expressions that include assignment such as\n \n 
                \n    >>> result = b + c + d\n
                \n\nThis means that the result array must exist before calling \nweave.blitz. Future versions will allow the following:\n\n 
                \n    >>> result = weave.blitz_eval(\"b + c + d\")\n
                \n
                3. \n
              3. \nweave.blitz works best when algorithms can be expressed in a \n\"vectorized\" form. Algorithms that have a large number of if/thens and other \nconditions are better hand written in C or Fortran. Further, the restrictions \nimposed by requiring vectorized expressions sometimes preclude the use of more \nefficient data structures or algorithms. For maximum speed in these cases, \nhand-coded C or Fortran code is the only way to go.\n
                4. \n
              4. \nOne other point deserves mention lest people be confused. \nweave.blitz is not a general purpose Python->C compiler. It \nonly works for expressions that contain Numeric arrays and/or \nPython scalar values. This focused scope concentrates effort on the \ncompuationally intensive regions of the program and sidesteps the difficult \nissues associated with a general purpose Python->C compiler.\n
                5. \n
              \n\n\n

              Numeric efficiency issues: What compilation buys you

              \n\nSome might wonder why compiling Numeric expressions to C++ is beneficial since \noperations on Numeric array operations are already executed within C loops. \nThe problem is that anything other than the simplest expression are executed in \nless than optimal fashion. Consider the following Numeric expression:\n\n 
              \n    a = 1.2 * b + c * d\n
              \n \nWhen Numeric calculates the value for the 2d array, a, it does \nthe following steps:\n\n 
              \n    temp1 = 1.2 * b\n    temp2 = c * d\n    a = temp1 + temp2\n
              \n \nTwo things to note. Since c is an (perhaps large) array, a large \ntemporary array must be created to store the results of 1.2 * b. \nThe same is true for temp2. Allocation is slow. The second thing \nis that we have 3 loops executing, one to calculate temp1, one for \ntemp2 and one for adding them up. A C loop for the same problem \nmight look like:\n\n 
              \n    for(int i = 0; i < M; i++)\n        for(int j = 0; j < N; j++)\n            a[i,j] = 1.2 * b[i,j] + c[i,j] * d[i,j]\n
              \n \nHere, the 3 loops have been fused into a single loop and there is no longer\na need for a temporary array. This provides a significant speed improvement\nover the above example (write me and tell me what you get). \n

              \nSo, converting Numeric expressions into C/C++ loops that fuse the loops and \neliminate temporary arrays can provide big gains. The goal then,is to convert \nNumeric expression to C/C++ loops, compile them in an extension module, and \nthen call the compiled extension function. The good news is that there is an \nobvious correspondence between the Numeric expression above and the C loop. The \nbad news is that Numeric is generally much more powerful than this simple \nexample illustrates and handling all possible indexing possibilities results in \nloops that are less than straight forward to write. (take a peak in Numeric for \nconfirmation). Luckily, there are several available tools that simplify the \nprocess.\n\n\n

              The Tools

              \n\nweave.blitz relies heavily on several remarkable tools. On the \nPython side, the main facilitators are Jermey Hylton's parser module and Jim \nHuginin's Numeric module. On the compiled language side, Todd Veldhuizen's \nblitz++ array library, written in C++ (shhhh. don't tell David Beazley), does \nthe heavy lifting. Don't assume that, because it's C++, it's much slower than C \nor Fortran. Blitz++ uses a jaw dropping array of template techniques \n(metaprogramming, template expression, etc) to convert innocent looking and \nreadable C++ expressions into to code that usually executes within a few \npercentage points of Fortran code for the same problem. This is good. \nUnfortunately all the template raz-ma-taz is very expensive to compile, so the \n200 line extension modules often take 2 or more minutes to compile. This isn't so \ngood. weave.blitz works to minimize this issue by remembering \nwhere compiled modules live and reusing them instead of re-compiling every time \na program is re-run.\n\n\n

              Parser

              \nTearing Numeric expressions apart, examining the pieces, and then rebuilding \nthem as C++ (blitz) expressions requires a parser of some sort. I can imagine \nsomeone attacking this problem with regular expressions, but it'd likely be \nugly and fragile. Amazingly, Python solves this problem for us. It actually \nexposes its parsing engine to the world through the parser module. \nThe following fragment creates an Abstract Syntax Tree (AST) object for the \nexpression and then converts to a (rather unpleasant looking) deeply nested list \nrepresentation of the tree. \n \n 
              \n    >>> import parser\n    >>> import scipy.weave.misc\n    >>> ast = parser.suite(\"a = b * c + d\")\n    >>> ast_list = ast.tolist()\n    >>> sym_list = scipy.weave.misc.translate_symbols(ast_list)\n    >>> pprint.pprint(sym_list)\n    ['file_input',\n     ['stmt',\n      ['simple_stmt',\n       ['small_stmt',\n        ['expr_stmt',\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'a']]]]]]]]]]]]]]],\n         ['EQUAL', '='],\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'b']]]],\n                    ['STAR', '*'],\n                    ['factor', ['power', ['atom', ['NAME', 'c']]]]],\n                   ['PLUS', '+'],\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'd']]]]]]]]]]]]]]]]],\n       ['NEWLINE', '']]],\n     ['ENDMARKER', '']]\n
              \n\nDespite its looks, with some tools developed by Jermey H., its possible\nto search these trees for specific patterns (sub-trees), extract the \nsub-tree, manipulate them converting python specific code fragments\nto blitz code fragments, and then re-insert it in the parse tree. The parser\nmodule documentation has some details on how to do this. Traversing the \nnew blitzified tree, writing out the terminal symbols as you go, creates\nour new blitz++ expression string.\n\n \n

              Blitz and Numeric

              \nThe other nice discovery in the project is that the data structure used\nfor Numeric arrays and blitz arrays is nearly identical. Numeric stores\n\"strides\" as byte offsets and blitz stores them as element offsets, but\nother than that, they are the same. Further, most of the concept and\ncapabilities of the two libraries are remarkably similar. It is satisfying \nthat two completely different implementations solved the problem with \nsimilar basic architectures. It is also fortitous. The work involved in \nconverting Numeric expressions to blitz expressions was greatly diminished.\nAs an example, consider the code for slicing an array in Python with a\nstride:\n\n 
              \n    >>> a = b[0:4:2] + c\n    >>> a\n    [0,2,4]\n
              \n\n\nIn Blitz it is as follows:\n\n 
              \n    Array<2,int> b(10);\n    Array<2,int> c(3);\n    // ...\n    Array<2,int> a = b(Range(0,3,2)) + c;\n
              \n\n\nHere the range object works exactly like Python slice objects with the exception\nthat the top index (3) is inclusive where as Python's (4) is exclusive. Other \ndifferences include the type declaraions in C++ and parentheses instead of \nbrackets for indexing arrays. Currently, weave.blitz handles the \ninclusive/exclusive issue by subtracting one from upper indices during the\ntranslation. An alternative that is likely more robust/maintainable in the \nlong run, is to write a PyRange class that behaves like Python's range. \nThis is likely very easy.\n

              \nThe stock blitz also doesn't handle negative indices in ranges. The current \nimplementation of the blitz() has a partial solution to this \nproblem. It calculates and index that starts with a '-' sign by subtracting it \nfrom the maximum index in the array so that:\n\n 

              \n                    upper index limit\n                        /-----\\\n    b[:-1] -> b(Range(0,Nb[0]-1-1))\n
              \n\nThis approach fails, however, when the top index is calculated from other \nvalues. In the following scenario, if i+j evaluates to a negative \nvalue, the compiled code will produce incorrect results and could even core-\ndump. Right now, all calculated indices are assumed to be positive.\n \n 
              \n    b[:i-j] -> b(Range(0,i+j))\n
              \n\nA solution is to calculate all indices up front using if/then to handle the\n+/- cases. This is a little work and results in more code, so it hasn't been\ndone. I'm holding out to see if blitz++ can be modified to handle negative\nindexing, but haven't looked into how much effort is involved yet. While it \nneeds fixin', I don't think there is a ton of code where this is an issue.\n

              \nThe actual translation of the Python expressions to blitz expressions is \ncurrently a two part process. First, all x:y:z slicing expression are removed\nfrom the AST, converted to slice(x,y,z) and re-inserted into the tree. Any\nmath needed on these expressions (subtracting from the \nmaximum index, etc.) are also preformed here. _beg and _end are used as special\nvariables that are defined as blitz::fromBegin and blitz::toEnd.\n\n 

              \n    a[i+j:i+j+1,:] = b[2:3,:] \n
              \n\nbecomes a more verbose:\n \n 
              \n    a[slice(i+j,i+j+1),slice(_beg,_end)] = b[slice(2,3),slice(_beg,_end)]\n
              \n \nThe second part does a simple string search/replace to convert to a blitz \nexpression with the following translations:\n\n 
              \n    slice(_beg,_end) -> _all  # not strictly needed, but cuts down on code.\n    slice            -> blitz::Range\n    [                -> (\n    ]                -> )\n    _stp             -> 1\n
              \n\n_all is defined in the compiled function as \nblitz::Range.all(). These translations could of course happen \ndirectly in the syntax tree. But the string replacement is slightly easier. \nNote that name spaces are maintained in the C++ code to lessen the likelyhood \nof name clashes. Currently no effort is made to detect name clashes. A good \nrule of thumb is don't use values that start with '_' or 'py_' in compiled \nexpressions and you'll be fine.\n\n \n

              Type definitions and coersion

              \n\nSo far we've glossed over the dynamic vs. static typing issue between Python \nand C++. In Python, the type of value that a variable holds can change\nthrough the course of program execution. C/C++, on the other hand, forces you\nto declare the type of value a variables will hold prior at compile time.\nweave.blitz handles this issue by examining the types of the\nvariables in the expression being executed, and compiling a function for those\nexplicit types. For example:\n\n 
              \n    a = ones((5,5),Float32)\n    b = ones((5,5),Float32)\n    weave.blitz(\"a = a + b\")\n
              \n\nWhen compiling this expression to C++, weave.blitz sees that the\nvalues for a and b in the local scope have type Float32, or 'float'\non a 32 bit architecture. As a result, it compiles the function using \nthe float type (no attempt has been made to deal with 64 bit issues).\nIt also goes one step further. If all arrays have the same type, a templated\nversion of the function is made and instantiated for float, double, \ncomplex, and complex arrays. Note: This feature has been \nremoved from the current version of the code. Each version will be compiled\nseparately \n

              \nWhat happens if you call a compiled function with array types that are \ndifferent than the ones for which it was originally compiled? No biggie, you'll \njust have to wait on it to compile a new version for your new types. This \ndoesn't overwrite the old functions, as they are still accessible. See the \ncatalog section in the inline() documentation to see how this is handled. \nSuffice to say, the mechanism is transparent to the user and behaves \nlike dynamic typing with the occasional wait for compiling newly typed \nfunctions.\n

              \nWhen working with combined scalar/array operations, the type of the array is \nalways used. This is similar to the savespace flag that was recently \nadded to Numeric. This prevents issues with the following expression perhaps \nunexpectedly being calculated at a higher (more expensive) precision that can \noccur in Python:\n\n 

              \n    >>> a = array((1,2,3),typecode = Float32)\n    >>> b = a * 2.1 # results in b being a Float64 array.\n
              \n \nIn this example, \n\n 
              \n    >>> a = ones((5,5),Float32)\n    >>> b = ones((5,5),Float32)\n    >>> weave.blitz(\"b = a * 2.1\")\n
              \n \nthe 2.1 is cast down to a float before carrying out \nthe operation. If you really want to force the calculation to be a \ndouble, define a and b as \ndouble arrays.\n

              \nOne other point of note. Currently, you must include both the right hand side \nand left hand side (assignment side) of your equation in the compiled \nexpression. Also, the array being assigned to must be created prior to calling \nweave.blitz. I'm pretty sure this is easily changed so that a \ncompiled_eval expression can be defined, but no effort has been made to \nallocate new arrays (and decern their type) on the fly.\n\n \n

              Cataloging Compiled Functions

              \n\nSee the Cataloging functions section in the \nweave.inline() documentation.\n\n \n

              Checking Array Sizes

              \n\nSurprisingly, one of the big initial problems with compiled code was making\nsure all the arrays in an operation were of compatible type. The following\ncase is trivially easy:\n\n 
              \n    a = b + c\n
              \n \nIt only requires that arrays a, b, and c \nhave the same shape. However, expressions like:\n\n 
              \n    a[i+j:i+j+1,:] = b[2:3,:] + c\n
              \n\nare not so trivial. Since slicing is involved, the size of the slices, not the \ninput arrays must be checked. Broadcasting complicates things further because \narrays and slices with different dimensions and shapes may be compatible for \nmath operations (broadcasting isn't yet supported by \nweave.blitz). Reductions have a similar effect as their \nresults are different shapes than their input operand. The binary operators in \nNumeric compare the shapes of their two operands just before they operate on \nthem. This is possible because Numeric treats each operation independently. \nThe intermediate (temporary) arrays created during sub-operations in an \nexpression are tested for the correct shape before they are combined by another \noperation. Because weave.blitz fuses all operations into a \nsingle loop, this isn't possible. The shape comparisons must be done and \nguaranteed compatible before evaluating the expression.\n

              \nThe solution chosen converts input arrays to \"dummy arrays\" that only represent \nthe dimensions of the arrays, not the data. Binary operations on dummy arrays \ncheck that input array sizes are comptible and return a dummy array with the \nsize correct size. Evaluating an expression of dummy arrays traces the \nchanging array sizes through all operations and fails if incompatible array \nsizes are ever found. \n

              \nThe machinery for this is housed in weave.size_check. It \nbasically involves writing a new class (dummy array) and overloading it math \noperators to calculate the new sizes correctly. All the code is in Python and \nthere is a fair amount of logic (mainly to handle indexing and slicing) so the \noperation does impose some overhead. For large arrays (ie. 50x50x50), the \noverhead is negligible compared to evaluating the actual expression. For small \narrays (ie. 16x16), the overhead imposed for checking the shapes with this \nmethod can cause the weave.blitz to be slower than evaluating \nthe expression in Python. \n

              \nWhat can be done to reduce the overhead? (1) The size checking code could be \nmoved into C. This would likely remove most of the overhead penalty compared \nto Numeric (although there is also some calling overhead), but no effort has \nbeen made to do this. (2) You can also call weave.blitz with\ncheck_size=0 and the size checking isn't done. However, if the \nsizes aren't compatible, it can cause a core-dump. So, foregoing size_checking\nisn't advisable until your code is well debugged.\n\n \n

              Creating the Extension Module

              \n\nweave.blitz uses the same machinery as \nweave.inline to build the extension module. The only difference\nis the code included in the function is automatically generated from the\nNumeric array expression instead of supplied by the user.\n\n\n

              Extension Modules

              \nweave.inline and weave.blitz are high level tools\nthat generate extension modules automatically. Under the covers, they use several\nclasses from weave.ext_tools to help generate the extension module.\nThe main two classes are ext_module and ext_function (I'd\nlike to add ext_class and ext_method also). These classes\nsimplify the process of generating extension modules by handling most of the \"boiler\nplate\" code automatically.\n\n\nNote: inline actually sub-classes weave.ext_tools.ext_function \nto generate slightly different code than the standard ext_function.\nThe main difference is that the standard class converts function arguments to\nC types, while inline always has two arguments, the local and global dicts, and\nthe grabs the variables that need to be convereted to C from these.\n\n\n\n

              A Simple Example

              \nThe following simple example demonstrates how to build an extension module within\na Python function:\n\n 
              \n    # examples/increment_example.py\n    from weave import ext_tools\n    \n    def build_increment_ext():\n        \"\"\" Build a simple extension with functions that increment numbers.\n            The extension will be built in the local directory.\n        \"\"\"        \n        mod = ext_tools.ext_module('increment_ext')\n    \n        a = 1 # effectively a type declaration for 'a' in the \n              # following functions.\n    \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n        mod.add_function(func)\n        \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+2));\"    \n        func = ext_tools.ext_function('increment_by_2',ext_code,['a'])\n        mod.add_function(func)\n                \n        mod.compile()\n
              \n\n\nThe function build_increment_ext() creates an extension module \nnamed increment_ext and compiles it to a shared library (.so or \n.pyd) that can be loaded into Python.. increment_ext contains two \nfunctions, increment and increment_by_2. \n\nThe first line of build_increment_ext(),\n\n 
              \n        mod = ext_tools.ext_module('increment_ext') \n
              \n\ncreates an ext_module instance that is ready to have \next_function instances added to it. ext_function \ninstances are created much with a calling convention similar to \nweave.inline(). The most common call includes a C/C++ code \nsnippet and a list of the arguments for the function. The following\n\n 
              \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n
              \n \ncreates a C/C++ extension function that is equivalent to the following Python\nfunction:\n\n 
              \n        def increment(a):\n            return a + 1\n
              \n\nA second method is also added to the module and then,\n\n 
              \n        mod.compile()\n
              \n\nis called to build the extension module. By default, the module is created\nin the current working directory.\n\nThis example is available in the examples/increment_example.py file\nfound in the weave directory. At the bottom of the file in the\nmodule's \"main\" program, an attempt to import increment_ext without\nbuilding it is made. If this fails (the module doesn't exist in the PYTHONPATH), \nthe module is built by calling build_increment_ext(). This approach\nonly takes the time consuming ( a few seconds for this example) process of building\nthe module if it hasn't been built before.\n\n 
              \n    if __name__ == \"__main__\":\n        try:\n            import increment_ext\n        except ImportError:\n            build_increment_ext()\n            import increment_ext\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\n\nNote: If we were willing to always pay the penalty of building the C++ code for \na module, we could store the md5 checksum of the C++ code along with some \ninformation about the compiler, platform, etc. Then, \next_module.compile() could try importing the module before it actually\ncompiles it, check the md5 checksum and other meta-data in the imported module\nwith the meta-data of the code it just produced and only compile the code if\nthe module didn't exist or the meta-data didn't match. This would reduce the\nabove code to:\n\n 
              \n    if __name__ == \"__main__\":\n        build_increment_ext()\n\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\nNote: There would always be the overhead of building the C++ code, but it would only actually compile the code once. You pay a little in overhead and get cleaner\n\"import\" code. Needs some thought.\n\n

              \n\nIf you run increment_example.py from the command line, you get\nthe following:\n\n 

              \n    [eric@n0]$ python increment_example.py\n    a, a+1: 1 2\n    a, a+2: 1 3\n
              \n\nIf the module didn't exist before it was run, the module is created. If it did\nexist, it is just imported and used.\n\n\n

              Fibonacci Example

              \nexamples/fibonacci.py provides a little more complex example of \nhow to use ext_tools. Fibonacci numbers are a series of numbers \nwhere each number in the series is the sum of the previous two: 1, 1, 2, 3, 5, \n8, etc. Here, the first two numbers in the series are taken to be 1. One \napproach to calculating Fibonacci numbers uses recursive function calls. In \nPython, it might be written as:\n\n 
              \n    def fib(a):\n        if a <= 2:\n            return 1\n        else:\n            return fib(a-2) + fib(a-1)\n
              \n\nIn C, the same function would look something like this:\n\n 
              \n     int fib(int a)\n     {                   \n         if(a <= 2)\n             return 1;\n         else\n             return fib(a-2) + fib(a-1);  \n     }                      \n
              \n\nRecursion is much faster in C than in Python, so it would be beneficial\nto use the C version for fibonacci number calculations instead of the\nPython version. We need an extension function that calls this C function\nto do this. This is possible by including the above code snippet as \n\"support code\" and then calling it from the extension function. Support \ncode snippets (usually structure definitions, helper functions and the like)\nare inserted into the extension module C/C++ file before the extension\nfunction code. Here is how to build the C version of the fibonacci number\ngenerator:\n\n 
              \ndef build_fibonacci():\n    \"\"\" Builds an extension module with fibonacci calculators.\n    \"\"\"\n    mod = ext_tools.ext_module('fibonacci_ext')\n    a = 1 # this is effectively a type declaration\n    \n    # recursive fibonacci in C \n    fib_code = \"\"\"\n                   int fib1(int a)\n                   {                   \n                       if(a <= 2)\n                           return 1;\n                       else\n                           return fib1(a-2) + fib1(a-1);  \n                   }                         \n               \"\"\"\n    ext_code = \"\"\"\n                   int val = fib1(a);\n                   return_val = Py::new_reference_to(Py::Int(val));\n               \"\"\"    \n    fib = ext_tools.ext_function('fib',ext_code,['a'])\n    fib.customize.add_support_code(fib_code)\n    mod.add_function(fib)\n\n    mod.compile()\n\n
              \n\nXXX More about custom_info, and what xxx_info instances are good for.\n\n

              \n\nNote: recursion is not the fastest way to calculate fibonacci numbers, but this \napproach serves nicely for this example.\n\n

              \n\n

              Customizing Type Conversions -- Type Factories

              \nnot written\n\n

              Things I wish weave did

              \n\nIt is possible to get name clashes if you uses a variable name that is already defined\nin a header automatically included (such as stdio.h) For instance, if you\ntry to pass in a variable named stdout, you'll get a cryptic error report\ndue to the fact that stdio.h also defines the name. weave\nshould probably try and handle this in some way.\n\nOther things...", "source_code_before": "\n

              Weave Documentation

              \n

              \nBy Eric Jones eric@enthought.com\n

              \n

              Outline

              \n
              \n
              Introduction\n
              Requirements\n
              Installation\n
              Testing\n
              Benchmarks\n
              Inline\n
              \n
              More with printf\n
              \n More examples\n
              \n
              Binary search\n
              Dictionary sort\n
              Numeric -- cast/copy/transpose\n
              wxPython
              \n
              \n
              Keyword options\n
              Returning values\n
              \n
              \n The issue with locals()
              \n
              \n
              A quick look at the code\n
              \n Technical Details\n
              \n
              Converting Types\n
              \n
              \n Numeric Argument Conversion\n
              \n String, List, Tuple, and Dictionary Conversion\n
              File Conversion \n
              \n Callable, Instance, and Module Conversion \n
              Customizing Conversions\n
              \n
              Compiling Code\n
              \"Cataloging\" functions\n
              \n
              Function Storage\n
              The PYTHONCOMPILED evnironment variable
              \n
              \n
              \n
              \n
              \n
              \n
              Blitz\n
              \n
              Requirements\n
              Limitations\n
              Numeric Efficiency Issues\n
              The Tools \n
              \n
              Parser\n
              Blitz and Numeric\n
              \n
              Type defintions and coersion\n
              Cataloging Compiled Functions\n
              Checking Array Sizes\n
              Creating the Extension Module\n
              \n
              Extension Modules\n
              \n
              A Simple Example\n
              Fibonacci Example\n
              \n
              Customizing Type Conversions -- Type Factories (not written)\n
              \n
              Type Specifications\n
              Type Information\n
              The Conversion Process \n
              \n
              \n\n

              Introduction

              \n\n

              \nThe weave package provides tools for including C/C++ code within\nin Python code. This offers both another level of optimization to those who need \nit, and an easy way to modify and extend any supported extension libraries such \nas wxPython and hopefully VTK soon. Inlining C/C++ code within Python generally\nresults in speed ups of 1.5x to 30x speed-up over algorithms written in pure\nPython (However, it is also possible to slow things down...). Generally \nalgorithms that require a large number of calls to the Python API don't benefit\nas much from the conversion to C/C++ as algorithms that have inner loops \ncompletely convertable to C.\n

              \nThere are three basic ways to use weave. The \nweave.inline() function executes C code directly within Python, \nand weave.blitz() translates Python Numeric expressions to C++ \nfor fast execution. blitz() was the original reason \nweave was built. For those interested in building extension\nlibraries, the ext_tools module provides classes for building \nextension modules within Python. \n

              \nMost of weave's functionality should work on Windows and Unix, \nalthough some of its functionality requires gcc or a similarly \nmodern C++ compiler that handles templates well. Up to now, most testing has \nbeen done on Windows 2000 with Microsoft's C++ compiler (MSVC) and with gcc \n(mingw32 2.95.2 and 2.95.3-6). All tests also pass on Linux (RH 7.1 \nwith gcc 2.96), and I've had reports that it works on Debian also (thanks \nPearu).\n

              \nThe inline and blitz provide new functionality to \nPython (although I've recently learned about the PyInline project which may offer \nsimilar functionality to inline). On the other hand, tools for \nbuilding Python extension modules already exists (SWIG, SIP, pycpp, CXX, and \nothers). As of yet, I'm not sure where weave fits in this \nspectrum. It is closest in flavor to CXX in that it makes creating new C/C++ \nextension modules pretty easy. However, if you're wrapping a gaggle of legacy \nfunctions or classes, SWIG and friends are definitely the better choice. \nweave is set up so that you can customize how Python types are \nconverted to C types in weave. This is great for \ninline(), but, for wrapping legacy code, it is more flexible to \nspecify things the other way around -- that is how C types map to Python types. \nThis weave does not do. I guess it would be possible to build \nsuch a tool on top of weave, but with good tools like SWIG around, \nI'm not sure the effort produces any new capabilities. Things like function \noverloading are probably easily implemented in weave and it might \nbe easier to mix Python/C code in function calls, but nothing beyond this comes \nto mind. So, if you're developing new extension modules or optimizing Python \nfunctions in C, weave.ext_tools() might be the tool \nfor you. If you're wrapping legacy code, stick with SWIG.\n

              \nThe next several sections give the basics of how to use weave.\nWe'll discuss what's happening under the covers in more detail later \non. Serious users will need to at least look at the type conversion section to \nunderstand how Python variables map to C/C++ types and how to customize this \nbehavior. One other note. If you don't know C or C++ then these docs are \nprobably of very little help to you. Further, it'd be helpful if you know \nsomething about writing Python extensions. weave does quite a \nbit for you, but for anything complex, you'll need to do some conversions, \nreference counting, etc.\n

              \n\nNote: weave is actually part of the SciPy package. However, it works fine as a \nstandalone package. The examples here are given as if it is used as a stand \nalone package. If you are using from within scipy, you can use from \nscipy import weave and the examples will work identically.\n\n\n

              Requirements

              \n
                \n
              • Python\n

                \n I use 2.1.1. Probably 2.0 or higher should work.\n

                \n

                • \n \n
              • C++ compiler\n

                \n weave uses distutils to actually build \n extension modules, so it uses whatever compiler was originally used to \n build Python. weave itself requires a C++ compiler. If \n you used a C++ compiler to build Python, your probably fine.\n

                \n On Unix gcc is the preferred choice because I've done a little \n testing with it. All testing has been done with gcc, but I expect the \n majority of compilers should work for inline and \n ext_tools. The one issue I'm not sure about is that I've \n hard coded things so that compilations are linked with the \n stdc++ library. Is this standard across \n Unix compilers, or is this a gcc-ism?\n

                \n For blitz(), you'll need a reasonably recent version of \n gcc. 2.95.2 works on windows and 2.96 looks fine on Linux. Other \n versions are likely to work. Its likely that KAI's C++ compiler and \n maybe some others will work, but I haven't tried. My advice is to use \n gcc for now unless your willing to tinker with the code some.\n

                \n On Windows, either MSVC or gcc (www.mingw.org\" > mingw32) should work. Again, \n you'll need gcc for blitz() as the\n MSVC compiler doesn't handle templates well.\n

                \n I have not tried Cygwin, so please report success if it works for you.\n

                \n

                • \n\n
              • Numeric (optional)\n

                \n The python Numeric module from here. is required for \n blitz() to work. Be sure and get NumPy, not NumArray\n which is the \"next generation\" implementation. This is not\n required for using inline() or ext_tools.\n

                \n

                • \n
              • scipy_distutils and scipy_test (packaged with weave)\n

                \n These two modules are packaged with weave in both\n the windows installer and the source distributions. If you are using\n CVS, however, you'll need to download these separately (also available\n through CVS at SciPy).\n

                \n

                • \n
              \n

              \n\n\n

              Installation

              \n

              \nThere are currently two ways to get weave. Fist, \nweave is part of SciPy and installed automatically (as a sub-\npackage) whenever SciPy is installed (although the latest version isn't in \nSciPy yet, so use this one for now). Second, since weave is \nuseful outside of the scientific community, it has been setup so that it can be\nused as a stand-alone module. \n\n

              \nThe stand-alone version can be downloaded from here. Unix users should grab the \ntar ball (.tgz file) and install it using the following commands.\n\n 

              \n    tar -xzvf weave-0.2.tar.gz\n    cd weave-0.2\n    python setup.py install\n
              \n\nThis will also install two other packages, scipy_distutils and \nscipy_test. The first is needed by the setup process itself and \nboth are used in the unit-testing process. Numeric is required if you want to \nuse blitz(), but isn't necessary for inline() or \next_tools\n

              \nFor Windows users, it's even easier. You can download the click-install .exe \nfile and run it for automatic installation. There is also a .zip file of the\nsource for those interested. It also includes a setup.py file to simplify\ninstallation. \n

              \nIf you're using the CVS version, you'll need to install \nscipy_distutils and scipy_test packages (also \navailable from CVS) on your own.\n

              \n \nNote: The dependency issue here is a little sticky. I hate to make people \ndownload more than one file (and so I haven't), but distutils doesn't have a \nway to do conditional installation -- at least that I know about. This can \nlead to undesired clobbering of the scipy_test and scipy_distutils modules. \nWhat to do, what to do... Right now it is a very minor issue.\n\n

              \n\n

              Testing

              \nOnce weave is installed, fire up python and run its unit tests.\n\n 
              \n    >>> import weave\n    >>> weave.test()\n    runs long time... spews tons of output and a few warnings\n    .\n    .\n    .\n    ..............................................................\n    ................................................................\n    ..................................................\n    ----------------------------------------------------------------------\n    Ran 184 tests in 158.418s\n\n    OK\n    \n    >>> \n
              \n\nThis takes a loooong time. On windows, it is usually several minutes. On Unix \nwith remote file systems, I've had it take 15 or so minutes. In the end, it \nshould run about 180 tests and spew some speed results along the way. If you \nget errors, they'll be reported at the end of the output. Please let me know\nwhat if this occurs.\n\nIf you don't have Numeric installed, you'll get some module import errors \nduring the test setup phase for modules that are Numeric specific (blitz_spec, \nblitz_tools, size_check, standard_array_spec, ast_tools), but all test should\npass (about 100 and they should complete in several minutes).\n

              \nIf you only want to test a single module of the package, you can do this by\nrunning test() for that specific module.\n\n 

              \n    >>> import weave.scalar_spec\n    >>> weave.scalar_spec.test()\n    .......\n    ----------------------------------------------------------------------\n    Ran 7 tests in 23.284s\n
              \n\nTesting Notes:\n
                \n
              • \n Windows 1\n

                \n I've had some test fail on windows machines where I have msvc, gcc-2.95.2 \n (in c:\\gcc-2.95.2), and gcc-2.95.3-6 (in c:\\gcc) all installed. My \n environment has c:\\gcc in the path and does not have c:\\gcc-2.95.2 in the \n path. The test process runs very smoothly until the end where several test \n using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') \n before running tests, I get gcc-2.95.3-6. If I check after running tests \n (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] \n still has c:\\gcc first in it and is not corrupted (msvc/distutils messes \n with the environment variables, so we have to undo its work in some \n places). If anyone else sees this, let me know - - it may just be an quirk \n on my machine (unlikely). Testing with the gcc- 2.95.2 installation always \n works.\n

                \n

                • \n
              • \n Windows 2\n

                \n If you run the tests from PythonWin or some other GUI tool, you'll get a\n ton of DOS windows popping up periodically as weave spawns\n the compiler multiple times. Very annoying. Anyone know how to fix this?\n

                \n

                • \n
              • \n wxPython\n

                \n wxPython tests are not enabled by default because importing wxPython on a \n Unix machine without access to a X-term will cause the program to exit. \n Anyone know of a safe way to detect whether wxPython can be imported and \n whether a display exists on a machine? \n

                \n

                • \n                \n\n

                \n

              \n\n\n

              Benchmarks

              \nThis section has a few benchmarks -- thats all people want to see anyway right? \nThese are mostly taken from running files in the weave/example \ndirectory and also from the test scripts. Without more information about what \nthe test actually do, their value is limited. Still, their here for the \ncurious. Look at the example scripts for more specifics about what problem was \nactually solved by each run. These examples are run under windows 2000 using \nMicrosoft Visual C++ and python2.1 on a 850 MHz PIII laptop with 320 MB of RAM.\nSpeed up is the improvement (degredation) factor of weave compared to \nconventional Python functions. The blitz() comparisons are shown\ncompared to Numeric.\n

              \n

              \n\n\n \n \n \n \n \n \n \n \n\n \n \n \n \n \n \nThe benchmarks shown blitz in the best possible light. Numeric \n(at least on my machine) is significantly worse for double precision than it is \nfor single precision calculations. If your interested in single precision \nresults, you can pretty much divide the double precision speed up by 3 and you'll\nbe close.\n\n
              \n

              inline and ext_tools

              Algorithm

              Speed up

              binary search   1.50
              fibonacci (recursive)  82.10
              fibonacci (loop)   9.17
              return None   0.14
              map   1.20
              dictionary sort   2.54
              vector quantization  37.40
              \n

              blitz -- double precision

              Algorithm

              Speed up

              a = b + c 512x512   3.05
              a = b + c + d 512x512   4.59
              5 pt avg. filter, 2D Image 512x512   9.01
              Electromagnetics (FDTD) 100x100x100   8.61
              \n
              \n

              \n\n

              Inline

              \n

              \ninline() compiles and executes C/C++ code on the fly. Variables \nin the local and global Python scope are also available in the C/C++ code. \nValues are passed to the C/C++ code by assignment much like variables \nare passed into a standard Python function. Values are returned from the C/C++ \ncode through a special argument called return_val. Also, the contents of \nmutable objects can be changed within the C/C++ code and the changes remain \nafter the C code exits and returns to Python. (more on this later)\n

              \nHere's a trivial printf example using inline():\n\n 

              \n    >>> import weave    \n    >>> a  = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n

              \nIn this, its most basic form, inline(c_code, var_list) requires two \narguments. c_code is a string of valid C/C++ code. \nvar_list is a list of variable names that are passed from \nPython into C/C++. Here we have a simple printf statement that \nwrites the Python variable a to the screen. The first time you run \nthis, there will be a pause while the code is written to a .cpp file, compiled \ninto an extension module, loaded into Python, cataloged for future use, and \nexecuted. On windows (850 MHz PIII), this takes about 1.5 seconds when using \nMicrosoft's C++ compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). \nAll subsequent executions of the code will happen very quickly because the code \nonly needs to be compiled once. If you kill and restart the interpreter and then \nexecute the same code fragment again, there will be a much shorter delay in the \nfractions of seconds range. This is because weave stores a \ncatalog of all previously compiled functions in an on disk cache. When it sees \na string that has been compiled, it loads the already compiled module and \nexecutes the appropriate function. \n

              \n\nNote: If you try the printf example in a GUI shell such as IDLE, \nPythonWin, PyShell, etc., you're unlikely to see the output. This is because the \nC code is writing to stdout, instead of to the GUI window. This doesn't mean \nthat inline doesn't work in these environments -- it only means that standard \nout in C is not the same as the standard out for Python in these cases. Non \ninput/output functions will work as expected.\n\n

              \nAlthough effort has been made to reduce the overhead associated with calling \ninline, it is still less efficient for simple code snippets than using \nequivalent Python code. The simple printf example is actually \nslower by 30% or so than using Python print statement. And, it is \nnot difficult to create code fragments that are 8-10 times slower using inline \nthan equivalent Python. However, for more complicated algorithms, \nthe speed up can be worth while -- anywhwere from 1.5- 30 times faster. \nAlgorithms that have to manipulate Python objects (sorting a list) usually only \nsee a factor of 2 or so improvement. Algorithms that are highly computational \nor manipulate Numeric arrays can see much larger improvements. The \nexamples/vq.py file shows a factor of 30 or more improvement on the vector \nquantization algorithm that is used heavily in information theory and \nclassification problems.\n

              \n\n\n

              More with printf

              \n

              \nMSVC users will actually see a bit of compiler output that distutils does not\nsupress the first time the code executes:\n\n 

                  \n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    sc_e013937dbc8c647ac62438874e5795131.cpp\n       Creating library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\n       \\Release\\sc_e013937dbc8c647ac62438874e5795131.lib and object C:\\DOCUME\n       ~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_e013937dbc8c64\n       7ac62438874e5795131.exp\n    1\n
              \n

              \nNothing bad is happening, its just a bit annoying. Anyone know how to \nturn this off? \n

              \nThis example also demonstrates using 'raw strings'. The r \npreceeding the code string in the last example denotes that this is a 'raw \nstring'. In raw strings, the backslash character is not interpreted as an \nescape character, and so it isn't necessary to use a double backslash to \nindicate that the '\\n' is meant to be interpreted in the C printf \nstatement instead of by Python. If your C code contains a lot\nof strings and control characters, raw strings might make things easier.\nMost of the time, however, standard strings work just as well.\n\n

              \nThe printf statement in these examples is formatted to print \nout integers. What happens if a is a string? inline\nwill happily, compile a new version of the code to accept strings as input,\nand execute the code. The result?\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    32956972\n
              \n

              \nIn this case, the result is non-sensical, but also non-fatal. In other \nsituations, it might produce a compile time error because a is \nrequired to be an integer at some point in the code, or it could produce a \nsegmentation fault. Its possible to protect against passing \ninline arguments of the wrong data type by using asserts in \nPython.\n\n 

                  \n    >>> a = 'string'\n    >>> def protected_printf(a):    \n    ...     assert(type(a) == type(1))\n    ...     weave.inline(r'printf(\"%d\\n\",a);',['a'])\n    >>> protected_printf(1)\n     1\n    >>> protected_printf('string')\n    AssertError...\n
              \n\n

              \nFor printing strings, the format statement needs to be changed.\n\n 

                  \n    >>> a = 'string'\n    >>> weave.inline(r'printf(\"%s\\n\",a);',['a'])\n    string\n
              \n\n

              \nAs in this case, C/C++ code fragments often have to change to accept different \ntypes. For the given printing task, however, C++ streams provide a way of a \nsingle statement that works for integers and strings. By default, the stream \nobjects live in the std (standard) namespace and thus require the use of \nstd::.\n\n 

                  \n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    1    \n    >>> a = 'string'\n    >>> weave.inline('std::cout << a << std::endl;',['a'])\n    string\n
              \n \n

              \nExamples using printf and cout are included in \nexamples/print_example.py.\n\n\n

              More examples

              \n\nThis section shows several more advanced uses of inline. It \nincludes a few algorithms from the Python Cookbook \nthat have been re-written in inline C to improve speed as well as a couple \nexamples using Numeric and wxPython.\n\n\n

              Binary search

              \nLets look at the example of searching a sorted list of integers for a value. \nFor inspiration, we'll use Kalle Svensson's \nbinary_search() algorithm from the Python Cookbook. His recipe follows:\n\n 
              \n    def binary_search(seq, t):\n        min = 0; max = len(seq) - 1\n        while 1:\n            if max < min:\n                return -1\n            m = (min  + max)  / 2\n            if seq[m] < t: \n                min = m  + 1 \n            elif seq[m] > t: \n                max = m  - 1 \n            else:\n                return m    \n
              \n\nThis Python version works for arbitrary Python data types. The C version below is \nspecialized to handle integer values. There is a little type checking done in \nPython to assure that we're working with the correct data types before heading \ninto C. The variables seq and t don't need to be \ndeclared beacuse weave handles converting and declaring them in \nthe C code. All other temporary variables such as min, max, etc. \nmust be declared -- it is C after all. Here's the new mixed Python/C function:\n\n 
                  \n    def c_int_binary_search(seq,t):\n        # do a little type checking in Python\n        assert(type(t) == type(1))\n        assert(type(seq) == type([]))\n        \n        # now the C code\n        code = \"\"\"\n               #line 29 \"binary_search.py\"\n               int val, m, min = 0;  \n               int max = seq.length() - 1;\n               PyObject *py_val; \n               for(;;)\n               {\n                   if (max < min  ) \n                   { \n                       return_val =  Py::new_reference_to(Py::Int(-1)); \n                       break;\n                   } \n                   m =  (min + max) /2;\n                   val =    py_to_int(PyList_GetItem(seq.ptr(),m),\"val\"); \n                   if (val  < t) \n                       min = m  + 1;\n                   else if (val >  t)\n                       max = m - 1;\n                   else\n                   {\n                       return_val = Py::new_reference_to(Py::Int(m));\n                       break;\n                   }\n               }\n               \"\"\"\n        return inline(code,['seq','t'])\n
              \n

              \nWe have two variables seq and t passed in. \nt is guaranteed (by the assert) to be an integer. \nPython integers are converted to C int types in the transition from Python to \nC. seq is a Python list. By default, it is translated to a CXX \nlist object. Full documentation for the CXX library can be found at its website. The basics are that the CXX \nprovides C++ class equivalents for Python objects that simplify, or at \nleast object orientify, working with Python objects in C/C++. For example, \nseq.length() returns the length of the list. A little more about\nCXX and its class methods, etc. is in the ** type conversions ** section.\n

              \n\nNote: CXX uses templates and therefore may be a little less portable than \nanother alternative by Gordan McMillan called SCXX which was inspired by\nCXX. It doesn't use templates so it should compile faster and be more portable.\nSCXX has a few less features, but it appears to me that it would mesh with\nthe needs of weave quite well. Hopefully xxx_spec files will be written\nfor SCXX in the future, and we'll be able to compare on a more empirical\nbasis. Both sets of spec files will probably stick around, it just a question\nof which becomes the default.\n\n

              \nMost of the algorithm above looks similar in C to the original Python code. \nThere are two main differences. The first is the setting of \nreturn_val instead of directly returning from the C code with a \nreturn statement. return_val is an automatically \ndefined variable of type PyObject* that is returned from the C \ncode back to Python. You'll have to handle reference counting issues when \nsetting this variable. In this example, CXX classes and functions handle the \ndirty work. All CXX functions and classes live in the namespace \nPy::. The following code converts the integer m to a \nCXX Int() object and then to a PyObject* with an \nincremented reference count using Py::new_reference_to().\n\n 

                 \n    return_val = Py::new_reference_to(Py::Int(m));\n
              \n

              \nThe second big differences shows up in the retrieval of integer values from the \nPython list. The simple Python seq[i] call balloons into a C \nPython API call to grab the value out of the list and then a separate call to \npy_to_int() that converts the PyObject* to an integer. \npy_to_int() includes both a NULL cheack and a \nPyInt_Check() call as well as the conversion call. If either of \nthe checks fail, an exception is raised. The entire C++ code block is executed \nwith in a try/catch block that handles exceptions much like Python \ndoes. This removes the need for most error checking code.\n

              \nIt is worth note that CXX lists do have indexing operators that result \nin code that looks much like Python. However, the overhead in using them \nappears to be relatively high, so the standard Python API was used on the \nseq.ptr() which is the underlying PyObject* of the \nList object.\n

              \nThe #line directive that is the first line of the C code \nblock isn't necessary, but it's nice for debugging. If the compilation fails \nbecause of the syntax error in the code, the error will be reported as an error \nin the Python file \"binary_search.py\" with an offset from the given line number \n(29 here).\n

              \nSo what was all our effort worth in terms of efficiency? Well not a lot in \nthis case. The examples/binary_search.py file runs both Python and C versions \nof the functions As well as using the standard bisect module. If \nwe run it on a 1 million element list and run the search 3000 times (for 0-\n2999), here are the results we get:\n\n 

                 \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python binary_search.py\n    Binary search for 3000 items in 1000000 length list of integers:\n     speed in python: 0.159999966621\n     speed of bisect: 0.121000051498\n     speed up: 1.32\n     speed in c: 0.110000014305\n     speed up: 1.45\n     speed in c(no asserts): 0.0900000333786\n     speed up: 1.78\n
              \n

              \nSo, we get roughly a 50-75% improvement depending on whether we use the Python \nasserts in our C version. If we move down to searching a 10000 element list, \nthe advantage evaporates. Even smaller lists might result in the Python \nversion being faster. I'd like to say that moving to Numeric lists (and \ngetting rid of the GetItem() call) offers a substantial speed up, but my \npreliminary efforts didn't produce one. I think the log(N) algorithm is to \nblame. Because the algorithm is nice, there just isn't much time spent \ncomputing things, so moving to C isn't that big of a win. If there are ways to \nreduce conversion overhead of values, this may improve the C/Python speed \nup. Anyone have other explanations or faster code, please let me know.\n\n\n

              Dictionary Sort

              \n

              \nThe demo in examples/dict_sort.py is another example from the Python CookBook. \nThis \nsubmission, by Alex Martelli, demonstrates how to return the values from a \ndictionary sorted by their keys:\n\n 

                     \n    def sortedDictValues3(adict):\n        keys = adict.keys()\n        keys.sort()\n        return map(adict.get, keys)\n
              \n

              \nAlex provides 3 algorithms and this is the 3rd and fastest of the set. The C \nversion of this same algorithm follows:\n\n 

                     \n    def c_sort(adict):\n        assert(type(adict) == type({}))\n        code = \"\"\"     \n        #line 21 \"dict_sort.py\"  \n        Py::List keys = adict.keys();\n        Py::List items(keys.length()); keys.sort();     \n        PyObject* item = NULL; \n        for(int i = 0;  i < keys.length();i++)\n        {\n            item = PyList_GET_ITEM(keys.ptr(),i);\n            item = PyDict_GetItem(adict.ptr(),item);\n            Py_XINCREF(item);\n            PyList_SetItem(items.ptr(),i,item);              \n        }           \n        return_val = Py::new_reference_to(items);\n        \"\"\"   \n        return inline_tools.inline(code,['adict'],verbose=1)\n
              \n

              \nLike the original Python function, the C++ version can handle any Python \ndictionary regardless of the key/value pair types. It uses CXX objects for the \nmost part to declare python types in C++, but uses Python API calls to manipulate \ntheir contents. Again, this choice is made for speed. The C++ version, while\nmore complicated, is about a factor of 2 faster than Python.\n\n 

                     \n    C:\\home\\ej\\wrk\\scipy\\weave\\examples> python dict_sort.py\n    Dict sort of 1000 items for 300 iterations:\n     speed in python: 0.319999933243\n    [0, 1, 2, 3, 4]\n     speed in c: 0.151000022888\n     speed up: 2.12\n    [0, 1, 2, 3, 4]\n
              \n

              \n\n

              Numeric -- cast/copy/transpose

              \n\nCastCopyTranspose is a function called quite heavily by Linear Algebra routines\nin the Numeric library. Its needed in part because of the row-major memory layout\nof multi-demensional Python (and C) arrays vs. the col-major order of the underlying\nFortran algorithms. For small matrices (say 100x100 or less), a significant\nportion of the common routines such as LU decompisition or singular value decompostion\nare spent in this setup routine. This shouldn't happen. Here is the Python\nversion of the function using standard Numeric operations.\n\n 
                     \n    def _castCopyAndTranspose(type, array):\n        if a.typecode() == type:\n            cast_array = copy.copy(Numeric.transpose(a))\n        else:\n            cast_array = copy.copy(Numeric.transpose(a).astype(type))\n        return cast_array\n
              \n\nAnd the following is a inline C version of the same function:\n\n 
              \n    from weave.blitz_tools import blitz_type_factories\n    from weave import scalar_spec\n    from weave import inline\n    def _cast_copy_transpose(type,a_2d):\n        assert(len(shape(a_2d)) == 2)\n        new_array = zeros(shape(a_2d),type)\n        numeric_type = scalar_spec.numeric_to_blitz_type_mapping[type]\n        code = \\\n        \"\"\"  \n        for(int i = 0;i < _Na_2d[0]; i++)  \n            for(int j = 0;  j < _Na_2d[1]; j++)\n                new_array(i,j) = (%s) a_2d(j,i);\n        \"\"\" % numeric_type\n        inline(code,['new_array','a_2d'],\n               type_factories = blitz_type_factories,compiler='gcc')\n        return new_array\n
              \n\nThis example uses blitz++ arrays instead of the standard representation of \nNumeric arrays so that indexing is simplier to write. This is accomplished by \npassing in the blitz++ \"type factories\" to override the standard Python to C++ \ntype conversions. Blitz++ arrays allow you to write clean, fast code, but they \nalso are sloooow to compile (20 seconds or more for this snippet). This is why \nthey aren't the default type used for Numeric arrays (and also because most \ncompilers can't compile blitz arrays...). inline() is also forced \nto use 'gcc' as the compiler because the default compiler on Windows (MSVC) \nwill not compile blitz code. 'gcc' I think will use the standard compiler \non Unix machine instead of explicitly forcing gcc (check this) \n\nComparisons of the Python vs inline C++ code show a factor of 3 speed up. Also \nshown are the results of an \"inplace\" transpose routine that can be used if the \noutput of the linear algebra routine can overwrite the original matrix (this is \noften appropriate). This provides another factor of 2 improvement.\n\n 
              \n     #C:\\home\\ej\\wrk\\scipy\\weave\\examples> python cast_copy_transpose.py\n    # Cast/Copy/Transposing (150,150)array 1 times\n    #  speed in python: 0.870999932289\n    #  speed in c: 0.25\n    #  speed up: 3.48\n    #  inplace transpose c: 0.129999995232\n    #  speed up: 6.70\n
              \n\n\n

              wxPython

              \n\ninline knows how to handle wxPython objects. Thats nice in and of\nitself, but it also demonstrates that the type conversion mechanism is reasonably \nflexible. Chances are, it won't take a ton of effort to support special types\nyou might have. The examples/wx_example.py borrows the scrolled window\nexample from the wxPython demo, accept that it mixes inline C code in the middle\nof the drawing function.\n\n 
              \n    def DoDrawing(self, dc):\n        \n        red = wxNamedColour(\"RED\");\n        blue = wxNamedColour(\"BLUE\");\n        grey_brush = wxLIGHT_GREY_BRUSH;\n        code = \\\n        \"\"\"\n        #line 108 \"wx_example.py\" \n        dc->BeginDrawing();\n        dc->SetPen(wxPen(*red,4,wxSOLID));\n        dc->DrawRectangle(5,5,50,50);\n        dc->SetBrush(*grey_brush);\n        dc->SetPen(wxPen(*blue,4,wxSOLID));\n        dc->DrawRectangle(15, 15, 50, 50);\n        \"\"\"\n        inline(code,['dc','red','blue','grey_brush'])\n        \n        dc.SetFont(wxFont(14, wxSWISS, wxNORMAL, wxNORMAL))\n        dc.SetTextForeground(wxColour(0xFF, 0x20, 0xFF))\n        te = dc.GetTextExtent(\"Hello World\")\n        dc.DrawText(\"Hello World\", 60, 65)\n\n        dc.SetPen(wxPen(wxNamedColour('VIOLET'), 4))\n        dc.DrawLine(5, 65+te[1], 60+te[0], 65+te[1])\n        ...\n
              \n\nHere, some of the Python calls to wx objects were just converted to C++ calls. There\nisn't any benefit, it just demonstrates the capabilities. You might want to use this\nif you have a computationally intensive loop in your drawing code that you want to \nspeed up.\n\nOn windows, you'll have to use the MSVC compiler if you use the standard wxPython\nDLLs distributed by Robin Dunn. Thats because MSVC and gcc, while binary\ncompatible in C, are not binary compatible for C++. In fact, its probably best, no \nmatter what platform you're on, to specify that inline use the same\ncompiler that was used to build wxPython to be on the safe side. There isn't currently\na way to learn this info from the library -- you just have to know. Also, at least\non the windows platform, you'll need to install the wxWindows libraries and link to \nthem. I think there is a way around this, but I haven't found it yet -- I get some\nlinking errors dealing with wxString. One final note. You'll probably have to\ntweak weave/wx_spec.py or weave/wx_info.py for your machine's configuration to\npoint at the correct directories etc. There. That should sufficiently scare people\ninto not even looking at this... :)\n\n              \n

              Keyword Options

              \n

              \nThe basic definition of the inline() function has a slew of \noptional variables. It also takes keyword arguments that are passed to \ndistutils as compiler options. The following is a formatted \ncut/paste of the argument section of inline's doc-string. It \nexplains all of the variables. Some examples using various options will \nfollow.\n\n 

                     \n    def inline(code,arg_names,local_dict = None, global_dict = None, \n               force = 0, \n               compiler='',\n               verbose = 0, \n               support_code = None,\n               customize=None, \n               type_factories = None, \n               auto_downcast=1,\n               **kw):\n
              \n\n \ninline has quite \na few options as listed below. Also, the keyword arguments for distutils \nextension modules are accepted to specify extra information needed for \ncompiling. \n
              \n

              inline Arguments:

              \n
              \n
              \n
              code
              \n \n
              \nstring. A string of valid C++ code. It should not \n specify a return statement. Instead it should assign results that need to be \n returned to Python in the return_val. \n
              \n\n
              arg_names
              \n \n
              \nlist of strings. A list of Python variable names \n that should be transferred from Python into the C/C++ code. \n
              \n\n
              local_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the local scope for the C/C++ \n code. If local_dict is not specified the local dictionary of the calling \n function is used. \n
              \n\n
              global_dict
              \n \n
              \noptional. dictionary. If specified, it is a \n dictionary of values that should be used as the global scope for the C/C++ \n code. If global_dict is not specified the global dictionary of the calling \n function is used. \n
              \n\n
              force
              \n \n
              \noptional. 0 or 1. default 0. If 1, the C++ code is \n compiled every time inline is called. This is really only useful for \n debugging, and probably only useful if you're editing support_code a lot. \n
              \n\n
              compiler
              \n \n
              \noptional. string. The name of compiler to use when compiling. On windows, it \nunderstands 'msvc' and 'gcc' as well as all the compiler names understood by \ndistutils. On Unix, it'll only understand the values understoof by distutils. \n(I should add 'gcc' though to this).\n

              \nOn windows, the compiler defaults to the Microsoft C++ compiler. If this isn't \navailable, it looks for mingw32 (the gcc compiler).\n

              \nOn Unix, it'll probably use the same compiler that was used when compiling \nPython. Cygwin's behavior should be similar.

              \n
              \n\n
              verbose
              \n \n
              \noptional. 0,1, or 2. defualt 0. Speficies how much \n much information is printed during the compile phase of inlining code. 0 is \n silent (except on windows with msvc where it still prints some garbage). 1 \n informs you when compiling starts, finishes, and how long it took. 2 prints \n out the command lines for the compilation process and can be useful if you're \n having problems getting code to work. Its handy for finding the name of the \n .cpp file if you need to examine it. verbose has no affect if the \n compilation isn't necessary. \n
              \n\n
              support_code
              \n \n
              \noptional. string. A string of valid C++ code \n declaring extra code that might be needed by your compiled function. This \n could be declarations of functions, classes, or structures. \n
              \n\n
              customize
              \n \n
              \noptional. base_info.custom_info object. An \n alternative way to specifiy support_code, headers, etc. needed by the \n function see the weave.base_info module for more details. (not sure \n this'll be used much). \n \n
              \n
              type_factories
              \n \n
              \noptional. list of type specification factories. These guys are what convert \nPython data types to C/C++ data types. If you'd like to use a different set of \ntype conversions than the default, specify them here. Look in the type \nconversions section of the main documentation for examples.\n
              \n
              auto_downcast
              \n \n
              \noptional. 0 or 1. default 1. This only affects functions that have Numeric \narrays as input variables. Setting this to 1 will cause all floating point \nvalues to be cast as float instead of double if all the Numeric arrays are of \ntype float. If even one of the arrays has type double or double complex, all \nvariables maintain there standard types.\n
              \n
              \n
              \n\n

              Distutils keywords:

              \n
              \ninline() also accepts a number of distutils keywords \nfor controlling how the code is compiled. The following descriptions have been \ncopied from Greg Ward's distutils.extension.Extension class doc-\nstrings for convenience:\n\n
              \n
              sources
              \n \n
              \n[string] list of source filenames, relative to the \n distribution root (where the setup script lives), in Unix form \n (slash-separated) for portability. Source files may be C, C++, SWIG (.i), \n platform-specific resource files, or whatever else is recognized by the \n \"build_ext\" command as source for a Python extension. Note: The module_path \n file is always appended to the front of this list \n
              \n\n
              include_dirs
              \n \n
              \n[string] list of directories to search for C/C++ \n header files (in Unix form for portability) \n
              \n\n
              define_macros
              \n \n
              \n[(name : string, value : string|None)] list of \n macros to define; each macro is defined using a 2-tuple, where 'value' is \n either the string to define it to or None to define it without a particular \n value (equivalent of \"#define FOO\" in source or -DFOO on Unix C compiler \n command line) \n
              \n
              undef_macros
              \n \n
              \n[string] list of macros to undefine explicitly \n
              \n
              library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at link time \n
              \n
              libraries
              \n
              \n[string] list of library names (not filenames or paths) to link against \n
              \n
              runtime_library_dirs
              \n
              \n[string] list of directories to search for C/C++ libraries at run time (for \nshared extensions, this is when the extension is loaded) \n
              \n\n
              extra_objects
              \n \n
              \n[string] list of extra files to link with (eg. \n object files not implied by 'sources', static library that must be \n explicitly specified, binary resource files, etc.) \n
              \n\n
              extra_compile_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when compiling the source files in 'sources'. For \n platforms and compilers where \"command line\" makes sense, this is typically \n a list of command-line arguments, but for other platforms it could be \n anything. \n
              \n
              extra_link_args
              \n \n
              \n[string] any extra platform- and compiler-specific \n information to use when linking object files together to create the \n extension (or to create a new static Python interpreter). Similar \n interpretation as for 'extra_compile_args'. \n
              \n
              export_symbols
              \n \n
              \n[string] list of symbols to be exported from a shared extension. Not used on \nall platforms, and not generally necessary for Python extensions, which \ntypically export exactly one symbol: \"init\" + extension_name. \n
              \n
              \n
              \n\n\n

              Keyword Option Examples

              \nWe'll walk through several examples here to demonstrate the behavior of \ninline and also how the various arguments are used.\n\nIn the simplest (most) cases, code and arg_names\nare the only arguments that need to be specified. Here's a simple example\nrun on Windows machine that has Microsoft VC++ installed.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'string'\n    >>> code = \"\"\"\n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));\n    ...        \"\"\"\n    >>> inline(code,['a'])\n     sc_86e98826b65b047ffd2cd5f479c627f12.cpp\n    Creating\n       library C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f12.lib\n    and object C:\\DOCUME~ 1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ff\n    d2cd5f479c627f12.exp\n    6\n    >>> inline(code,['a'])\n    6\n
              \n \nWhen inline is first run, you'll notice that pause and some \ntrash printed to the screen. The \"trash\" is acutually part of the compilers\noutput that distutils does not supress. The name of the extension file, \nsc_bighonkingnumber.cpp, is generated from the md5 check sum\nof the C/C++ code fragment. On Unix or windows machines with only\ngcc installed, the trash will not appear. On the second call, the code \nfragment is not compiled since it already exists, and only the answer is \nreturned. Now kill the interpreter and restart, and run the same code with\na different string.\n\n 
              \n    >>> from weave import inline\n    >>> a = 'a longer string' \n    >>> code = \"\"\" \n    ...        int l = a.length();\n    ...        return_val = Py::new_reference_to(Py::Int(l));  \n    ...        \"\"\"\n    >>> inline(code,['a'])\n    15\n
              \n

              \nNotice this time, inline() did not recompile the code because it\nfound the compiled function in the persistent catalog of functions. There is\na short pause as it looks up and loads the function, but it is much shorter \nthan compiling would require.\n

              \nYou can specify the local and global dictionaries if you'd like (much like \nexec or eval() in Python), but if they aren't \nspecified, the \"expected\" ones are used -- i.e. the ones from the function that \ncalled inline() . This is accomplished through a little call \nframe trickery. Here is an example where the local_dict is specified using\nthe same code example from above:\n\n 

              \n    >>> a = 'a longer string'\n    >>> b = 'an even  longer string' \n    >>> my_dict = {'a':b}\n    >>> inline(code,['a'])\n    15\n    >>> inline(code,['a'],my_dict)\n    21\n
              \n \n

              \nEverytime, the code is changed, inline does a \nrecompile. However, changing any of the other options in inline does not\nforce a recompile. The force option was added so that one\ncould force a recompile when tinkering with other variables. In practice,\nit is just as easy to change the code by a single character\n(like adding a space some place) to force the recompile. Note: It also \nmight be nice to add some methods for purging the cache and on disk \ncatalogs.\n

              \nI use verbose sometimes for debugging. When set to 2, it'll \noutput all the information (including the name of the .cpp file) that you'd\nexpect from running a make file. This is nice if you need to examine the\ngenerated code to see where things are going haywire. Note that error\nmessages from failed compiles are printed to the screen even if verbose\n is set to 0.\n

              \nThe following example demonstrates using gcc instead of the standard msvc \ncompiler on windows using same code fragment as above. Because the example has \nalready been compiled, the force=1 flag is needed to make \ninline() ignore the previously compiled version and recompile \nusing gcc. The verbose flag is added to show what is printed out:\n\n 

              \n    >>>inline(code,['a'],compiler='gcc',verbose=2,force=1)\n    running build_ext    \n    building 'sc_86e98826b65b047ffd2cd5f479c627f13' extension \n    c:\\gcc-2.95.2\\bin\\g++.exe -mno-cygwin -mdll -O2 -w -Wstrict-prototypes -IC:\n    \\home\\ej\\wrk\\scipy\\weave -IC:\\Python21\\Include -c C:\\DOCUME~1\\eric\\LOCAL\n    S~1\\Temp\\python21_compiled\\sc_86e98826b65b047ffd2cd5f479c627f13.cpp -o C:\\D\n    OCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e98826b65b04\n    7ffd2cd5f479c627f13.o    \n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxextensions.c (C:\\DOCUME~1\\eri\n    c\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxextensions.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxxsupport.cxx (C:\\DOCUME~1\\eric\n    \\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxxsupport.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\IndirectPythonInterface.cxx (C:\\\n    DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\indirectpythonin\n    terface.o up-to-date)\n    skipping C:\\home\\ej\\wrk\\scipy\\weave\\CXX\\cxx_extensions.cxx (C:\\DOCUME~1\\\n    eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\cxx_extensions.o up-to-da\n    te)\n    writing C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86\n    e98826b65b047ffd2cd5f479c627f13.def\n    c:\\gcc-2.95.2\\bin\\dllwrap.exe --driver-name g++ -mno-cygwin -mdll -static -\n    -output-lib C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\l\n    ibsc_86e98826b65b047ffd2cd5f479c627f13.a --def C:\\DOCUME~1\\eric\\LOCALS~1\\Te\n    mp\\python21_compiled\\temp\\Release\\sc_86e98826b65b047ffd2cd5f479c627f13.def \n    -s C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\temp\\Release\\sc_86e9882\n    6b65b047ffd2cd5f479c627f13.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compil\n    ed\\temp\\Release\\cxxextensions.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\cxxsupport.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_com\n    piled\\temp\\Release\\indirectpythoninterface.o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\n    \\python21_compiled\\temp\\Release\\cxx_extensions.o -LC:\\Python21\\libs -lpytho\n    n21 -o C:\\DOCUME~1\\eric\\LOCALS~1\\Temp\\python21_compiled\\sc_86e98826b65b047f\n    fd2cd5f479c627f13.pyd\n    15\n
              \n\nThat's quite a bit of output. verbose=1 just prints the compile\ntime.\n\n 
              \n    >>>inline(code,['a'],compiler='gcc',verbose=1,force=1)\n    Compiling code...\n    finished compiling (sec):  6.00800001621\n    15\n
              \n\n

              \n Note: I've only used the compiler option for switching between 'msvc'\nand 'gcc' on windows. It may have use on Unix also, but I don't know yet.\n\n\n

              \nThe support_code argument is likely to be used a lot. It allows \nyou to specify extra code fragments such as function, structure or class \ndefinitions that you want to use in the code string. Note that \nchanges to support_code do not force a recompile. The \ncatalog only relies on code (for performance reasons) to determine \nwhether recompiling is necessary. So, if you make a change to support_code, \nyou'll need to alter code in some way or use the \nforce argument to get the code to recompile. I usually just add \nsome inocuous whitespace to the end of one of the lines in code \nsomewhere. Here's an example of defining a separate method for calculating\nthe string length:\n\n 

              \n    >>> from weave import inline\n    >>> a = 'a longer string'\n    >>> support_code = \"\"\"\n    ...                PyObject* length(Py::String a)\n    ...                {\n    ...                    int l = a.length();  \n    ...                    return Py::new_reference_to(Py::Int(l)); \n    ...                }\n    ...                \"\"\"        \n    >>> inline(\"return_val = length(a);\",['a'],\n    ...        support_code = support_code)\n    15\n
              \n

              \ncustomize is a left over from a previous way of specifying \ncompiler options. It is a custom_info object that can specify \nquite a bit of information about how a file is compiled. These \ninfo objects are the standard way of defining compile information \nfor type conversion classes. However, I don't think they are as handy here, \nespecially since we've exposed all the keyword arguments that distutils can \nhandle. Between these keywords, and the support_code option, I \nthink customize may be obsolete. We'll see if anyone cares to use \nit. If not, it'll get axed in the next version.\n

              \nThe type_factories variable is important to people who want to\ncustomize the way arguments are converted from Python to C. We'll talk about\nthis in the next chapter **xx** of this document when we discuss type\nconversions.\n

              \nauto_downcast handles one of the big type conversion issues that\nis common when using Numeric arrays in conjunction with Python scalar values.\nIf you have an array of single precision values and multiply that array by a \nPython scalar, the result is upcast to a double precision array because the\nscalar value is double precision. This is not usually the desired behavior\nbecause it can double your memory usage. auto_downcast goes\nsome distance towards changing the casting precedence of arrays and scalars.\nIf your only using single precision arrays, it will automatically downcast all\nscalar values from double to single precision when they are passed into the\nC++ code. This is the default behavior. If you want all values to keep there\ndefault type, set auto_downcast to 0.\n

              \n\n\n\n

              Returning Values

              \n\nPython variables in the local and global scope transfer seemlessly from Python \ninto the C++ snippets. And, if inline were to completely live up\nto its name, any modifications to variables in the C++ code would be reflected\nin the Python variables when control was passed back to Python. For example,\nthe desired behavior would be something like:\n\n 
              \n    # THIS DOES NOT WORK\n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    2\n
              \n\nInstead you get:\n\n 
              \n    >>> a = 1\n    >>> weave.inline(\"a++;\",['a'])\n    >>> a\n    1\n
              \n \nVariables are passed into C++ as if you are calling a Python function. Python's \ncalling convention is sometimes called \"pass by assignment\". This means its as \nif a c_a = a assignment is made right before inline \ncall is made and the c_a variable is used within the C++ code. \nThus, any changes made to c_a are not reflected in Python's \na variable. Things do get a little more confusing, however, when \nlooking at variables with mutable types. Changes made in C++ to the contents \nof mutable types are reflected in the Python variables.\n\n 
              \n    >>> a= [1,2]\n    >>> weave.inline(\"PyList_SetItem(a.ptr(),0,PyInt_FromLong(3));\",['a'])\n    >>> print a\n    [3, 2]\n
              \n\nSo modifications to the contents of mutable types in C++ are seen when control\nis returned to Python. Modifications to immutable types such as tuples,\nstrings, and numbers do not alter the Python variables.\n\nIf you need to make changes to an immutable variable, you'll need to assign\nthe new value to the \"magic\" variable return_val in C++. This\nvalue is returned by the inline() function:\n\n 
              \n    >>> a = 1\n    >>> a = weave.inline(\"return_val = Py::new_reference_to(Py::Int(a+1));\",['a'])  \n    >>> a\n    2\n
              \n\nThe return_val variable can also be used to return newly created \nvalues. This is possible by returning a tuple. The following trivial example \nillustrates how this can be done:\n\n 
                     \n    # python version\n    def multi_return():\n        return 1, '2nd'\n    \n    # C version.\n    def c_multi_return():    \n        code =  \"\"\"\n     \t        Py::Tuple results(2);\n     \t        results[0] = Py::Int(1);\n     \t        results[1] = Py::String(\"2nd\");\n     \t        return_val = Py::new_reference_to(results); \t        \n                \"\"\"\n        return inline_tools.inline(code)\n
              \n

              \nThe example is available in examples/tuple_return.py. It also\nhas the dubious honor of demonstrating how much inline() can \nslow things down. The C version here is about 10 times slower than the Python\nversion. Of course, something so trivial has no reason to be written in\nC anyway.\n\n\n

              The issue with locals()

              \n

              \ninline passes the locals() and globals() \ndictionaries from Python into the C++ function from the calling function. It \nextracts the variables that are used in the C++ code from these dictionaries, \nconverts then to C++ variables, and then calculates using them. It seems like \nit would be trivial, then, after the calculations were finished to then insert \nthe new values back into the locals() and globals() \ndictionaries so that the modified values were reflected in Python. \nUnfortunately, as pointed out by the Python manual, the locals() dictionary is \nnot writable. \n

              \n\nI suspect locals() is not writable because there are some \noptimizations done to speed lookups of the local namespace. I'm guessing local \nlookups don't always look at a dictionary to find values. Can someone \"in the \nknow\" confirm or correct this? Another thing I'd like to know is whether there \nis a way to write to the local namespace of another stack frame from C/C++. If \nso, it would be possible to have some clean up code in compiled functions that \nwrote final values of variables in C++ back to the correct Python stack frame. \nI think this goes a long way toward making inline truely live up \nto its name. I don't think we'll get to the point of creating variables in \nPython for variables created in C -- although I suppose with a C/C++ parser you \ncould do that also.\n\n

              \n\n\n

              A quick look at the code

              \n\nweave generates a C++ file holding an extension function for \neach inline code snippet. These file names are generated using \nfrom the md5 signature of the code snippet and saved to a location specified by \nthe PYTHONCOMPILED environment variable (discussed later). The cpp files are \ngenerally about 200-400 lines long and include quite a few functions to support \ntype conversions, etc. However, the actual compiled function is pretty simple. \nBelow is the familiar printf example:\n\n 
              \n    >>> import weave    \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\\\\n\",a);',['a'])\n    1\n
              \n\nAnd here is the extension function generated by inline:\n\n 
              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        // The Py_None needs an incref before returning\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n        \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try                              \n        {                                \n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n            /* Here is the inline code */            \n            printf(\"%d\\n\",a);\n            /* I would like to fill in changed locals and globals here... */\n        }                                       \n        catch( Py::Exception& e)           \n        {                                \n            return_val =  Py::Null();    \n            exception_occured = 1;       \n        }                                 \n        if(!return_val && !exception_occured)\n        {\n                                      \n            Py_INCREF(Py_None);              \n            return_val = Py_None;            \n        }\n        /* clean up code */\n        \n        /* return */                              \n        return return_val;           \n    }                                \n
              \n\nEvery inline function takes exactly two arguments -- the local and global\ndictionaries for the current scope. All variable values are looked up out\nof these dictionaries. The lookups, along with all inline code \nexecution, are done within a C++ try block. If the variables\naren't found, or there is an error converting a Python variable to the \nappropriate type in C++, an exception is raised. The C++ exception\nis automatically converted to a Python exception by CXX and returned to Python.\n\nThe py_to_int() function illustrates how the conversions and\nexception handling works. py_to_int first checks that the given PyObject*\npointer is not NULL and is a Python integer. If all is well, it calls the\nPython API to convert the value to an int. Otherwise, it calls\nhandle_bad_type() which gathers information about what went wrong\nand then raises a CXX TypeError which returns to Python as a TypeError.\n\n 
              \n    int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\n 
              \n    void handle_bad_type(PyObject* py_obj, char* good_type, char*  var_name)\n    {\n        char msg[500];\n        sprintf(msg,\"received '%s' type instead of '%s' for variable '%s'\",\n                find_type(py_obj),good_type,var_name);\n        throw Py::TypeError(msg);\n    }\n    \n    char* find_type(PyObject* py_obj)\n    {\n        if(py_obj == NULL) return \"C NULL value\";\n        if(PyCallable_Check(py_obj)) return \"callable\";\n        if(PyString_Check(py_obj)) return \"string\";\n        if(PyInt_Check(py_obj)) return \"int\";\n        if(PyFloat_Check(py_obj)) return \"float\";\n        if(PyDict_Check(py_obj)) return \"dict\";\n        if(PyList_Check(py_obj)) return \"list\";\n        if(PyTuple_Check(py_obj)) return \"tuple\";\n        if(PyFile_Check(py_obj)) return \"file\";\n        if(PyModule_Check(py_obj)) return \"module\";\n        \n        //should probably do more interagation (and thinking) on these.\n        if(PyCallable_Check(py_obj) && PyInstance_Check(py_obj)) return \"callable\";\n        if(PyInstance_Check(py_obj)) return \"instance\"; \n        if(PyCallable_Check(py_obj)) return \"callable\";\n        return \"unkown type\";\n    }\n
              \n\nSince the inline is also executed within the try/catch\nblock, you can use CXX exceptions within your code. It is usually a bad idea\nto directly return from your code, even if an error occurs. This\nskips the clean up section of the extension function. In this simple example,\nthere isn't any clean up code, but in more complicated examples, there may\nbe some reference counting that needs to be taken care of here on converted\nvariables. To avoid this, either uses exceptions or set \nreturn_val to NULL and use if/then's to skip code\nafter errors.\n\n\n

              Technical Details

              \n

              \nThere are several main steps to using C/C++ code withing Python:\n

                \n
              1. Type conversion \n
              2. Generating C/C++ code \n
              3. Compile the code to an extension module \n
              4. Catalog (and cache) the function for future use
                5. \n
              \n

              \nItems 1 and 2 above are related, but most easily discussed separately. Type \nconversions are customizable by the user if needed. Understanding them is \npretty important for anything beyond trivial uses of inline. \nGenerating the C/C++ code is handled by ext_function and \next_module classes and . For the most part, compiling the code is \nhandled by distutils. Some customizations were needed, but they were \nrelatively minor and do not require changes to distutils itself. Cataloging is \npretty simple in concept, but surprisingly required the most code to implement \n(and still likely needs some work). So, this section covers items 1 and 4 from \nthe list. Item 2 is covered later in the chapter covering the \next_tools module, and distutils is covered by a completely \nseparate document xxx.\n\n

              Passing Variables in/out of the C/C++ code

              \n\nNote: Passing variables into the C code is pretty straight forward, but there \nare subtlties to how variable modifications in C are returned to Python. see Returning Values for a more thorough discussion of \nthis issue.\n \n \n\n

              Type Conversions

              \n\n\nNote: Maybe xxx_converter instead of \nxxx_specification is a more descriptive name. Might change in \nfuture version?\n\n\n

              \nBy default, inline() makes the following type conversions between\nPython and C++ types.\n

              \n\n

              \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
              \n

              Default Data Type Conversions

              \n

              Python

              		\n

              C++

                 int   int
                 float   double
                 complex   std::complex
                 string   Py::String
                 list   Py::List
                 dict   Py::Dict
                 tuple   Py::Tuple
                 file   FILE*
                 callable   PyObject*
                 instance   PyObject*
                 Numeric.array   PyArrayObject*
                 wxXXX   wxXXX*
              \n
              \n

              \nThe Py:: namespace is defined by the \nCXX library which has C++ class\nequivalents for many Python types. std:: is the namespace of the\nstandard library in C++.\n

              \n\nNote: \n

                \n
              • I haven't figured out how to handle long int yet (I think they are currenlty converted \n to int - - check this). \n \n
              • \nHopefully VTK will be added to the list soon
                • \n
              \n\n

              \n\nPython to C++ conversions fill in code in several locations in the generated\ninline extension function. Below is the basic template for the\nfunction. This is actually the exact code that is generated by calling\nweave.inline(\"\").\n\n 

              \n    static PyObject* compiled_func(PyObject*self, PyObject* args)\n    {\n        PyObject *return_val = NULL;\n        int exception_occured = 0;\n        PyObject *py__locals = NULL;\n        PyObject *py__globals = NULL;\n        PyObject *py_a;\n        py_a = NULL;\n    \n        if(!PyArg_ParseTuple(args,\"OO:compiled_func\",&py__locals,&py__globals))\n            return NULL;\n        try\n        {\n            PyObject* raw_locals = py_to_raw_dict(py__locals,\"_locals\");\n            PyObject* raw_globals = py_to_raw_dict(py__globals,\"_globals\");\n            /* argument conversion code */\n            /* inline code */\n            /*I would like to fill in changed locals and globals here...*/\n    \n        }\n        catch( Py::Exception& e)\n        {\n            return_val =  Py::Null();\n            exception_occured = 1;\n        }\n        /* cleanup code */\n        if(!return_val && !exception_occured)\n        {\n    \n            Py_INCREF(Py_None);\n            return_val = Py_None;\n        }\n    \n        return return_val;\n    }\n
              \n\nThe /* inline code */ section is filled with the code passed to\nthe inline() function call. The \n/*argument convserion code*/ and /* cleanup code */\nsections are filled with code that handles conversion from Python to C++\ntypes and code that deallocates memory or manipulates reference counts before\nthe function returns. The following sections demostrate how these two areas\nare filled in by the default conversion methods.\n\n \nNote: I'm not sure I have reference counting correct on a few of these. The \nonly thing I increase/decrease the ref count on is Numeric arrays. If you\nsee an issue, please let me know.\n\n\n\n

              Numeric Argument Conversion

              \n\nInteger, floating point, and complex arguments are handled in a very similar\nfashion. Consider the following inline function that has a single integer \nvariable passed in:\n\n 
              \n    >>> a = 1\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    int a = py_to_int (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_int() has the following\nform:\n\n 
              \n    static int py_to_int(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyInt_Check(py_obj))\n            handle_bad_type(py_obj,\"int\", name);\n        return (int) PyInt_AsLong(py_obj);\n    }\n
              \n\nSimilarly, the float and complex conversion routines look like:\n\n 
                  \n    static double py_to_float(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyFloat_Check(py_obj))\n            handle_bad_type(py_obj,\"float\", name);\n        return PyFloat_AsDouble(py_obj);\n    }\n    \n    static std::complex py_to_complex(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyComplex_Check(py_obj))\n            handle_bad_type(py_obj,\"complex\", name);\n        return std::complex(PyComplex_RealAsDouble(py_obj),\n                                    PyComplex_ImagAsDouble(py_obj));    \n    }\n
              \n\nNumeric conversions do not require any clean up code.\n\n\n

              String, List, Tuple, and Dictionary Conversion

              \n\nStrings, Lists, Tuples and Dictionary conversions are all converted to \nCXX types by default.\n\nFor the following code, \n\n 
              \n    >>> a = [1]\n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code inserted for a is:\n\n 
              \n    /* argument conversion code */\n    Py::List a = py_to_list (get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_list() and its\nfriends has the following form:\n\n 
                  \n    static Py::List py_to_list(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyList_Check(py_obj))\n            handle_bad_type(py_obj,\"list\", name);\n        return Py::List(py_obj);\n    }\n    \n    static Py::String py_to_string(PyObject* py_obj,char* name)\n    {\n        if (!PyString_Check(py_obj))\n            handle_bad_type(py_obj,\"string\", name);\n        return Py::String(py_obj);\n    }\n\n    static Py::Dict py_to_dict(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyDict_Check(py_obj))\n            handle_bad_type(py_obj,\"dict\", name);\n        return Py::Dict(py_obj);\n    }\n    \n    static Py::Tuple py_to_tuple(PyObject* py_obj,char* name)\n    {\n        if (!py_obj || !PyTuple_Check(py_obj))\n            handle_bad_type(py_obj,\"tuple\", name);\n        return Py::Tuple(py_obj);\n    }\n
              \n\nCXX handles reference counts on for strings, lists, tuples, and dictionaries,\nso clean up code isn't necessary.\n\n\n

              File Conversion

              \n\nFor the following code, \n\n 
              \n    >>> a = open(\"bob\",'w')  \n    >>> inline(\"\",['a'])\n
              \n\nThe argument conversion code is:\n\n 
              \n    /* argument conversion code */\n    PyObject* py_a = get_variable(\"a\",raw_locals,raw_globals);\n    FILE* a = py_to_file(py_a,\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. py_to_file() converts\nPyObject* to a FILE* and increments the reference count of the PyObject*:\n\n 
              \n    FILE* py_to_file(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"file\", name);\n    \n        Py_INCREF(py_obj);\n        return PyFile_AsFile(py_obj);\n    }\n
              \n\nBecause the PyObject* was incremented, the clean up code needs to decrement\nthe counter\n\n 
              \n    /* cleanup code */\n    Py_XDECREF(py_a);\n
              \n\nIts important to understand that file conversion only works on actual files --\ni.e. ones created using the open() command in Python. It does\nnot support converting arbitrary objects that support the file interface into\nC FILE* pointers. This can affect many things. For example, in\ninitial printf() examples, one might be tempted to solve the \nproblem of C and Python IDE's (PythonWin, PyCrust, etc.) writing to different\nstdout and stderr by using fprintf() and passing in \nsys.stdout and sys.stderr. For example, instead of\n\n 
              \n    >>> weave.inline('printf(\"hello\\\\n\");')\n
              \n \nYou might try:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n
              \n\nThis will work as expected from a standard python interpreter, but in PythonWin,\nthe following occurs:\n\n 
              \n    >>> buf = sys.stdout\n    >>> weave.inline('fprintf(buf,\"hello\\\\n\");',['buf'])\n    Traceback (most recent call last):\n        File \"\", line 1, in ?\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 315, in inline\n            auto_downcast = auto_downcast,\n        File \"C:\\Python21\\weave\\inline_tools.py\", line 386, in compile_function\n            type_factories = type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 197, in __init__\n            auto_downcast, type_factories)\n        File \"C:\\Python21\\weave\\ext_tools.py\", line 390, in assign_variable_types\n            raise TypeError, format_error_msg(errors)\n        TypeError: {'buf': \"Unable to convert variable 'buf' to a C++ type.\"}\n
              \n\nThe traceback tells us that inline() was unable to convert 'buf' to a\nC++ type (If instance conversion was implemented, the error would have occurred at \nruntime instead). Why is this? Let's look at what the buf object \nreally is:\n\n 
              \n    >>> buf\n    pywin.framework.interact.InteractiveView instance at 00EAD014\n
              \n\nPythonWin has reassigned sys.stdout to a special object that \nimplements the Python file interface. This works great in Python, but since \nthe special object doesn't have a FILE* pointer underlying it, fprintf doesn't \nknow what to do with it (well this will be the problem when instance conversion \nis implemented...).\n\n\n

              Callable, Instance, and Module Conversion

              \n\nNote: Need to look into how ref counts should be handled. Also,\nInstance and Module conversion are not currently implemented.\n\n\n 
              \n    >>> def a(): \n        pass\n    >>> inline(\"\",['a'])\n
              \n\nCallable and instance variables are converted to PyObject*. Nothing is done\nto there reference counts.\n\n 
              \n    /* argument conversion code */\n    PyObject* a = py_to_callable(get_variable(\"a\",raw_locals,raw_globals),\"a\");\n
              \n\nget_variable() reads the variable a\nfrom the local and global namespaces. The py_to_callable() and\npy_to_instance() don't currently increment the ref count.\n\n 
                  \n    PyObject* py_to_callable(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyCallable_Check(py_obj))\n            handle_bad_type(py_obj,\"callable\", name);    \n        return py_obj;\n    }\n\n    PyObject* py_to_instance(PyObject* py_obj, char* name)\n    {\n        if (!py_obj || !PyFile_Check(py_obj))\n            handle_bad_type(py_obj,\"instance\", name);    \n        return py_obj;\n    }\n
              \n \nThere is no cleanup code for callables, modules, or instances.\n\n\n

              Customizing Conversions

              \n

              \nConverting from Python to C++ types is handled by xxx_specification classes. A \ntype specification class actually serve in two related but different \nroles. The first is in determining whether a Python variable that needs to be \nconverted should be represented by the given class. The second is as a code \ngenerator that generate C++ code needed to convert from Python to C++ types for \na specific variable.\n

              \nWhen \n\n 

              \n    >>> a = 1\n    >>> weave.inline('printf(\"%d\",a);',['a'])\n
              \n \nis called for the first time, the code snippet has to be compiled. In this \nprocess, the variable 'a' is tested against a list of type specifications (the \ndefault list is stored in weave/ext_tools.py). The first \nspecification in the list is used to represent the variable. \n\n

              \nExamples of xxx_specification are scattered throughout numerous \n\"xxx_spec.py\" files in the weave package. Closely related to \nthe xxx_specification classes are yyy_info classes. \nThese classes contain compiler, header, and support code information necessary \nfor including a certain set of capabilities (such as blitz++ or CXX support)\nin a compiled module. xxx_specification classes have one or more\nyyy_info classes associated with them.\n\nIf you'd like to define your own set of type specifications, the current best route\nis to examine some of the existing spec and info files. Maybe looking over\nsequence_spec.py and cxx_info.py are a good place to start. After defining \nspecification classes, you'll need to pass them into inline using the \ntype_factories argument. \n\nA lot of times you may just want to change how a specific variable type is \nrepresented. Say you'd rather have Python strings converted to \nstd::string or maybe char* instead of using the CXX \nstring object, but would like all other type conversions to have default \nbehavior. This requires that a new specification class that handles strings\nis written and then prepended to a list of the default type specifications. Since\nit is closer to the front of the list, it effectively overrides the default\nstring specification.\n\nThe following code demonstrates how this is done:\n\n...\n\n\n

              The Catalog

              \n

              \ncatalog.py has a class called catalog that helps keep \ntrack of previously compiled functions. This prevents inline() \nand related functions from having to compile functions everytime they are \ncalled. Instead, catalog will check an in memory cache to see if the function \nhas already been loaded into python. If it hasn't, then it starts searching \nthrough persisent catalogs on disk to see if it finds an entry for the given \nfunction. By saving information about compiled functions to disk, it isn't\nnecessary to re-compile functions everytime you stop and restart the interpreter.\nFunctions are compiled once and stored for future use.\n\n

              \nWhen inline(cpp_code) is called the following things happen:\n

                \n
              1. \n A fast local cache of functions is checked for the last function called for \n cpp_code. If an entry for cpp_code doesn't exist in the \n cache or the cached function call fails (perhaps because the function doesn't \n have compatible types) then the next step is to check the catalog. \n
              2. \n The catalog class also keeps an in-memory cache with a list of all the \n functions compiled for cpp_code. If cpp_code has\n ever been called, then this cache will be present (loaded from disk). If\n the cache isn't present, then it is loaded from disk.\n

                \n If the cache is present, each function in the cache is \n called until one is found that was compiled for the correct argument types. If \n none of the functions work, a new function is compiled with the given argument \n types. This function is written to the on-disk catalog as well as into the \n in-memory cache.

                \n
              3. \n When a lookup for cpp_code fails, the catalog looks through \n the on-disk function catalogs for the entries. The PYTHONCOMPILED variable \n determines where to search for these catalogs and in what order. If \n PYTHONCOMPILED is not present several platform dependent locations are \n searched. All functions found for cpp_code in the path are \n loaded into the in-memory cache with functions found earlier in the search \n path closer to the front of the call list.\n

                \n If the function isn't found in the on-disk catalog, \n then the function is compiled, written to the first writable directory in the \n PYTHONCOMPILED path, and also loaded into the in-memory cache.

                \n
                4. \n
              \n\n\n

              Function Storage: How functions are stored in caches and on disk

              \n

              \nFunction caches are stored as dictionaries where the key is the entire C++\ncode string and the value is either a single function (as in the \"level 1\"\ncache) or a list of functions (as in the main catalog cache). On disk\ncatalogs are stored in the same manor using standard Python shelves.\n

              \nEarly on, there was a question as to whether md5 check sums of the C++\ncode strings should be used instead of the actual code strings. I think this\nis the route inline Perl took. Some (admittedly quick) tests of the md5 vs.\nthe entire string showed that using the entire string was at least a\nfactor of 3 or 4 faster for Python. I think this is because it is more\ntime consuming to compute the md5 value than it is to do look-ups of long\nstrings in the dictionary. Look at the examples/md5_speed.py file for the\ntest run. \n\n\n

              Catalog search paths and the PYTHONCOMPILED variable

              \n

              \nThe default location for catalog files on Unix is is ~/.pythonXX_compiled where \nXX is version of Python being used. If this directory doesn't exist, it is \ncreated the first time a catalog is used. The directory must be writable. If, \nfor any reason it isn't, then the catalog attempts to create a directory based \non your user id in the /tmp directory. The directory permissions are set so \nthat only you have access to the directory. If this fails, I think you're out of \nluck. I don't think either of these should ever fail though. On Windows, a \ndirectory called pythonXX_compiled is created in the user's temporary \ndirectory. \n

              \nThe actual catalog file that lives in this directory is a Python shelve with\na platform specific name such as \"nt21compiled_catalog\" so that multiple OSes\ncan share the same file systems without trampling on each other. Along with\nthe catalog file, the .cpp and .so or .pyd files created by inline will live\nin this directory. The catalog file simply contains keys which are the C++\ncode strings with values that are lists of functions. The function lists point\nat functions within these compiled modules. Each function in the lists \nexecutes the same C++ code string, but compiled for different input variables.\n

              \nYou can use the PYTHONCOMPILED environment variable to specify alternative\nlocations for compiled functions. On Unix this is a colon (':') separated\nlist of directories. On windows, it is a (';') separated list of directories.\nThese directories will be searched prior to the default directory for a\ncompiled function catalog. Also, the first writable directory in the list\nis where all new compiled function catalogs, .cpp and .so or .pyd files are\nwritten. Relative directory paths ('.' and '..') should work fine in the\nPYTHONCOMPILED variable as should environement variables.\n

              \nThere is a \"special\" path variable called MODULE that can be placed in the \nPYTHONCOMPILED variable. It specifies that the compiled catalog should\nreside in the same directory as the module that called it. This is useful\nif an admin wants to build a lot of compiled functions during the build\nof a package and then install them in site-packages along with the package.\nUser's who specify MODULE in their PYTHONCOMPILED variable will have access\nto these compiled functions. Note, however, that if they call the function\nwith a set of argument types that it hasn't previously been built for, the\nnew function will be stored in their default directory (or some other writable\ndirectory in the PYTHONCOMPILED path) because the user will not have write\naccess to the site-packages directory.\n

              \nAn example of using the PYTHONCOMPILED path on bash follows:\n\n 

              \n    PYTHONCOMPILED=MODULE:/some/path;export PYTHONCOMPILED;\n
              \n\nIf you are using python21 on linux, and the module bob.py in site-packages\nhas a compiled function in it, then the catalog search order when calling that\nfunction for the first time in a python session would be:\n\n 
              \n    /usr/lib/python21/site-packages/linuxpython_compiled\n    /some/path/linuxpython_compiled\n    ~/.python21_compiled/linuxpython_compiled\n
              \n\nThe default location is always included in the search path.\n

              \n \nNote: hmmm. see a possible problem here. I should probably make a sub-\ndirectory such as /usr/lib/python21/site-\npackages/python21_compiled/linuxpython_compiled so that library files compiled \nwith python21 are tried to link with python22 files in some strange scenarios. \nNeed to check this.\n\n\n

              \nThe in-module cache (in weave.inline_tools reduces the overhead \nof calling inline functions by about a factor of 2. It can be reduced a little \nmore for type loop calls where the same function is called over and over again \nif the cache was a single value instead of a dictionary, but the benefit is \nvery small (less than 5%) and the utility is quite a bit less. So, we'll stick \nwith a dictionary as the cache.\n

              \n\n\n

              Blitz

              \n Note: most of this section is lifted from old documentation. It should be\npretty accurate, but there may be a few discrepancies.\n

              \nweave.blitz() compiles Numeric Python expressions for fast \nexecution. For most applications, compiled expressions should provide a \nfactor of 2-10 speed-up over Numeric arrays. Using compiled \nexpressions is meant to be as unobtrusive as possible and works much like \npythons exec statement. As an example, the following code fragment takes a 5 \npoint average of the 512x512 2d image, b, and stores it in array, a:\n\n 

              \n    from scipy import *  # or from Numeric import *\n    a = ones((512,512), Float64) \n    b = ones((512,512), Float64) \n    # ...do some stuff to fill in b...\n    # now average\n    a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1] \\\n                   + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n
              \n \nTo compile the expression, convert the expression to a string by putting\nquotes around it and then use weave.blitz:\n\n 
              \n    import weave\n    expr = \"a[1:-1,1:-1] =  (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n                          \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n    weave.blitz(expr)\n
              \n\nThe first time weave.blitz is run for a given expression and \nset of arguements, C++ code that accomplishes the exact same task as the Python \nexpression is generated and compiled to an extension module. This can take up \nto a couple of minutes depending on the complexity of the function. Subsequent \ncalls to the function are very fast. Futher, the generated module is saved \nbetween program executions so that the compilation is only done once for a \ngiven expression and associated set of array types. If the given expression\nis executed with a new set of array types, the code most be compiled again. This\ndoes not overwrite the previously compiled function -- both of them are saved and\navailable for exectution. \n

              \nThe following table compares the run times for standard Numeric code and \ncompiled code for the 5 point averaging.\n

              \n

              \n\n\n\n\n\n
              Method Run Time (seconds)
              Standard Numeric 0.46349
              blitz (1st time compiling) 78.95526
              blitz (subsequent calls) 0.05843 (factor of 8 speedup)
              \n
              \n

              \nThese numbers are for a 512x512 double precision image run on a 400 MHz Celeron \nprocessor under RedHat Linux 6.2.\n

              \nBecause of the slow compile times, its probably most effective to develop \nalgorithms as you usually do using the capabilities of scipy or the Numeric \nmodule. Once the algorithm is perfected, put quotes around it and execute it \nusing weave.blitz. This provides the standard rapid \nprototyping strengths of Python and results in algorithms that run close to \nthat of hand coded C or Fortran.\n\n\n

              Requirements

              \n\nCurrently, the weave.blitz has only been tested under Linux \nwith gcc-2.95-3 and on Windows with Mingw32 (2.95.2). Its compiler \nrequirements are pretty heavy duty (see the \nblitz++ home page), so it won't \nwork with just any compiler. Particularly MSVC++ isn't up to snuff. A number \nof other compilers such as KAI++ will also work, but my suspicions are that gcc \nwill get the most use.\n\n\n

              Limitations

              \n
                \n
              1. \nCurrently, weave.blitz handles all standard mathematic \noperators except for the ** power operator. The built-in trigonmetric, log, \nfloor/ceil, and fabs functions might work (but haven't been tested). It also \nhandles all types of array indexing supported by the Numeric module. \n

                \nweave.blitz does not currently support operations that use \narray broadcasting, nor have any of the special purpose functions in Numeric \nsuch as take, compress, etc. been implemented. Note that there are no obvious \nreasons why most of this functionality cannot be added to scipy.weave, so it \nwill likely trickle into future versions. Using slice() objects \ndirectly instead of start:stop:step is also not supported.\n

                2. \n
              2. \nCurrently Python only works on expressions that include assignment such as\n \n 
                \n    >>> result = b + c + d\n
                \n\nThis means that the result array must exist before calling \nweave.blitz. Future versions will allow the following:\n\n 
                \n    >>> result = weave.blitz_eval(\"b + c + d\")\n
                \n
                3. \n
              3. \nweave.blitz works best when algorithms can be expressed in a \n\"vectorized\" form. Algorithms that have a large number of if/thens and other \nconditions are better hand written in C or Fortran. Further, the restrictions \nimposed by requiring vectorized expressions sometimes preclude the use of more \nefficient data structures or algorithms. For maximum speed in these cases, \nhand-coded C or Fortran code is the only way to go.\n
                4. \n
              4. \nOne other point deserves mention lest people be confused. \nweave.blitz is not a general purpose Python->C compiler. It \nonly works for expressions that contain Numeric arrays and/or \nPython scalar values. This focused scope concentrates effort on the \ncompuationally intensive regions of the program and sidesteps the difficult \nissues associated with a general purpose Python->C compiler.\n
                5. \n
              \n\n\n

              Numeric efficiency issues: What compilation buys you

              \n\nSome might wonder why compiling Numeric expressions to C++ is beneficial since \noperations on Numeric array operations are already executed within C loops. \nThe problem is that anything other than the simplest expression are executed in \nless than optimal fashion. Consider the following Numeric expression:\n\n 
              \n    a = 1.2 * b + c * d\n
              \n \nWhen Numeric calculates the value for the 2d array, a, it does \nthe following steps:\n\n 
              \n    temp1 = 1.2 * b\n    temp2 = c * d\n    a = temp1 + temp2\n
              \n \nTwo things to note. Since c is an (perhaps large) array, a large \ntemporary array must be created to store the results of 1.2 * b. \nThe same is true for temp2. Allocation is slow. The second thing \nis that we have 3 loops executing, one to calculate temp1, one for \ntemp2 and one for adding them up. A C loop for the same problem \nmight look like:\n\n 
              \n    for(int i = 0; i < M; i++)\n        for(int j = 0; j < N; j++)\n            a[i,j] = 1.2 * b[i,j] + c[i,j] * d[i,j]\n
              \n \nHere, the 3 loops have been fused into a single loop and there is no longer\na need for a temporary array. This provides a significant speed improvement\nover the above example (write me and tell me what you get). \n

              \nSo, converting Numeric expressions into C/C++ loops that fuse the loops and \neliminate temporary arrays can provide big gains. The goal then,is to convert \nNumeric expression to C/C++ loops, compile them in an extension module, and \nthen call the compiled extension function. The good news is that there is an \nobvious correspondence between the Numeric expression above and the C loop. The \nbad news is that Numeric is generally much more powerful than this simple \nexample illustrates and handling all possible indexing possibilities results in \nloops that are less than straight forward to write. (take a peak in Numeric for \nconfirmation). Luckily, there are several available tools that simplify the \nprocess.\n\n\n

              The Tools

              \n\nweave.blitz relies heavily on several remarkable tools. On the \nPython side, the main facilitators are Jermey Hylton's parser module and Jim \nHuginin's Numeric module. On the compiled language side, Todd Veldhuizen's \nblitz++ array library, written in C++ (shhhh. don't tell David Beazley), does \nthe heavy lifting. Don't assume that, because it's C++, it's much slower than C \nor Fortran. Blitz++ uses a jaw dropping array of template techniques \n(metaprogramming, template expression, etc) to convert innocent looking and \nreadable C++ expressions into to code that usually executes within a few \npercentage points of Fortran code for the same problem. This is good. \nUnfortunately all the template raz-ma-taz is very expensive to compile, so the \n200 line extension modules often take 2 or more minutes to compile. This isn't so \ngood. weave.blitz works to minimize this issue by remembering \nwhere compiled modules live and reusing them instead of re-compiling every time \na program is re-run.\n\n\n

              Parser

              \nTearing Numeric expressions apart, examining the pieces, and then rebuilding \nthem as C++ (blitz) expressions requires a parser of some sort. I can imagine \nsomeone attacking this problem with regular expressions, but it'd likely be \nugly and fragile. Amazingly, Python solves this problem for us. It actually \nexposes its parsing engine to the world through the parser module. \nThe following fragment creates an Abstract Syntax Tree (AST) object for the \nexpression and then converts to a (rather unpleasant looking) deeply nested list \nrepresentation of the tree. \n \n 
              \n    >>> import parser\n    >>> import scipy.weave.misc\n    >>> ast = parser.suite(\"a = b * c + d\")\n    >>> ast_list = ast.tolist()\n    >>> sym_list = scipy.weave.misc.translate_symbols(ast_list)\n    >>> pprint.pprint(sym_list)\n    ['file_input',\n     ['stmt',\n      ['simple_stmt',\n       ['small_stmt',\n        ['expr_stmt',\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'a']]]]]]]]]]]]]]],\n         ['EQUAL', '='],\n         ['testlist',\n          ['test',\n           ['and_test',\n            ['not_test',\n             ['comparison',\n              ['expr',\n               ['xor_expr',\n                ['and_expr',\n                 ['shift_expr',\n                  ['arith_expr',\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'b']]]],\n                    ['STAR', '*'],\n                    ['factor', ['power', ['atom', ['NAME', 'c']]]]],\n                   ['PLUS', '+'],\n                   ['term',\n                    ['factor', ['power', ['atom', ['NAME', 'd']]]]]]]]]]]]]]]]],\n       ['NEWLINE', '']]],\n     ['ENDMARKER', '']]\n
              \n\nDespite its looks, with some tools developed by Jermey H., its possible\nto search these trees for specific patterns (sub-trees), extract the \nsub-tree, manipulate them converting python specific code fragments\nto blitz code fragments, and then re-insert it in the parse tree. The parser\nmodule documentation has some details on how to do this. Traversing the \nnew blitzified tree, writing out the terminal symbols as you go, creates\nour new blitz++ expression string.\n\n \n

              Blitz and Numeric

              \nThe other nice discovery in the project is that the data structure used\nfor Numeric arrays and blitz arrays is nearly identical. Numeric stores\n\"strides\" as byte offsets and blitz stores them as element offsets, but\nother than that, they are the same. Further, most of the concept and\ncapabilities of the two libraries are remarkably similar. It is satisfying \nthat two completely different implementations solved the problem with \nsimilar basic architectures. It is also fortitous. The work involved in \nconverting Numeric expressions to blitz expressions was greatly diminished.\nAs an example, consider the code for slicing an array in Python with a\nstride:\n\n 
              \n    >>> a = b[0:4:2] + c\n    >>> a\n    [0,2,4]\n
              \n\n\nIn Blitz it is as follows:\n\n 
              \n    Array<2,int> b(10);\n    Array<2,int> c(3);\n    // ...\n    Array<2,int> a = b(Range(0,3,2)) + c;\n
              \n\n\nHere the range object works exactly like Python slice objects with the exception\nthat the top index (3) is inclusive where as Python's (4) is exclusive. Other \ndifferences include the type declaraions in C++ and parentheses instead of \nbrackets for indexing arrays. Currently, weave.blitz handles the \ninclusive/exclusive issue by subtracting one from upper indices during the\ntranslation. An alternative that is likely more robust/maintainable in the \nlong run, is to write a PyRange class that behaves like Python's range. \nThis is likely very easy.\n

              \nThe stock blitz also doesn't handle negative indices in ranges. The current \nimplementation of the blitz() has a partial solution to this \nproblem. It calculates and index that starts with a '-' sign by subtracting it \nfrom the maximum index in the array so that:\n\n 

              \n                    upper index limit\n                        /-----\\\n    b[:-1] -> b(Range(0,Nb[0]-1-1))\n
              \n\nThis approach fails, however, when the top index is calculated from other \nvalues. In the following scenario, if i+j evaluates to a negative \nvalue, the compiled code will produce incorrect results and could even core-\ndump. Right now, all calculated indices are assumed to be positive.\n \n 
              \n    b[:i-j] -> b(Range(0,i+j))\n
              \n\nA solution is to calculate all indices up front using if/then to handle the\n+/- cases. This is a little work and results in more code, so it hasn't been\ndone. I'm holding out to see if blitz++ can be modified to handle negative\nindexing, but haven't looked into how much effort is involved yet. While it \nneeds fixin', I don't think there is a ton of code where this is an issue.\n

              \nThe actual translation of the Python expressions to blitz expressions is \ncurrently a two part process. First, all x:y:z slicing expression are removed\nfrom the AST, converted to slice(x,y,z) and re-inserted into the tree. Any\nmath needed on these expressions (subtracting from the \nmaximum index, etc.) are also preformed here. _beg and _end are used as special\nvariables that are defined as blitz::fromBegin and blitz::toEnd.\n\n 

              \n    a[i+j:i+j+1,:] = b[2:3,:] \n
              \n\nbecomes a more verbose:\n \n 
              \n    a[slice(i+j,i+j+1),slice(_beg,_end)] = b[slice(2,3),slice(_beg,_end)]\n
              \n \nThe second part does a simple string search/replace to convert to a blitz \nexpression with the following translations:\n\n 
              \n    slice(_beg,_end) -> _all  # not strictly needed, but cuts down on code.\n    slice            -> blitz::Range\n    [                -> (\n    ]                -> )\n    _stp             -> 1\n
              \n\n_all is defined in the compiled function as \nblitz::Range.all(). These translations could of course happen \ndirectly in the syntax tree. But the string replacement is slightly easier. \nNote that name spaces are maintained in the C++ code to lessen the likelyhood \nof name clashes. Currently no effort is made to detect name clashes. A good \nrule of thumb is don't use values that start with '_' or 'py_' in compiled \nexpressions and you'll be fine.\n\n \n

              Type definitions and coersion

              \n\nSo far we've glossed over the dynamic vs. static typing issue between Python \nand C++. In Python, the type of value that a variable holds can change\nthrough the course of program execution. C/C++, on the other hand, forces you\nto declare the type of value a variables will hold prior at compile time.\nweave.blitz handles this issue by examining the types of the\nvariables in the expression being executed, and compiling a function for those\nexplicit types. For example:\n\n 
              \n    a = ones((5,5),Float32)\n    b = ones((5,5),Float32)\n    weave.blitz(\"a = a + b\")\n
              \n\nWhen compiling this expression to C++, weave.blitz sees that the\nvalues for a and b in the local scope have type Float32, or 'float'\non a 32 bit architecture. As a result, it compiles the function using \nthe float type (no attempt has been made to deal with 64 bit issues).\nIt also goes one step further. If all arrays have the same type, a templated\nversion of the function is made and instantiated for float, double, \ncomplex, and complex arrays. Note: This feature has been \nremoved from the current version of the code. Each version will be compiled\nseparately \n

              \nWhat happens if you call a compiled function with array types that are \ndifferent than the ones for which it was originally compiled? No biggie, you'll \njust have to wait on it to compile a new version for your new types. This \ndoesn't overwrite the old functions, as they are still accessible. See the \ncatalog section in the inline() documentation to see how this is handled. \nSuffice to say, the mechanism is transparent to the user and behaves \nlike dynamic typing with the occasional wait for compiling newly typed \nfunctions.\n

              \nWhen working with combined scalar/array operations, the type of the array is \nalways used. This is similar to the savespace flag that was recently \nadded to Numeric. This prevents issues with the following expression perhaps \nunexpectedly being calculated at a higher (more expensive) precision that can \noccur in Python:\n\n 

              \n    >>> a = array((1,2,3),typecode = Float32)\n    >>> b = a * 2.1 # results in b being a Float64 array.\n
              \n \nIn this example, \n\n 
              \n    >>> a = ones((5,5),Float32)\n    >>> b = ones((5,5),Float32)\n    >>> weave.blitz(\"b = a * 2.1\")\n
              \n \nthe 2.1 is cast down to a float before carrying out \nthe operation. If you really want to force the calculation to be a \ndouble, define a and b as \ndouble arrays.\n

              \nOne other point of note. Currently, you must include both the right hand side \nand left hand side (assignment side) of your equation in the compiled \nexpression. Also, the array being assigned to must be created prior to calling \nweave.blitz. I'm pretty sure this is easily changed so that a \ncompiled_eval expression can be defined, but no effort has been made to \nallocate new arrays (and decern their type) on the fly.\n\n \n

              Cataloging Compiled Functions

              \n\nSee the Cataloging functions section in the \nweave.inline() documentation.\n\n \n

              Checking Array Sizes

              \n\nSurprisingly, one of the big initial problems with compiled code was making\nsure all the arrays in an operation were of compatible type. The following\ncase is trivially easy:\n\n 
              \n    a = b + c\n
              \n \nIt only requires that arrays a, b, and c \nhave the same shape. However, expressions like:\n\n 
              \n    a[i+j:i+j+1,:] = b[2:3,:] + c\n
              \n\nare not so trivial. Since slicing is involved, the size of the slices, not the \ninput arrays must be checked. Broadcasting complicates things further because \narrays and slices with different dimensions and shapes may be compatible for \nmath operations (broadcasting isn't yet supported by \nweave.blitz). Reductions have a similar effect as their \nresults are different shapes than their input operand. The binary operators in \nNumeric compare the shapes of their two operands just before they operate on \nthem. This is possible because Numeric treats each operation independently. \nThe intermediate (temporary) arrays created during sub-operations in an \nexpression are tested for the correct shape before they are combined by another \noperation. Because weave.blitz fuses all operations into a \nsingle loop, this isn't possible. The shape comparisons must be done and \nguaranteed compatible before evaluating the expression.\n

              \nThe solution chosen converts input arrays to \"dummy arrays\" that only represent \nthe dimensions of the arrays, not the data. Binary operations on dummy arrays \ncheck that input array sizes are comptible and return a dummy array with the \nsize correct size. Evaluating an expression of dummy arrays traces the \nchanging array sizes through all operations and fails if incompatible array \nsizes are ever found. \n

              \nThe machinery for this is housed in weave.size_check. It \nbasically involves writing a new class (dummy array) and overloading it math \noperators to calculate the new sizes correctly. All the code is in Python and \nthere is a fair amount of logic (mainly to handle indexing and slicing) so the \noperation does impose some overhead. For large arrays (ie. 50x50x50), the \noverhead is negligible compared to evaluating the actual expression. For small \narrays (ie. 16x16), the overhead imposed for checking the shapes with this \nmethod can cause the weave.blitz to be slower than evaluating \nthe expression in Python. \n

              \nWhat can be done to reduce the overhead? (1) The size checking code could be \nmoved into C. This would likely remove most of the overhead penalty compared \nto Numeric (although there is also some calling overhead), but no effort has \nbeen made to do this. (2) You can also call weave.blitz with\ncheck_size=0 and the size checking isn't done. However, if the \nsizes aren't compatible, it can cause a core-dump. So, foregoing size_checking\nisn't advisable until your code is well debugged.\n\n \n

              Creating the Extension Module

              \n\nweave.blitz uses the same machinery as \nweave.inline to build the extension module. The only difference\nis the code included in the function is automatically generated from the\nNumeric array expression instead of supplied by the user.\n\n\n

              Extension Modules

              \nweave.inline and weave.blitz are high level tools\nthat generate extension modules automatically. Under the covers, they use several\nclasses from weave.ext_tools to help generate the extension module.\nThe main two classes are ext_module and ext_function (I'd\nlike to add ext_class and ext_method also). These classes\nsimplify the process of generating extension modules by handling most of the \"boiler\nplate\" code automatically.\n\n\nNote: inline actually sub-classes weave.ext_tools.ext_function \nto generate slightly different code than the standard ext_function.\nThe main difference is that the standard class converts function arguments to\nC types, while inline always has two arguments, the local and global dicts, and\nthe grabs the variables that need to be convereted to C from these.\n\n\n\n

              A Simple Example

              \nThe following simple example demonstrates how to build an extension module within\na Python function:\n\n 
              \n    # examples/increment_example.py\n    from weave import ext_tools\n    \n    def build_increment_ext():\n        \"\"\" Build a simple extension with functions that increment numbers.\n            The extension will be built in the local directory.\n        \"\"\"        \n        mod = ext_tools.ext_module('increment_ext')\n    \n        a = 1 # effectively a type declaration for 'a' in the \n              # following functions.\n    \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n        mod.add_function(func)\n        \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+2));\"    \n        func = ext_tools.ext_function('increment_by_2',ext_code,['a'])\n        mod.add_function(func)\n                \n        mod.compile()\n
              \n\n\nThe function build_increment_ext() creates an extension module \nnamed increment_ext and compiles it to a shared library (.so or \n.pyd) that can be loaded into Python.. increment_ext contains two \nfunctions, increment and increment_by_2. \n\nThe first line of build_increment_ext(),\n\n 
              \n        mod = ext_tools.ext_module('increment_ext') \n
              \n\ncreates an ext_module instance that is ready to have \next_function instances added to it. ext_function \ninstances are created much with a calling convention similar to \nweave.inline(). The most common call includes a C/C++ code \nsnippet and a list of the arguments for the function. The following\n\n 
              \n        ext_code = \"return_val = Py::new_reference_to(Py::Int(a+1));\"    \n        func = ext_tools.ext_function('increment',ext_code,['a'])\n
              \n \ncreates a C/C++ extension function that is equivalent to the following Python\nfunction:\n\n 
              \n        def increment(a):\n            return a + 1\n
              \n\nA second method is also added to the module and then,\n\n 
              \n        mod.compile()\n
              \n\nis called to build the extension module. By default, the module is created\nin the current working directory.\n\nThis example is available in the examples/increment_example.py file\nfound in the weave directory. At the bottom of the file in the\nmodule's \"main\" program, an attempt to import increment_ext without\nbuilding it is made. If this fails (the module doesn't exist in the PYTHONPATH), \nthe module is built by calling build_increment_ext(). This approach\nonly takes the time consuming ( a few seconds for this example) process of building\nthe module if it hasn't been built before.\n\n 
              \n    if __name__ == \"__main__\":\n        try:\n            import increment_ext\n        except ImportError:\n            build_increment_ext()\n            import increment_ext\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\n\nNote: If we were willing to always pay the penalty of building the C++ code for \na module, we could store the md5 checksum of the C++ code along with some \ninformation about the compiler, platform, etc. Then, \next_module.compile() could try importing the module before it actually\ncompiles it, check the md5 checksum and other meta-data in the imported module\nwith the meta-data of the code it just produced and only compile the code if\nthe module didn't exist or the meta-data didn't match. This would reduce the\nabove code to:\n\n 
              \n    if __name__ == \"__main__\":\n        build_increment_ext()\n\n        a = 1\n        print 'a, a+1:', a, increment_ext.increment(a)\n        print 'a, a+2:', a, increment_ext.increment_by_2(a)           \n
              \n\nNote: There would always be the overhead of building the C++ code, but it would only actually compile the code once. You pay a little in overhead and get cleaner\n\"import\" code. Needs some thought.\n\n

              \n\nIf you run increment_example.py from the command line, you get\nthe following:\n\n 

              \n    [eric@n0]$ python increment_example.py\n    a, a+1: 1 2\n    a, a+2: 1 3\n
              \n\nIf the module didn't exist before it was run, the module is created. If it did\nexist, it is just imported and used.\n\n\n

              Fibonacci Example

              \nexamples/fibonacci.py provides a little more complex example of \nhow to use ext_tools. Fibonacci numbers are a series of numbers \nwhere each number in the series is the sum of the previous two: 1, 1, 2, 3, 5, \n8, etc. Here, the first two numbers in the series are taken to be 1. One \napproach to calculating Fibonacci numbers uses recursive function calls. In \nPython, it might be written as:\n\n 
              \n    def fib(a):\n        if a <= 2:\n            return 1\n        else:\n            return fib(a-2) + fib(a-1)\n
              \n\nIn C, the same function would look something like this:\n\n 
              \n     int fib(int a)\n     {                   \n         if(a <= 2)\n             return 1;\n         else\n             return fib(a-2) + fib(a-1);  \n     }                      \n
              \n\nRecursion is much faster in C than in Python, so it would be beneficial\nto use the C version for fibonacci number calculations instead of the\nPython version. We need an extension function that calls this C function\nto do this. This is possible by including the above code snippet as \n\"support code\" and then calling it from the extension function. Support \ncode snippets (usually structure definitions, helper functions and the like)\nare inserted into the extension module C/C++ file before the extension\nfunction code. Here is how to build the C version of the fibonacci number\ngenerator:\n\n 
              \ndef build_fibonacci():\n    \"\"\" Builds an extension module with fibonacci calculators.\n    \"\"\"\n    mod = ext_tools.ext_module('fibonacci_ext')\n    a = 1 # this is effectively a type declaration\n    \n    # recursive fibonacci in C \n    fib_code = \"\"\"\n                   int fib1(int a)\n                   {                   \n                       if(a <= 2)\n                           return 1;\n                       else\n                           return fib1(a-2) + fib1(a-1);  \n                   }                         \n               \"\"\"\n    ext_code = \"\"\"\n                   int val = fib1(a);\n                   return_val = Py::new_reference_to(Py::Int(val));\n               \"\"\"    \n    fib = ext_tools.ext_function('fib',ext_code,['a'])\n    fib.customize.add_support_code(fib_code)\n    mod.add_function(fib)\n\n    mod.compile()\n\n
              \n\nXXX More about custom_info, and what xxx_info instances are good for.\n\n

              \n\nNote: recursion is not the fastest way to calculate fibonacci numbers, but this \napproach serves nicely for this example.\n\n

              \n\n

              Customizing Type Conversions -- Type Factories

              \nnot written\n\n

              Things I wish weave did

              \n\nIt is possible to get name clashes if you uses a variable name that is already defined\nin a header automatically included (such as stdio.h) For instance, if you\ntry to pass in a variable named stdout, you'll get a cryptic error report\ndue to the fact that stdio.h also defines the name. weave\nshould probably try and handle this in some way.\n\nOther things...", "methods": [], "methods_before": [], "changed_methods": [], "nloc": null, "complexity": null, "token_count": null, "diff_parsed": { "added": [ "", "
              ", "", "

              ", "", "" ], "deleted": [ "
              ", "
              ", "", "

              ", "" ] } } ] }, { "hash": "2547260e6e69c2fd4f0527ca464e9fe4612623d8", "msg": "changed insertion of stdc++ to check for msvc instead of platform == linux", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-04T23:54:32+00:00", "author_timezone": 0, "committer_date": "2002-01-04T23:54:32+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "b908030c39e3c5c490540597e93c5dc4bbcd77c7" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 1, "insertions": 1, "lines": 2, "files": 1, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": "weave/build_tools.py", "new_path": "weave/build_tools.py", "filename": "build_tools.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -147,7 +147,7 @@ def build_extension(module_path,compiler_name = '',build_dir = None,\n # add module to the needed source code files and build extension\n # FIX this is g++ specific. It probably should be fixed for other\n # Unices/compilers. Find a generic solution\n- if sys.platform[:-1] == 'linux':\n+ if compiler_name != 'msvc':\n libraries = kw.get('libraries',[])\n kw['libraries'] = ['stdc++'] + libraries \n ext = Extension(module_name, **kw)\n", "added_lines": 1, "deleted_lines": 1, "source_code": "\"\"\" Tools for compiling C/C++ code to extension modules\n\n The main function, build_extension(), takes the C/C++ file\n along with some other options and builds a Python extension.\n It uses distutils for most of the heavy lifting.\n \n choose_compiler() is also useful (mainly on windows anyway)\n for trying to determine whether MSVC++ or gcc is available.\n MSVC doesn't handle templates as well, so some of the code emitted\n by the python->C conversions need this info to choose what kind\n of code to create.\n \n The other main thing here is an alternative version of the MingW32\n compiler class. The class makes it possible to build libraries with\n gcc even if the original version of python was built using MSVC. It\n does this by converting a pythonxx.lib file to a libpythonxx.a file.\n Note that you need write access to the pythonxx/lib directory to do this.\n\"\"\"\n\nimport sys,os,string,time\nimport tempfile\nimport exceptions\n\nclass CompileError(exceptions.Exception):\n pass\n \ndef build_extension(module_path,compiler_name = '',build_dir = None,\n temp_dir = None, verbose = 0, **kw):\n \"\"\" Build the file given by module_path into a Python extension module.\n \n build_extensions uses distutils to build Python extension modules.\n kw arguments not used are passed on to the distutils extension\n module. Directory settings can handle absoulte settings, but don't\n currently expand '~' or environment variables.\n \n module_path -- the full path name to the c file to compile. \n Something like: /full/path/name/module_name.c \n The name of the c/c++ file should be the same as the\n name of the module (i.e. the initmodule() routine)\n compiler_name -- The name of the compiler to use. On Windows if it \n isn't given, MSVC is used if it exists (is found).\n gcc is used as a second choice. If neither are found, \n the default distutils compiler is used. Acceptable \n names are 'gcc', 'msvc' or any of the compiler names \n shown by distutils.ccompiler.show_compilers()\n build_dir -- The location where the resulting extension module \n should be placed. This location must be writable. If\n it isn't, several default locations are tried. If the \n build_dir is not in the current python path, a warning\n is emitted, and it is added to the end of the path.\n build_dir defaults to the current directory.\n temp_dir -- The location where temporary files (*.o or *.obj)\n from the build are placed. This location must be \n writable. If it isn't, several default locations are \n tried. It defaults to tempfile.gettempdir()\n verbose -- 0, 1, or 2. 0 is as quiet as possible. 1 prints\n minimal information. 2 is noisy. \n **kw -- keyword arguments. These are passed on to the \n distutils extension module. Most of the keywords\n are listed below.\n\n Distutils keywords. These are cut and pasted from Greg Ward's\n distutils.extension.Extension class for convenience:\n \n sources : [string]\n list of source filenames, relative to the distribution root\n (where the setup script lives), in Unix form (slash-separated)\n for portability. Source files may be C, C++, SWIG (.i),\n platform-specific resource files, or whatever else is recognized\n by the \"build_ext\" command as source for a Python extension.\n Note: The module_path file is always appended to the front of this\n list \n include_dirs : [string]\n list of directories to search for C/C++ header files (in Unix\n form for portability) \n define_macros : [(name : string, value : string|None)]\n list of macros to define; each macro is defined using a 2-tuple,\n where 'value' is either the string to define it to or None to\n define it without a particular value (equivalent of \"#define\n FOO\" in source or -DFOO on Unix C compiler command line) \n undef_macros : [string]\n list of macros to undefine explicitly\n library_dirs : [string]\n list of directories to search for C/C++ libraries at link time\n libraries : [string]\n list of library names (not filenames or paths) to link against\n runtime_library_dirs : [string]\n list of directories to search for C/C++ libraries at run time\n (for shared extensions, this is when the extension is loaded)\n extra_objects : [string]\n list of extra files to link with (eg. object files not implied\n by 'sources', static library that must be explicitly specified,\n binary resource files, etc.)\n extra_compile_args : [string]\n any extra platform- and compiler-specific information to use\n when compiling the source files in 'sources'. For platforms and\n compilers where \"command line\" makes sense, this is typically a\n list of command-line arguments, but for other platforms it could\n be anything.\n extra_link_args : [string]\n any extra platform- and compiler-specific information to use\n when linking object files together to create the extension (or\n to create a new static Python interpreter). Similar\n interpretation as for 'extra_compile_args'.\n export_symbols : [string]\n list of symbols to be exported from a shared extension. Not\n used on all platforms, and not generally necessary for Python\n extensions, which typically export exactly one symbol: \"init\" +\n extension_name.\n \"\"\"\n success = 0\n from distutils.core import setup, Extension\n \n # this is a screwy trick to get rid of a ton of warnings on Unix\n import distutils.sysconfig\n distutils.sysconfig.get_config_vars()\n if distutils.sysconfig._config_vars.has_key('OPT'):\n flags = distutils.sysconfig._config_vars['OPT'] \n flags = flags.replace('-Wall','')\n distutils.sysconfig._config_vars['OPT'] = flags\n \n # get the name of the module and the extension directory it lives in. \n module_dir,cpp_name = os.path.split(os.path.abspath(module_path))\n module_name,ext = os.path.splitext(cpp_name) \n \n # configure temp and build directories\n temp_dir = configure_temp_dir(temp_dir) \n build_dir = configure_build_dir(module_dir)\n \n compiler_name = choose_compiler(compiler_name)\n configure_sys_argv(compiler_name,temp_dir,build_dir)\n \n # the business end of the function\n try:\n if verbose == 1:\n print 'Compiling code...'\n \n # set compiler verboseness 2 or more makes it output results\n if verbose > 1: verb = 1 \n else: verb = 0\n \n t1 = time.time() \n # add module to the needed source code files and build extension\n sources = kw.get('sources',[])\n kw['sources'] = [module_path] + sources \n \n # add module to the needed source code files and build extension\n # FIX this is g++ specific. It probably should be fixed for other\n # Unices/compilers. Find a generic solution\n if compiler_name != 'msvc':\n libraries = kw.get('libraries',[])\n kw['libraries'] = ['stdc++'] + libraries \n ext = Extension(module_name, **kw)\n \n # the switcheroo on SystemExit here is meant to keep command line\n # sessions from exiting when compiles fail.\n builtin = sys.modules['__builtin__']\n old_SysExit = builtin.__dict__['SystemExit']\n builtin.__dict__['SystemExit'] = CompileError\n \n # distutils for MSVC messes with the environment, so we save the\n # current state and restore them afterward.\n import copy\n environ = copy.deepcopy(os.environ)\n try:\n setup(name = module_name, ext_modules = [ext],verbose=verb)\n finally:\n # restore state\n os.environ = environ \n # restore SystemExit\n builtin.__dict__['SystemExit'] = old_SysExit\n t2 = time.time()\n \n if verbose == 1:\n print 'finished compiling (sec): ', t2 - t1 \n success = 1\n configure_python_path(build_dir)\n except SyntaxError: #TypeError:\n success = 0 \n \n # restore argv after our trick... \n restore_sys_argv()\n \n return success\n\nold_argv = []\ndef configure_sys_argv(compiler_name,temp_dir,build_dir):\n # We're gonna play some tricks with argv here to pass info to distutils \n # which is really built for command line use. better way??\n global old_argv\n old_argv = sys.argv[:] \n sys.argv = ['','build_ext','--build-lib', build_dir,\n '--build-temp',temp_dir] \n if compiler_name == 'gcc':\n sys.argv.insert(2,'--compiler='+compiler_name)\n elif compiler_name:\n sys.argv.insert(2,'--compiler='+compiler_name)\n\ndef restore_sys_argv():\n sys.argv = old_argv\n \ndef configure_python_path(build_dir): \n #make sure the module lives in a directory on the python path.\n python_paths = [os.path.abspath(x) for x in sys.path]\n if os.path.abspath(build_dir) not in python_paths:\n #print \"warning: build directory was not part of python path.\"\\\n # \" It has been appended to the path.\"\n sys.path.append(os.path.abspath(build_dir))\n\ndef choose_compiler(compiler_name=''):\n \"\"\" Try and figure out which compiler is gonna be used on windows.\n On other platforms, it just returns whatever value it is given.\n \n converts 'gcc' to 'mingw32' on win32\n \"\"\"\n if sys.platform == 'win32': \n if not compiler_name:\n # On Windows, default to MSVC and use gcc if it wasn't found\n # wasn't found. If neither are found, go with whatever\n # the default is for distutils -- and probably fail...\n if msvc_exists():\n compiler_name = 'msvc'\n elif gcc_exists():\n compiler_name = 'mingw32'\n elif compiler_name == 'gcc':\n compiler_name = 'mingw32'\n else:\n # don't know how to force gcc -- look into this.\n if compiler_name == 'gcc':\n compiler_name = 'unix' \n return compiler_name\n \ndef gcc_exists():\n \"\"\" Test to make sure gcc is found \n \n Does this return correct value on win98???\n \"\"\"\n result = 0\n try:\n w,r=os.popen4('gcc -v')\n w.close()\n str_result = r.read()\n #print str_result\n if string.find(str_result,'Reading specs') != -1:\n result = 1\n except:\n # This was needed because the msvc compiler messes with\n # the path variable. and will occasionlly mess things up\n # so much that gcc is lost in the path. (Occurs in test\n # scripts)\n result = not os.system('gcc -v')\n return result\n\ndef msvc_exists():\n \"\"\" Determine whether MSVC is available on the machine.\n \"\"\"\n result = 0\n try:\n w,r=os.popen4('cl')\n w.close()\n str_result = r.read()\n #print str_result\n if string.find(str_result,'Microsoft') != -1:\n result = 1\n except:\n #assume we're ok if devstudio exists\n import distutils.msvccompiler\n version = distutils.msvccompiler.get_devstudio_version()\n if version:\n result = 1\n return result\n\ndef configure_temp_dir(temp_dir=None):\n if temp_dir is None: \n temp_dir = tempfile.gettempdir()\n elif not os.path.exists(temp_dir) or not os.access(temp_dir,os.W_OK):\n print \"warning: specified temp_dir '%s' does not exist or is \" \\\n \"or is not writable. Using the default temp directory\" % \\\n temp_dir\n temp_dir = tempfile.gettempdir()\n\n # final check that that directories are writable. \n if not os.access(temp_dir,os.W_OK):\n msg = \"Either the temp or build directory wasn't writable. Check\" \\\n \" these locations: '%s'\" % temp_dir \n raise ValueError, msg\n return temp_dir\n\ndef configure_build_dir(build_dir=None):\n # make sure build_dir exists and is writable\n if build_dir and (not os.path.exists(build_dir) or \n not os.access(build_dir,os.W_OK)):\n print \"warning: specified build_dir '%s' does not exist or is \" \\\n \"or is not writable. Trying default locations\" % build_dir\n build_dir = None\n \n if build_dir is None:\n #default to building in the home directory of the given module. \n build_dir = os.curdir\n # if it doesn't work use the current directory. This should always\n # be writable. \n if not os.access(build_dir,os.W_OK):\n print \"warning:, neither the module's directory nor the \"\\\n \"current directory are writable. Using the temporary\"\\\n \"directory.\"\n build_dir = tempfile.gettempdir()\n\n # final check that that directories are writable.\n if not os.access(build_dir,os.W_OK):\n msg = \"The build directory wasn't writable. Check\" \\\n \" this location: '%s'\" % build_dir\n raise ValueError, msg\n \n return os.path.abspath(build_dir) \n \nif sys.platform == 'win32':\n import distutils.cygwinccompiler\n # the same as cygwin plus some additional parameters\n class Mingw32CCompiler (distutils.cygwinccompiler.CygwinCCompiler):\n \"\"\" A modified MingW32 compiler compatible with an MSVC built Python.\n \n \"\"\"\n \n compiler_type = 'mingw32'\n \n def __init__ (self,\n verbose=0,\n dry_run=0,\n force=0):\n \n distutils.cygwinccompiler.CygwinCCompiler.__init__ (self, verbose, \n dry_run, force)\n \n # A real mingw32 doesn't need to specify a different entry point,\n # but cygwin 2.91.57 in no-cygwin-mode needs it.\n if self.gcc_version <= \"2.91.57\":\n entry_point = '--entry _DllMain@12'\n else:\n entry_point = ''\n if self.linker_dll == 'dllwrap':\n self.linker = 'dllwrap' + ' --driver-name g++'\n elif self.linker_dll == 'gcc':\n self.linker = 'g++' \n # **changes: eric jones 4/11/01\n # 1. Check for import library on Windows. Build if it doesn't exist.\n if not import_library_exists():\n build_import_library()\n \n # **changes: eric jones 4/11/01\n # 2. increased optimization and turned off all warnings\n # 3. also added --driver-name g++\n #self.set_executables(compiler='gcc -mno-cygwin -O2 -w',\n # compiler_so='gcc -mno-cygwin -mdll -O2 -w',\n # linker_exe='gcc -mno-cygwin',\n # linker_so='%s --driver-name g++ -mno-cygwin -mdll -static %s' \n # % (self.linker, entry_point))\n self.set_executables(compiler='g++ -mno-cygwin -O2 -w',\n compiler_so='g++ -mno-cygwin -mdll -O2 -w -Wstrict-prototypes',\n linker_exe='g++ -mno-cygwin',\n linker_so='%s -mno-cygwin -mdll -static %s' \n % (self.linker, entry_point))\n \n # Maybe we should also append -mthreads, but then the finished\n # dlls need another dll (mingwm10.dll see Mingw32 docs)\n # (-mthreads: Support thread-safe exception handling on `Mingw32') \n \n # no additional libraries needed \n self.dll_libraries=[]\n \n # __init__ ()\n \n # On windows platforms, we want to default to mingw32 (gcc)\n # because msvc can't build blitz stuff.\n # We should also check the version of gcc available...\n #distutils.ccompiler._default_compilers['nt'] = 'mingw32'\n #distutils.ccompiler._default_compilers = (('nt', 'mingw32'))\n # reset the Mingw32 compiler in distutils to the one defined above\n distutils.cygwinccompiler.Mingw32CCompiler = Mingw32CCompiler\n \n def import_library_exists():\n \"\"\" on windows platforms, make sure a gcc import library exists\n \"\"\"\n if os.name == 'nt':\n lib_name = \"libpython%d%d.a\" % tuple(sys.version_info[:2])\n full_path = os.path.join(sys.prefix,'libs',lib_name)\n if not os.path.exists(full_path):\n return 0\n return 1\n \n def build_import_library():\n \"\"\" Build the import libraries for Mingw32-gcc on Windows\n \"\"\"\n import lib2def as lib2def\n #libfile, deffile = parse_cmd()\n #if deffile == None:\n # deffile = sys.stdout\n #else:\n # deffile = open(deffile, 'w')\n lib_name = \"python%d%d.lib\" % tuple(sys.version_info[:2]) \n lib_file = os.path.join(sys.prefix,'libs',lib_name)\n def_name = \"python%d%d.def\" % tuple(sys.version_info[:2]) \n def_file = os.path.join(sys.prefix,'libs',def_name)\n nm_cmd = '%s %s' % (lib2def.DEFAULT_NM, lib_file)\n nm_output = lib2def.getnm(nm_cmd)\n dlist, flist = lib2def.parse_nm(nm_output)\n lib2def.output_def(dlist, flist, lib2def.DEF_HEADER, open(def_file, 'w'))\n \n out_name = \"libpython%d%d.a\" % tuple(sys.version_info[:2])\n out_file = os.path.join(sys.prefix,'libs',out_name)\n dll_name = \"python%d%d.dll\" % tuple(sys.version_info[:2])\n args = (dll_name,def_file,out_file)\n cmd = 'dlltool --dllname %s --def %s --output-lib %s' % args\n success = not os.system(cmd)\n # for now, fail silently\n if not success:\n print 'WARNING: failed to build import library for gcc. Linking will fail.'\n #if not success:\n # msg = \"Couldn't find import library, and failed to build it.\"\n # raise DistutilsPlatformError, msg\n \ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n\n\n\n", "source_code_before": "\"\"\" Tools for compiling C/C++ code to extension modules\n\n The main function, build_extension(), takes the C/C++ file\n along with some other options and builds a Python extension.\n It uses distutils for most of the heavy lifting.\n \n choose_compiler() is also useful (mainly on windows anyway)\n for trying to determine whether MSVC++ or gcc is available.\n MSVC doesn't handle templates as well, so some of the code emitted\n by the python->C conversions need this info to choose what kind\n of code to create.\n \n The other main thing here is an alternative version of the MingW32\n compiler class. The class makes it possible to build libraries with\n gcc even if the original version of python was built using MSVC. It\n does this by converting a pythonxx.lib file to a libpythonxx.a file.\n Note that you need write access to the pythonxx/lib directory to do this.\n\"\"\"\n\nimport sys,os,string,time\nimport tempfile\nimport exceptions\n\nclass CompileError(exceptions.Exception):\n pass\n \ndef build_extension(module_path,compiler_name = '',build_dir = None,\n temp_dir = None, verbose = 0, **kw):\n \"\"\" Build the file given by module_path into a Python extension module.\n \n build_extensions uses distutils to build Python extension modules.\n kw arguments not used are passed on to the distutils extension\n module. Directory settings can handle absoulte settings, but don't\n currently expand '~' or environment variables.\n \n module_path -- the full path name to the c file to compile. \n Something like: /full/path/name/module_name.c \n The name of the c/c++ file should be the same as the\n name of the module (i.e. the initmodule() routine)\n compiler_name -- The name of the compiler to use. On Windows if it \n isn't given, MSVC is used if it exists (is found).\n gcc is used as a second choice. If neither are found, \n the default distutils compiler is used. Acceptable \n names are 'gcc', 'msvc' or any of the compiler names \n shown by distutils.ccompiler.show_compilers()\n build_dir -- The location where the resulting extension module \n should be placed. This location must be writable. If\n it isn't, several default locations are tried. If the \n build_dir is not in the current python path, a warning\n is emitted, and it is added to the end of the path.\n build_dir defaults to the current directory.\n temp_dir -- The location where temporary files (*.o or *.obj)\n from the build are placed. This location must be \n writable. If it isn't, several default locations are \n tried. It defaults to tempfile.gettempdir()\n verbose -- 0, 1, or 2. 0 is as quiet as possible. 1 prints\n minimal information. 2 is noisy. \n **kw -- keyword arguments. These are passed on to the \n distutils extension module. Most of the keywords\n are listed below.\n\n Distutils keywords. These are cut and pasted from Greg Ward's\n distutils.extension.Extension class for convenience:\n \n sources : [string]\n list of source filenames, relative to the distribution root\n (where the setup script lives), in Unix form (slash-separated)\n for portability. Source files may be C, C++, SWIG (.i),\n platform-specific resource files, or whatever else is recognized\n by the \"build_ext\" command as source for a Python extension.\n Note: The module_path file is always appended to the front of this\n list \n include_dirs : [string]\n list of directories to search for C/C++ header files (in Unix\n form for portability) \n define_macros : [(name : string, value : string|None)]\n list of macros to define; each macro is defined using a 2-tuple,\n where 'value' is either the string to define it to or None to\n define it without a particular value (equivalent of \"#define\n FOO\" in source or -DFOO on Unix C compiler command line) \n undef_macros : [string]\n list of macros to undefine explicitly\n library_dirs : [string]\n list of directories to search for C/C++ libraries at link time\n libraries : [string]\n list of library names (not filenames or paths) to link against\n runtime_library_dirs : [string]\n list of directories to search for C/C++ libraries at run time\n (for shared extensions, this is when the extension is loaded)\n extra_objects : [string]\n list of extra files to link with (eg. object files not implied\n by 'sources', static library that must be explicitly specified,\n binary resource files, etc.)\n extra_compile_args : [string]\n any extra platform- and compiler-specific information to use\n when compiling the source files in 'sources'. For platforms and\n compilers where \"command line\" makes sense, this is typically a\n list of command-line arguments, but for other platforms it could\n be anything.\n extra_link_args : [string]\n any extra platform- and compiler-specific information to use\n when linking object files together to create the extension (or\n to create a new static Python interpreter). Similar\n interpretation as for 'extra_compile_args'.\n export_symbols : [string]\n list of symbols to be exported from a shared extension. Not\n used on all platforms, and not generally necessary for Python\n extensions, which typically export exactly one symbol: \"init\" +\n extension_name.\n \"\"\"\n success = 0\n from distutils.core import setup, Extension\n \n # this is a screwy trick to get rid of a ton of warnings on Unix\n import distutils.sysconfig\n distutils.sysconfig.get_config_vars()\n if distutils.sysconfig._config_vars.has_key('OPT'):\n flags = distutils.sysconfig._config_vars['OPT'] \n flags = flags.replace('-Wall','')\n distutils.sysconfig._config_vars['OPT'] = flags\n \n # get the name of the module and the extension directory it lives in. \n module_dir,cpp_name = os.path.split(os.path.abspath(module_path))\n module_name,ext = os.path.splitext(cpp_name) \n \n # configure temp and build directories\n temp_dir = configure_temp_dir(temp_dir) \n build_dir = configure_build_dir(module_dir)\n \n compiler_name = choose_compiler(compiler_name)\n configure_sys_argv(compiler_name,temp_dir,build_dir)\n \n # the business end of the function\n try:\n if verbose == 1:\n print 'Compiling code...'\n \n # set compiler verboseness 2 or more makes it output results\n if verbose > 1: verb = 1 \n else: verb = 0\n \n t1 = time.time() \n # add module to the needed source code files and build extension\n sources = kw.get('sources',[])\n kw['sources'] = [module_path] + sources \n \n # add module to the needed source code files and build extension\n # FIX this is g++ specific. It probably should be fixed for other\n # Unices/compilers. Find a generic solution\n if sys.platform[:-1] == 'linux':\n libraries = kw.get('libraries',[])\n kw['libraries'] = ['stdc++'] + libraries \n ext = Extension(module_name, **kw)\n \n # the switcheroo on SystemExit here is meant to keep command line\n # sessions from exiting when compiles fail.\n builtin = sys.modules['__builtin__']\n old_SysExit = builtin.__dict__['SystemExit']\n builtin.__dict__['SystemExit'] = CompileError\n \n # distutils for MSVC messes with the environment, so we save the\n # current state and restore them afterward.\n import copy\n environ = copy.deepcopy(os.environ)\n try:\n setup(name = module_name, ext_modules = [ext],verbose=verb)\n finally:\n # restore state\n os.environ = environ \n # restore SystemExit\n builtin.__dict__['SystemExit'] = old_SysExit\n t2 = time.time()\n \n if verbose == 1:\n print 'finished compiling (sec): ', t2 - t1 \n success = 1\n configure_python_path(build_dir)\n except SyntaxError: #TypeError:\n success = 0 \n \n # restore argv after our trick... \n restore_sys_argv()\n \n return success\n\nold_argv = []\ndef configure_sys_argv(compiler_name,temp_dir,build_dir):\n # We're gonna play some tricks with argv here to pass info to distutils \n # which is really built for command line use. better way??\n global old_argv\n old_argv = sys.argv[:] \n sys.argv = ['','build_ext','--build-lib', build_dir,\n '--build-temp',temp_dir] \n if compiler_name == 'gcc':\n sys.argv.insert(2,'--compiler='+compiler_name)\n elif compiler_name:\n sys.argv.insert(2,'--compiler='+compiler_name)\n\ndef restore_sys_argv():\n sys.argv = old_argv\n \ndef configure_python_path(build_dir): \n #make sure the module lives in a directory on the python path.\n python_paths = [os.path.abspath(x) for x in sys.path]\n if os.path.abspath(build_dir) not in python_paths:\n #print \"warning: build directory was not part of python path.\"\\\n # \" It has been appended to the path.\"\n sys.path.append(os.path.abspath(build_dir))\n\ndef choose_compiler(compiler_name=''):\n \"\"\" Try and figure out which compiler is gonna be used on windows.\n On other platforms, it just returns whatever value it is given.\n \n converts 'gcc' to 'mingw32' on win32\n \"\"\"\n if sys.platform == 'win32': \n if not compiler_name:\n # On Windows, default to MSVC and use gcc if it wasn't found\n # wasn't found. If neither are found, go with whatever\n # the default is for distutils -- and probably fail...\n if msvc_exists():\n compiler_name = 'msvc'\n elif gcc_exists():\n compiler_name = 'mingw32'\n elif compiler_name == 'gcc':\n compiler_name = 'mingw32'\n else:\n # don't know how to force gcc -- look into this.\n if compiler_name == 'gcc':\n compiler_name = 'unix' \n return compiler_name\n \ndef gcc_exists():\n \"\"\" Test to make sure gcc is found \n \n Does this return correct value on win98???\n \"\"\"\n result = 0\n try:\n w,r=os.popen4('gcc -v')\n w.close()\n str_result = r.read()\n #print str_result\n if string.find(str_result,'Reading specs') != -1:\n result = 1\n except:\n # This was needed because the msvc compiler messes with\n # the path variable. and will occasionlly mess things up\n # so much that gcc is lost in the path. (Occurs in test\n # scripts)\n result = not os.system('gcc -v')\n return result\n\ndef msvc_exists():\n \"\"\" Determine whether MSVC is available on the machine.\n \"\"\"\n result = 0\n try:\n w,r=os.popen4('cl')\n w.close()\n str_result = r.read()\n #print str_result\n if string.find(str_result,'Microsoft') != -1:\n result = 1\n except:\n #assume we're ok if devstudio exists\n import distutils.msvccompiler\n version = distutils.msvccompiler.get_devstudio_version()\n if version:\n result = 1\n return result\n\ndef configure_temp_dir(temp_dir=None):\n if temp_dir is None: \n temp_dir = tempfile.gettempdir()\n elif not os.path.exists(temp_dir) or not os.access(temp_dir,os.W_OK):\n print \"warning: specified temp_dir '%s' does not exist or is \" \\\n \"or is not writable. Using the default temp directory\" % \\\n temp_dir\n temp_dir = tempfile.gettempdir()\n\n # final check that that directories are writable. \n if not os.access(temp_dir,os.W_OK):\n msg = \"Either the temp or build directory wasn't writable. Check\" \\\n \" these locations: '%s'\" % temp_dir \n raise ValueError, msg\n return temp_dir\n\ndef configure_build_dir(build_dir=None):\n # make sure build_dir exists and is writable\n if build_dir and (not os.path.exists(build_dir) or \n not os.access(build_dir,os.W_OK)):\n print \"warning: specified build_dir '%s' does not exist or is \" \\\n \"or is not writable. Trying default locations\" % build_dir\n build_dir = None\n \n if build_dir is None:\n #default to building in the home directory of the given module. \n build_dir = os.curdir\n # if it doesn't work use the current directory. This should always\n # be writable. \n if not os.access(build_dir,os.W_OK):\n print \"warning:, neither the module's directory nor the \"\\\n \"current directory are writable. Using the temporary\"\\\n \"directory.\"\n build_dir = tempfile.gettempdir()\n\n # final check that that directories are writable.\n if not os.access(build_dir,os.W_OK):\n msg = \"The build directory wasn't writable. Check\" \\\n \" this location: '%s'\" % build_dir\n raise ValueError, msg\n \n return os.path.abspath(build_dir) \n \nif sys.platform == 'win32':\n import distutils.cygwinccompiler\n # the same as cygwin plus some additional parameters\n class Mingw32CCompiler (distutils.cygwinccompiler.CygwinCCompiler):\n \"\"\" A modified MingW32 compiler compatible with an MSVC built Python.\n \n \"\"\"\n \n compiler_type = 'mingw32'\n \n def __init__ (self,\n verbose=0,\n dry_run=0,\n force=0):\n \n distutils.cygwinccompiler.CygwinCCompiler.__init__ (self, verbose, \n dry_run, force)\n \n # A real mingw32 doesn't need to specify a different entry point,\n # but cygwin 2.91.57 in no-cygwin-mode needs it.\n if self.gcc_version <= \"2.91.57\":\n entry_point = '--entry _DllMain@12'\n else:\n entry_point = ''\n if self.linker_dll == 'dllwrap':\n self.linker = 'dllwrap' + ' --driver-name g++'\n elif self.linker_dll == 'gcc':\n self.linker = 'g++' \n # **changes: eric jones 4/11/01\n # 1. Check for import library on Windows. Build if it doesn't exist.\n if not import_library_exists():\n build_import_library()\n \n # **changes: eric jones 4/11/01\n # 2. increased optimization and turned off all warnings\n # 3. also added --driver-name g++\n #self.set_executables(compiler='gcc -mno-cygwin -O2 -w',\n # compiler_so='gcc -mno-cygwin -mdll -O2 -w',\n # linker_exe='gcc -mno-cygwin',\n # linker_so='%s --driver-name g++ -mno-cygwin -mdll -static %s' \n # % (self.linker, entry_point))\n self.set_executables(compiler='g++ -mno-cygwin -O2 -w',\n compiler_so='g++ -mno-cygwin -mdll -O2 -w -Wstrict-prototypes',\n linker_exe='g++ -mno-cygwin',\n linker_so='%s -mno-cygwin -mdll -static %s' \n % (self.linker, entry_point))\n \n # Maybe we should also append -mthreads, but then the finished\n # dlls need another dll (mingwm10.dll see Mingw32 docs)\n # (-mthreads: Support thread-safe exception handling on `Mingw32') \n \n # no additional libraries needed \n self.dll_libraries=[]\n \n # __init__ ()\n \n # On windows platforms, we want to default to mingw32 (gcc)\n # because msvc can't build blitz stuff.\n # We should also check the version of gcc available...\n #distutils.ccompiler._default_compilers['nt'] = 'mingw32'\n #distutils.ccompiler._default_compilers = (('nt', 'mingw32'))\n # reset the Mingw32 compiler in distutils to the one defined above\n distutils.cygwinccompiler.Mingw32CCompiler = Mingw32CCompiler\n \n def import_library_exists():\n \"\"\" on windows platforms, make sure a gcc import library exists\n \"\"\"\n if os.name == 'nt':\n lib_name = \"libpython%d%d.a\" % tuple(sys.version_info[:2])\n full_path = os.path.join(sys.prefix,'libs',lib_name)\n if not os.path.exists(full_path):\n return 0\n return 1\n \n def build_import_library():\n \"\"\" Build the import libraries for Mingw32-gcc on Windows\n \"\"\"\n import lib2def as lib2def\n #libfile, deffile = parse_cmd()\n #if deffile == None:\n # deffile = sys.stdout\n #else:\n # deffile = open(deffile, 'w')\n lib_name = \"python%d%d.lib\" % tuple(sys.version_info[:2]) \n lib_file = os.path.join(sys.prefix,'libs',lib_name)\n def_name = \"python%d%d.def\" % tuple(sys.version_info[:2]) \n def_file = os.path.join(sys.prefix,'libs',def_name)\n nm_cmd = '%s %s' % (lib2def.DEFAULT_NM, lib_file)\n nm_output = lib2def.getnm(nm_cmd)\n dlist, flist = lib2def.parse_nm(nm_output)\n lib2def.output_def(dlist, flist, lib2def.DEF_HEADER, open(def_file, 'w'))\n \n out_name = \"libpython%d%d.a\" % tuple(sys.version_info[:2])\n out_file = os.path.join(sys.prefix,'libs',out_name)\n dll_name = \"python%d%d.dll\" % tuple(sys.version_info[:2])\n args = (dll_name,def_file,out_file)\n cmd = 'dlltool --dllname %s --def %s --output-lib %s' % args\n success = not os.system(cmd)\n # for now, fail silently\n if not success:\n print 'WARNING: failed to build import library for gcc. Linking will fail.'\n #if not success:\n # msg = \"Couldn't find import library, and failed to build it.\"\n # raise DistutilsPlatformError, msg\n \ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n\n\n\n", "methods": [ { "name": "build_extension", "long_name": "build_extension( module_path , compiler_name = '' , build_dir = None , temp_dir = None , verbose = 0 , ** kw )", "filename": "build_tools.py", "nloc": 47, "complexity": 8, "token_count": 336, "parameters": [ "module_path", "compiler_name", "build_dir", "temp_dir", "verbose", "kw" ], "start_line": 27, "end_line": 184, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 158, "top_nesting_level": 0 }, { "name": "configure_sys_argv", "long_name": "configure_sys_argv( compiler_name , temp_dir , build_dir )", "filename": "build_tools.py", "nloc": 9, "complexity": 3, "token_count": 68, "parameters": [ "compiler_name", "temp_dir", "build_dir" ], "start_line": 187, "end_line": 197, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 }, { "name": "restore_sys_argv", "long_name": "restore_sys_argv( )", "filename": "build_tools.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [], "start_line": 199, "end_line": 200, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "configure_python_path", "long_name": "configure_python_path( build_dir )", "filename": "build_tools.py", "nloc": 4, "complexity": 3, "token_count": 51, "parameters": [ "build_dir" ], "start_line": 202, "end_line": 208, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "choose_compiler", "long_name": "choose_compiler( compiler_name = '' )", "filename": "build_tools.py", "nloc": 13, "complexity": 7, "token_count": 55, "parameters": [ "compiler_name" ], "start_line": 210, "end_line": 231, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 0 }, { "name": "gcc_exists", "long_name": "gcc_exists( )", "filename": "build_tools.py", "nloc": 11, "complexity": 3, "token_count": 61, "parameters": [], "start_line": 233, "end_line": 252, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 }, { "name": "msvc_exists", "long_name": "msvc_exists( )", "filename": "build_tools.py", "nloc": 14, "complexity": 4, "token_count": 71, "parameters": [], "start_line": 254, "end_line": 271, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 0 }, { "name": "configure_temp_dir", "long_name": "configure_temp_dir( temp_dir = None )", "filename": "build_tools.py", "nloc": 13, "complexity": 5, "token_count": 82, "parameters": [ "temp_dir" ], "start_line": 273, "end_line": 287, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "configure_build_dir", "long_name": "configure_build_dir( build_dir = None )", "filename": "build_tools.py", "nloc": 18, "complexity": 7, "token_count": 112, "parameters": [ "build_dir" ], "start_line": 289, "end_line": 314, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "__init__", "long_name": "__init__( self , verbose = 0 , dry_run = 0 , force = 0 )", "filename": "build_tools.py", "nloc": 22, "complexity": 5, "token_count": 117, "parameters": [ "self", "verbose", "dry_run", "force" ], "start_line": 326, "end_line": 368, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 43, "top_nesting_level": 2 }, { "name": "import_library_exists", "long_name": "import_library_exists( )", "filename": "build_tools.py", "nloc": 7, "complexity": 3, "token_count": 57, "parameters": [], "start_line": 380, "end_line": 388, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "build_import_library", "long_name": "build_import_library( )", "filename": "build_tools.py", "nloc": 18, "complexity": 2, "token_count": 190, "parameters": [], "start_line": 390, "end_line": 416, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 27, "top_nesting_level": 1 }, { "name": "test", "long_name": "test( )", "filename": "build_tools.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 421, "end_line": 423, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "build_tools.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 425, "end_line": 427, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "methods_before": [ { "name": "build_extension", "long_name": "build_extension( module_path , compiler_name = '' , build_dir = None , temp_dir = None , verbose = 0 , ** kw )", "filename": "build_tools.py", "nloc": 47, "complexity": 8, "token_count": 343, "parameters": [ "module_path", "compiler_name", "build_dir", "temp_dir", "verbose", "kw" ], "start_line": 27, "end_line": 184, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 158, "top_nesting_level": 0 }, { "name": "configure_sys_argv", "long_name": "configure_sys_argv( compiler_name , temp_dir , build_dir )", "filename": "build_tools.py", "nloc": 9, "complexity": 3, "token_count": 68, "parameters": [ "compiler_name", "temp_dir", "build_dir" ], "start_line": 187, "end_line": 197, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 }, { "name": "restore_sys_argv", "long_name": "restore_sys_argv( )", "filename": "build_tools.py", "nloc": 2, "complexity": 1, "token_count": 9, "parameters": [], "start_line": 199, "end_line": 200, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "configure_python_path", "long_name": "configure_python_path( build_dir )", "filename": "build_tools.py", "nloc": 4, "complexity": 3, "token_count": 51, "parameters": [ "build_dir" ], "start_line": 202, "end_line": 208, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "choose_compiler", "long_name": "choose_compiler( compiler_name = '' )", "filename": "build_tools.py", "nloc": 13, "complexity": 7, "token_count": 55, "parameters": [ "compiler_name" ], "start_line": 210, "end_line": 231, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 0 }, { "name": "gcc_exists", "long_name": "gcc_exists( )", "filename": "build_tools.py", "nloc": 11, "complexity": 3, "token_count": 61, "parameters": [], "start_line": 233, "end_line": 252, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 }, { "name": "msvc_exists", "long_name": "msvc_exists( )", "filename": "build_tools.py", "nloc": 14, "complexity": 4, "token_count": 71, "parameters": [], "start_line": 254, "end_line": 271, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 0 }, { "name": "configure_temp_dir", "long_name": "configure_temp_dir( temp_dir = None )", "filename": "build_tools.py", "nloc": 13, "complexity": 5, "token_count": 82, "parameters": [ "temp_dir" ], "start_line": 273, "end_line": 287, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "configure_build_dir", "long_name": "configure_build_dir( build_dir = None )", "filename": "build_tools.py", "nloc": 18, "complexity": 7, "token_count": 112, "parameters": [ "build_dir" ], "start_line": 289, "end_line": 314, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "__init__", "long_name": "__init__( self , verbose = 0 , dry_run = 0 , force = 0 )", "filename": "build_tools.py", "nloc": 22, "complexity": 5, "token_count": 117, "parameters": [ "self", "verbose", "dry_run", "force" ], "start_line": 326, "end_line": 368, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 43, "top_nesting_level": 2 }, { "name": "import_library_exists", "long_name": "import_library_exists( )", "filename": "build_tools.py", "nloc": 7, "complexity": 3, "token_count": 57, "parameters": [], "start_line": 380, "end_line": 388, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "build_import_library", "long_name": "build_import_library( )", "filename": "build_tools.py", "nloc": 18, "complexity": 2, "token_count": 190, "parameters": [], "start_line": 390, "end_line": 416, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 27, "top_nesting_level": 1 }, { "name": "test", "long_name": "test( )", "filename": "build_tools.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 421, "end_line": 423, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "build_tools.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 425, "end_line": 427, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "build_extension", "long_name": "build_extension( module_path , compiler_name = '' , build_dir = None , temp_dir = None , verbose = 0 , ** kw )", "filename": "build_tools.py", "nloc": 47, "complexity": 8, "token_count": 336, "parameters": [ "module_path", "compiler_name", "build_dir", "temp_dir", "verbose", "kw" ], "start_line": 27, "end_line": 184, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 158, "top_nesting_level": 0 } ], "nloc": 216, "complexity": 53, "token_count": 1310, "diff_parsed": { "added": [ " if compiler_name != 'msvc':" ], "deleted": [ " if sys.platform[:-1] == 'linux':" ] } } ] }, { "hash": "c1a5d613bb52d1ae45cc8bb90e056c9181cad18b", "msg": "refined get_version", "author": { "name": "Pearu Peterson", "email": "pearu.peterson@gmail.com" }, "committer": { "name": "Pearu Peterson", "email": "pearu.peterson@gmail.com" }, "author_date": "2002-01-05T12:02:28+00:00", "author_timezone": 0, "committer_date": "2002-01-05T12:02:28+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "2547260e6e69c2fd4f0527ca464e9fe4612623d8" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 29, "insertions": 102, "lines": 131, "files": 3, "dmm_unit_size": 0.0, "dmm_unit_complexity": 0.0, "dmm_unit_interfacing": 0.06521739130434782, "modified_files": [ { "old_path": null, "new_path": "scipy_distutils/__version__.py", "filename": "__version__.py", "extension": "py", "change_type": "ADD", "diff": "@@ -0,0 +1,4 @@\n+# This file is automatically updated with get_version\n+# function from scipy_distutils.misc_utils.py\n+version = '0.1.19-alpha-45'\n+version_info = (0, 1, 19, 'alpha', 45)\n", "added_lines": 4, "deleted_lines": 0, "source_code": "# This file is automatically updated with get_version\n# function from scipy_distutils.misc_utils.py\nversion = '0.1.19-alpha-45'\nversion_info = (0, 1, 19, 'alpha', 45)\n", "source_code_before": null, "methods": [], "methods_before": [], "changed_methods": [], "nloc": 2, "complexity": 0, "token_count": 16, "diff_parsed": { "added": [ "# This file is automatically updated with get_version", "# function from scipy_distutils.misc_utils.py", "version = '0.1.19-alpha-45'", "version_info = (0, 1, 19, 'alpha', 45)" ], "deleted": [] } }, { "old_path": "scipy_distutils/misc_util.py", "new_path": "scipy_distutils/misc_util.py", "filename": "misc_util.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -1,36 +1,108 @@\n import os,sys,string\n \n-def get_version(major,minor,path = '.'):\n+def get_version(release_level='alpha', path='.', major=None):\n \"\"\"\n- Return a version string calculated from a CVS tree starting at\n- path. The micro version number is found as a sum of the last bits\n- of the revision numbers listed in CVS/Entries. If /CVS does\n- not exists, get_version tries to get the version from the\n- /__version__.py file where __version__ variable should be\n- defined. If that also fails, then return None.\n+ Return version string calculated from CVS tree or found in\n+ /__version__.py. Automatically update /__version__.py\n+ if the version is changed.\n+ An attempt is made to guarantee that version is increasing in\n+ time. This function always succeeds. None is returned if no\n+ version information is available.\n+\n+ Version string is in the form\n+\n+ ..--\n+\n+ and its items have the following meanings:\n+ serial - shows cumulative changes in all files in the CVS\n+ repository\n+ micro - a number that is equivalent to the number of files\n+ minor - indicates the changes in micro value (files are added\n+ or removed)\n+ release_level - is alpha, beta, canditate, or final\n+ major - indicates changes in release_level.\n+ \"\"\"\n+\n+ release_level_map = {'alpha':0,\n+ 'beta':1,\n+ 'canditate':2,\n+ 'final':3}\n+ release_level_value = release_level_map.get(release_level)\n+ if release_level_value is None:\n+ print 'Warning: release_level=%s is not %s'\\\n+ % (release_level,\n+ string.join(release_level_map.keys(),','))\n+\n+ cwd = os.getcwd()\n+ os.chdir(path)\n+ try:\n+ version_module = __import__('__version__')\n+ reload(version_module)\n+ old_version_info = version_module.version_info\n+ old_version = version_module.version\n+ except:\n+ print sys.exc_value\n+ old_version_info = None\n+ old_version = None\n+ os.chdir(cwd)\n+\n+ cvs_revs = get_cvs_version(path)\n+ if cvs_revs is None:\n+ return old_version\n+\n+ minor = 1\n+ micro,serial = cvs_revs\n+ if old_version_info is not None:\n+ minor = old_version_info[1]\n+ old_release_level_value = release_level_map.get(old_version_info[3])\n+ if micro != old_version_info[2]: # files have beed added or removed\n+ minor = minor + 1\n+ if major is None:\n+ major = old_version_info[0]\n+ if old_release_level_value is not None:\n+ if old_release_level_value > release_level_value:\n+ major = major + 1\n+ if major is None:\n+ major = 0\n+\n+ version_info = (major,minor,micro,release_level,serial)\n+ version = '%s.%s.%s-%s-%s' % version_info\n+\n+ if version != old_version:\n+ print 'updating version: %s -> %s'%(old_version,version)\n+ version_file = os.path.abspath(os.path.join(path,'__version__.py'))\n+ f = open(version_file,'w')\n+ f.write('# This file is automatically updated with get_version\\n'\\\n+ '# function from scipy_distutils.misc_utils.py\\n'\\\n+ 'version = %s\\n'\\\n+ 'version_info = %s\\n'%(repr(version),version_info))\n+ f.close()\n+ return version\n+\n+def get_cvs_version(path):\n+ \"\"\"\n+ Return two last cumulative revision numbers of a CVS tree starting\n+ at . The first number shows the number of files in the CVS\n+ tree (this is often true, but not always) and the second number\n+ characterizes the changes in these files.\n+ If /CVS/Entries is not existing then return None.\n \"\"\"\n- micro = get_micro_version(os.path.abspath(path))\n- if micro is None:\n- try:\n- return __import__(os.path.join(path,'__version__.py')).__version__\n- except:\n- return\n- return '%s.%s.%s'%(major,minor,micro)\n-\n-def get_micro_version(path):\n- # micro version number should be increasing in time, unless a file\n- # is removed from the CVS source tree. In that case one should\n- # increase the minor version number.\n entries_file = os.path.join(path,'CVS','Entries')\n if os.path.exists(entries_file):\n- micro = 0\n+ rev1,rev2 = 0,0\n for line in open(entries_file).readlines():\n items = string.split(line,'/')\n- if items[0] == 'D' and len(items)>1:\n- micro = micro + get_micro_version(os.path.join(path,items[1]))\n- elif items[0] == '' and len(items)>2:\n- micro = micro + eval(string.split(items[2],'.')[-1])\n- return micro\n+ if items[0]=='D' and len(items)>1:\n+ try:\n+ d1,d2 = get_cvs_version(os.path.join(path,items[1]))\n+ except:\n+ d1,d2 = 0,0\n+ elif items[0]=='' and len(items)>3 and items[1]!='__version__.py':\n+ d1,d2 = map(eval,string.split(items[2],'.')[-2:])\n+ else:\n+ continue\n+ rev1,rev2 = rev1+d1,rev2+d2\n+ return rev1,rev2\n \n def get_path(mod_name):\n \"\"\" This function makes sure installation is done from the\n", "added_lines": 97, "deleted_lines": 25, "source_code": "import os,sys,string\n\ndef get_version(release_level='alpha', path='.', major=None):\n \"\"\"\n Return version string calculated from CVS tree or found in\n /__version__.py. Automatically update /__version__.py\n if the version is changed.\n An attempt is made to guarantee that version is increasing in\n time. This function always succeeds. None is returned if no\n version information is available.\n\n Version string is in the form\n\n ..--\n\n and its items have the following meanings:\n serial - shows cumulative changes in all files in the CVS\n repository\n micro - a number that is equivalent to the number of files\n minor - indicates the changes in micro value (files are added\n or removed)\n release_level - is alpha, beta, canditate, or final\n major - indicates changes in release_level.\n \"\"\"\n\n release_level_map = {'alpha':0,\n 'beta':1,\n 'canditate':2,\n 'final':3}\n release_level_value = release_level_map.get(release_level)\n if release_level_value is None:\n print 'Warning: release_level=%s is not %s'\\\n % (release_level,\n string.join(release_level_map.keys(),','))\n\n cwd = os.getcwd()\n os.chdir(path)\n try:\n version_module = __import__('__version__')\n reload(version_module)\n old_version_info = version_module.version_info\n old_version = version_module.version\n except:\n print sys.exc_value\n old_version_info = None\n old_version = None\n os.chdir(cwd)\n\n cvs_revs = get_cvs_version(path)\n if cvs_revs is None:\n return old_version\n\n minor = 1\n micro,serial = cvs_revs\n if old_version_info is not None:\n minor = old_version_info[1]\n old_release_level_value = release_level_map.get(old_version_info[3])\n if micro != old_version_info[2]: # files have beed added or removed\n minor = minor + 1\n if major is None:\n major = old_version_info[0]\n if old_release_level_value is not None:\n if old_release_level_value > release_level_value:\n major = major + 1\n if major is None:\n major = 0\n\n version_info = (major,minor,micro,release_level,serial)\n version = '%s.%s.%s-%s-%s' % version_info\n\n if version != old_version:\n print 'updating version: %s -> %s'%(old_version,version)\n version_file = os.path.abspath(os.path.join(path,'__version__.py'))\n f = open(version_file,'w')\n f.write('# This file is automatically updated with get_version\\n'\\\n '# function from scipy_distutils.misc_utils.py\\n'\\\n 'version = %s\\n'\\\n 'version_info = %s\\n'%(repr(version),version_info))\n f.close()\n return version\n\ndef get_cvs_version(path):\n \"\"\"\n Return two last cumulative revision numbers of a CVS tree starting\n at . The first number shows the number of files in the CVS\n tree (this is often true, but not always) and the second number\n characterizes the changes in these files.\n If /CVS/Entries is not existing then return None.\n \"\"\"\n entries_file = os.path.join(path,'CVS','Entries')\n if os.path.exists(entries_file):\n rev1,rev2 = 0,0\n for line in open(entries_file).readlines():\n items = string.split(line,'/')\n if items[0]=='D' and len(items)>1:\n try:\n d1,d2 = get_cvs_version(os.path.join(path,items[1]))\n except:\n d1,d2 = 0,0\n elif items[0]=='' and len(items)>3 and items[1]!='__version__.py':\n d1,d2 = map(eval,string.split(items[2],'.')[-2:])\n else:\n continue\n rev1,rev2 = rev1+d1,rev2+d2\n return rev1,rev2\n\ndef get_path(mod_name):\n \"\"\" This function makes sure installation is done from the\n correct directory no matter if it is installed from the\n command line or from another package or run_setup function.\n \n \"\"\"\n if mod_name == '__main__':\n d = os.path.abspath('.')\n elif mod_name == '__builtin__':\n #builtin if/then added by Pearu for use in core.run_setup. \n d = os.path.dirname(os.path.abspath(sys.argv[0]))\n else:\n #import scipy_distutils.setup\n mod = __import__(mod_name)\n file = mod.__file__\n d = os.path.dirname(os.path.abspath(file))\n return d\n \ndef add_local_to_path(mod_name):\n local_path = get_path(mod_name)\n sys.path.insert(0,local_path)\n \ndef add_grandparent_to_path(mod_name):\n local_path = get_path(mod_name)\n gp_dir = os.path.split(local_path)[0]\n sys.path.insert(0,gp_dir)\n\ndef restore_path():\n del sys.path[0]\n\ndef append_package_dir_to_path(package_name): \n \"\"\" Search for a directory with package_name and append it to PYTHONPATH\n \n The local directory is searched first and then the parent directory.\n \"\"\"\n # first see if it is in the current path\n # then try parent. If it isn't found, fail silently\n # and let the import error occur.\n \n # not an easy way to clean up after this...\n import os,sys\n if os.path.exists(package_name):\n sys.path.append(package_name)\n elif os.path.exists(os.path.join('..',package_name)):\n sys.path.append(os.path.join('..',package_name))\n\ndef get_package_config(package_name):\n \"\"\" grab the configuration info from the setup_xxx.py file\n in a package directory. The package directory is searched\n from the current directory, so setting the path to the\n setup.py file directory of the file calling this is usually\n needed to get search the path correct.\n \"\"\"\n append_package_dir_to_path(package_name)\n mod = __import__('setup_'+package_name)\n config = mod.configuration()\n return config\n\ndef package_config(primary,dependencies=[]):\n \"\"\" Create a configuration dictionary ready for setup.py from\n a list of primary and dependent package names. Each\n package listed must have a directory with the same name\n in the current or parent working directory. Further, it\n should have a setup_xxx.py module within that directory that\n has a configuration() file in it. \n \"\"\"\n config = []\n config.extend([get_package_config(x) for x in primary])\n config.extend([get_package_config(x) for x in dependencies]) \n config_dict = merge_config_dicts(config)\n return config_dict\n \nlist_keys = ['packages', 'ext_modules', 'data_files',\n 'include_dirs', 'libraries', 'fortran_libraries',\n 'headers']\ndict_keys = ['package_dir'] \n\ndef default_config_dict():\n d={}\n for key in list_keys: d[key] = []\n for key in dict_keys: d[key] = {}\n return d\n\ndef merge_config_dicts(config_list):\n result = default_config_dict() \n for d in config_list:\n for key in list_keys:\n result[key].extend(d.get(key,[]))\n for key in dict_keys:\n result[key].update(d.get(key,{}))\n return result\n", "source_code_before": "import os,sys,string\n\ndef get_version(major,minor,path = '.'):\n \"\"\"\n Return a version string calculated from a CVS tree starting at\n path. The micro version number is found as a sum of the last bits\n of the revision numbers listed in CVS/Entries. If /CVS does\n not exists, get_version tries to get the version from the\n /__version__.py file where __version__ variable should be\n defined. If that also fails, then return None.\n \"\"\"\n micro = get_micro_version(os.path.abspath(path))\n if micro is None:\n try:\n return __import__(os.path.join(path,'__version__.py')).__version__\n except:\n return\n return '%s.%s.%s'%(major,minor,micro)\n\ndef get_micro_version(path):\n # micro version number should be increasing in time, unless a file\n # is removed from the CVS source tree. In that case one should\n # increase the minor version number.\n entries_file = os.path.join(path,'CVS','Entries')\n if os.path.exists(entries_file):\n micro = 0\n for line in open(entries_file).readlines():\n items = string.split(line,'/')\n if items[0] == 'D' and len(items)>1:\n micro = micro + get_micro_version(os.path.join(path,items[1]))\n elif items[0] == '' and len(items)>2:\n micro = micro + eval(string.split(items[2],'.')[-1])\n return micro\n\ndef get_path(mod_name):\n \"\"\" This function makes sure installation is done from the\n correct directory no matter if it is installed from the\n command line or from another package or run_setup function.\n \n \"\"\"\n if mod_name == '__main__':\n d = os.path.abspath('.')\n elif mod_name == '__builtin__':\n #builtin if/then added by Pearu for use in core.run_setup. \n d = os.path.dirname(os.path.abspath(sys.argv[0]))\n else:\n #import scipy_distutils.setup\n mod = __import__(mod_name)\n file = mod.__file__\n d = os.path.dirname(os.path.abspath(file))\n return d\n \ndef add_local_to_path(mod_name):\n local_path = get_path(mod_name)\n sys.path.insert(0,local_path)\n \ndef add_grandparent_to_path(mod_name):\n local_path = get_path(mod_name)\n gp_dir = os.path.split(local_path)[0]\n sys.path.insert(0,gp_dir)\n\ndef restore_path():\n del sys.path[0]\n\ndef append_package_dir_to_path(package_name): \n \"\"\" Search for a directory with package_name and append it to PYTHONPATH\n \n The local directory is searched first and then the parent directory.\n \"\"\"\n # first see if it is in the current path\n # then try parent. If it isn't found, fail silently\n # and let the import error occur.\n \n # not an easy way to clean up after this...\n import os,sys\n if os.path.exists(package_name):\n sys.path.append(package_name)\n elif os.path.exists(os.path.join('..',package_name)):\n sys.path.append(os.path.join('..',package_name))\n\ndef get_package_config(package_name):\n \"\"\" grab the configuration info from the setup_xxx.py file\n in a package directory. The package directory is searched\n from the current directory, so setting the path to the\n setup.py file directory of the file calling this is usually\n needed to get search the path correct.\n \"\"\"\n append_package_dir_to_path(package_name)\n mod = __import__('setup_'+package_name)\n config = mod.configuration()\n return config\n\ndef package_config(primary,dependencies=[]):\n \"\"\" Create a configuration dictionary ready for setup.py from\n a list of primary and dependent package names. Each\n package listed must have a directory with the same name\n in the current or parent working directory. Further, it\n should have a setup_xxx.py module within that directory that\n has a configuration() file in it. \n \"\"\"\n config = []\n config.extend([get_package_config(x) for x in primary])\n config.extend([get_package_config(x) for x in dependencies]) \n config_dict = merge_config_dicts(config)\n return config_dict\n \nlist_keys = ['packages', 'ext_modules', 'data_files',\n 'include_dirs', 'libraries', 'fortran_libraries',\n 'headers']\ndict_keys = ['package_dir'] \n\ndef default_config_dict():\n d={}\n for key in list_keys: d[key] = []\n for key in dict_keys: d[key] = {}\n return d\n\ndef merge_config_dicts(config_list):\n result = default_config_dict() \n for d in config_list:\n for key in list_keys:\n result[key].extend(d.get(key,[]))\n for key in dict_keys:\n result[key].update(d.get(key,{}))\n return result\n", "methods": [ { "name": "get_version", "long_name": "get_version( release_level = 'alpha' , path = '.' , major = None )", "filename": "misc_util.py", "nloc": 51, "complexity": 11, "token_count": 299, "parameters": [ "release_level", "path", "major" ], "start_line": 3, "end_line": 80, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 78, "top_nesting_level": 0 }, { "name": "get_cvs_version", "long_name": "get_cvs_version( path )", "filename": "misc_util.py", "nloc": 17, "complexity": 9, "token_count": 170, "parameters": [ "path" ], "start_line": 82, "end_line": 105, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 24, "top_nesting_level": 0 }, { "name": "get_path", "long_name": "get_path( mod_name )", "filename": "misc_util.py", "nloc": 10, "complexity": 3, "token_count": 80, "parameters": [ "mod_name" ], "start_line": 107, "end_line": 123, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 0 }, { "name": "add_local_to_path", "long_name": "add_local_to_path( mod_name )", "filename": "misc_util.py", "nloc": 3, "complexity": 1, "token_count": 21, "parameters": [ "mod_name" ], "start_line": 125, "end_line": 127, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "add_grandparent_to_path", "long_name": "add_grandparent_to_path( mod_name )", "filename": "misc_util.py", "nloc": 4, "complexity": 1, "token_count": 34, "parameters": [ "mod_name" ], "start_line": 129, "end_line": 132, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 0 }, { "name": "restore_path", "long_name": "restore_path( )", "filename": "misc_util.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [], "start_line": 134, "end_line": 135, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "append_package_dir_to_path", "long_name": "append_package_dir_to_path( package_name )", "filename": "misc_util.py", "nloc": 6, "complexity": 3, "token_count": 64, "parameters": [ "package_name" ], "start_line": 137, "end_line": 151, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "get_package_config", "long_name": "get_package_config( package_name )", "filename": "misc_util.py", "nloc": 5, "complexity": 1, "token_count": 27, "parameters": [ "package_name" ], "start_line": 153, "end_line": 163, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 }, { "name": "package_config", "long_name": "package_config( primary , dependencies = [ ] )", "filename": "misc_util.py", "nloc": 6, "complexity": 3, "token_count": 53, "parameters": [ "primary", "dependencies" ], "start_line": 165, "end_line": 177, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 0 }, { "name": "default_config_dict", "long_name": "default_config_dict( )", "filename": "misc_util.py", "nloc": 5, "complexity": 3, "token_count": 34, "parameters": [], "start_line": 184, "end_line": 188, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 }, { "name": "merge_config_dicts", "long_name": "merge_config_dicts( config_list )", "filename": "misc_util.py", "nloc": 8, "complexity": 4, "token_count": 61, "parameters": [ "config_list" ], "start_line": 190, "end_line": 197, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 0 } ], "methods_before": [ { "name": "get_version", "long_name": "get_version( major , minor , path = '.' )", "filename": "misc_util.py", "nloc": 8, "complexity": 3, "token_count": 61, "parameters": [ "major", "minor", "path" ], "start_line": 3, "end_line": 18, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 0 }, { "name": "get_micro_version", "long_name": "get_micro_version( path )", "filename": "misc_util.py", "nloc": 11, "complexity": 7, "token_count": 128, "parameters": [ "path" ], "start_line": 20, "end_line": 33, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 0 }, { "name": "get_path", "long_name": "get_path( mod_name )", "filename": "misc_util.py", "nloc": 10, "complexity": 3, "token_count": 80, "parameters": [ "mod_name" ], "start_line": 35, "end_line": 51, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 0 }, { "name": "add_local_to_path", "long_name": "add_local_to_path( mod_name )", "filename": "misc_util.py", "nloc": 3, "complexity": 1, "token_count": 21, "parameters": [ "mod_name" ], "start_line": 53, "end_line": 55, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "add_grandparent_to_path", "long_name": "add_grandparent_to_path( mod_name )", "filename": "misc_util.py", "nloc": 4, "complexity": 1, "token_count": 34, "parameters": [ "mod_name" ], "start_line": 57, "end_line": 60, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 0 }, { "name": "restore_path", "long_name": "restore_path( )", "filename": "misc_util.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [], "start_line": 62, "end_line": 63, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "append_package_dir_to_path", "long_name": "append_package_dir_to_path( package_name )", "filename": "misc_util.py", "nloc": 6, "complexity": 3, "token_count": 64, "parameters": [ "package_name" ], "start_line": 65, "end_line": 79, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "get_package_config", "long_name": "get_package_config( package_name )", "filename": "misc_util.py", "nloc": 5, "complexity": 1, "token_count": 27, "parameters": [ "package_name" ], "start_line": 81, "end_line": 91, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 }, { "name": "package_config", "long_name": "package_config( primary , dependencies = [ ] )", "filename": "misc_util.py", "nloc": 6, "complexity": 3, "token_count": 53, "parameters": [ "primary", "dependencies" ], "start_line": 93, "end_line": 105, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 0 }, { "name": "default_config_dict", "long_name": "default_config_dict( )", "filename": "misc_util.py", "nloc": 5, "complexity": 3, "token_count": 34, "parameters": [], "start_line": 112, "end_line": 116, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 }, { "name": "merge_config_dicts", "long_name": "merge_config_dicts( config_list )", "filename": "misc_util.py", "nloc": 8, "complexity": 4, "token_count": 61, "parameters": [ "config_list" ], "start_line": 118, "end_line": 125, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "get_cvs_version", "long_name": "get_cvs_version( path )", "filename": "misc_util.py", "nloc": 17, "complexity": 9, "token_count": 170, "parameters": [ "path" ], "start_line": 82, "end_line": 105, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 24, "top_nesting_level": 0 }, { "name": "get_version", "long_name": "get_version( release_level = 'alpha' , path = '.' , major = None )", "filename": "misc_util.py", "nloc": 51, "complexity": 11, "token_count": 299, "parameters": [ "release_level", "path", "major" ], "start_line": 3, "end_line": 80, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 78, "top_nesting_level": 0 }, { "name": "get_version", "long_name": "get_version( major , minor , path = '.' )", "filename": "misc_util.py", "nloc": 8, "complexity": 3, "token_count": 61, "parameters": [ "major", "minor", "path" ], "start_line": 3, "end_line": 18, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 0 }, { "name": "get_micro_version", "long_name": "get_micro_version( path )", "filename": "misc_util.py", "nloc": 11, "complexity": 7, "token_count": 128, "parameters": [ "path" ], "start_line": 20, "end_line": 33, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 0 } ], "nloc": 122, "complexity": 40, "token_count": 893, "diff_parsed": { "added": [ "def get_version(release_level='alpha', path='.', major=None):", " Return version string calculated from CVS tree or found in", " /__version__.py. Automatically update /__version__.py", " if the version is changed.", " An attempt is made to guarantee that version is increasing in", " time. This function always succeeds. None is returned if no", " version information is available.", "", " Version string is in the form", "", " ..--", "", " and its items have the following meanings:", " serial - shows cumulative changes in all files in the CVS", " repository", " micro - a number that is equivalent to the number of files", " minor - indicates the changes in micro value (files are added", " or removed)", " release_level - is alpha, beta, canditate, or final", " major - indicates changes in release_level.", " \"\"\"", "", " release_level_map = {'alpha':0,", " 'beta':1,", " 'canditate':2,", " 'final':3}", " release_level_value = release_level_map.get(release_level)", " if release_level_value is None:", " print 'Warning: release_level=%s is not %s'\\", " % (release_level,", " string.join(release_level_map.keys(),','))", "", " cwd = os.getcwd()", " os.chdir(path)", " try:", " version_module = __import__('__version__')", " reload(version_module)", " old_version_info = version_module.version_info", " old_version = version_module.version", " except:", " print sys.exc_value", " old_version_info = None", " old_version = None", " os.chdir(cwd)", "", " cvs_revs = get_cvs_version(path)", " if cvs_revs is None:", " return old_version", "", " minor = 1", " micro,serial = cvs_revs", " if old_version_info is not None:", " minor = old_version_info[1]", " old_release_level_value = release_level_map.get(old_version_info[3])", " if micro != old_version_info[2]: # files have beed added or removed", " minor = minor + 1", " if major is None:", " major = old_version_info[0]", " if old_release_level_value is not None:", " if old_release_level_value > release_level_value:", " major = major + 1", " if major is None:", " major = 0", "", " version_info = (major,minor,micro,release_level,serial)", " version = '%s.%s.%s-%s-%s' % version_info", "", " if version != old_version:", " print 'updating version: %s -> %s'%(old_version,version)", " version_file = os.path.abspath(os.path.join(path,'__version__.py'))", " f = open(version_file,'w')", " f.write('# This file is automatically updated with get_version\\n'\\", " '# function from scipy_distutils.misc_utils.py\\n'\\", " 'version = %s\\n'\\", " 'version_info = %s\\n'%(repr(version),version_info))", " f.close()", " return version", "", "def get_cvs_version(path):", " \"\"\"", " Return two last cumulative revision numbers of a CVS tree starting", " at . The first number shows the number of files in the CVS", " tree (this is often true, but not always) and the second number", " characterizes the changes in these files.", " If /CVS/Entries is not existing then return None.", " rev1,rev2 = 0,0", " if items[0]=='D' and len(items)>1:", " try:", " d1,d2 = get_cvs_version(os.path.join(path,items[1]))", " except:", " d1,d2 = 0,0", " elif items[0]=='' and len(items)>3 and items[1]!='__version__.py':", " d1,d2 = map(eval,string.split(items[2],'.')[-2:])", " else:", " continue", " rev1,rev2 = rev1+d1,rev2+d2", " return rev1,rev2" ], "deleted": [ "def get_version(major,minor,path = '.'):", " Return a version string calculated from a CVS tree starting at", " path. The micro version number is found as a sum of the last bits", " of the revision numbers listed in CVS/Entries. If /CVS does", " not exists, get_version tries to get the version from the", " /__version__.py file where __version__ variable should be", " defined. If that also fails, then return None.", " micro = get_micro_version(os.path.abspath(path))", " if micro is None:", " try:", " return __import__(os.path.join(path,'__version__.py')).__version__", " except:", " return", " return '%s.%s.%s'%(major,minor,micro)", "", "def get_micro_version(path):", " # micro version number should be increasing in time, unless a file", " # is removed from the CVS source tree. In that case one should", " # increase the minor version number.", " micro = 0", " if items[0] == 'D' and len(items)>1:", " micro = micro + get_micro_version(os.path.join(path,items[1]))", " elif items[0] == '' and len(items)>2:", " micro = micro + eval(string.split(items[2],'.')[-1])", " return micro" ] } }, { "old_path": "scipy_distutils/setup.py", "new_path": "scipy_distutils/setup.py", "filename": "setup.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -14,11 +14,8 @@ def install_package():\n os.chdir(path)\n try:\n \n- version = get_version(0,2)\n+ version = get_version('alpha')\n print 'scipy_distutils',version\n- version_file = open('__version__.py','w')\n- version_file.write('__version__ = %s\\n'%(repr(version)))\n- version_file.close()\n \n setup (name = \"scipy_distutils\",\n version = version,\n", "added_lines": 1, "deleted_lines": 4, "source_code": "#!/usr/bin/env python\nimport os\n\nfrom distutils.core import setup\nfrom misc_util import get_path, get_version\n\ndef install_package():\n \"\"\" Install the scipy_distutils. The dance with the current directory is done\n to fool distutils into thinking it is run from the scipy_distutils directory\n even if it was invoked from another script located in a different location.\n \"\"\"\n path = get_path(__name__)\n old_path = os.getcwd()\n os.chdir(path)\n try:\n\n version = get_version('alpha')\n print 'scipy_distutils',version\n\n setup (name = \"scipy_distutils\",\n version = version,\n description = \"Changes to distutils needed for SciPy -- mostly Fortran support\",\n author = \"Travis Oliphant, Eric Jones, and Pearu Peterson\",\n author_email = \"scipy-devel@scipy.org\",\n licence = \"BSD Style\",\n url = 'http://www.scipy.org',\n packages = ['scipy_distutils','scipy_distutils.command'],\n package_dir = {'scipy_distutils':path}\n )\n finally:\n os.chdir(old_path)\n \nif __name__ == '__main__':\n install_package()\n", "source_code_before": "#!/usr/bin/env python\nimport os\n\nfrom distutils.core import setup\nfrom misc_util import get_path, get_version\n\ndef install_package():\n \"\"\" Install the scipy_distutils. The dance with the current directory is done\n to fool distutils into thinking it is run from the scipy_distutils directory\n even if it was invoked from another script located in a different location.\n \"\"\"\n path = get_path(__name__)\n old_path = os.getcwd()\n os.chdir(path)\n try:\n\n version = get_version(0,2)\n print 'scipy_distutils',version\n version_file = open('__version__.py','w')\n version_file.write('__version__ = %s\\n'%(repr(version)))\n version_file.close()\n\n setup (name = \"scipy_distutils\",\n version = version,\n description = \"Changes to distutils needed for SciPy -- mostly Fortran support\",\n author = \"Travis Oliphant, Eric Jones, and Pearu Peterson\",\n author_email = \"scipy-devel@scipy.org\",\n licence = \"BSD Style\",\n url = 'http://www.scipy.org',\n packages = ['scipy_distutils','scipy_distutils.command'],\n package_dir = {'scipy_distutils':path}\n )\n finally:\n os.chdir(old_path)\n \nif __name__ == '__main__':\n install_package()\n", "methods": [ { "name": "install_package", "long_name": "install_package( )", "filename": "setup.py", "nloc": 19, "complexity": 2, "token_count": 90, "parameters": [], "start_line": 7, "end_line": 31, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 0 } ], "methods_before": [ { "name": "install_package", "long_name": "install_package( )", "filename": "setup.py", "nloc": 22, "complexity": 2, "token_count": 118, "parameters": [], "start_line": 7, "end_line": 34, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 28, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "install_package", "long_name": "install_package( )", "filename": "setup.py", "nloc": 19, "complexity": 2, "token_count": 90, "parameters": [], "start_line": 7, "end_line": 31, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 0 } ], "nloc": 24, "complexity": 2, "token_count": 113, "diff_parsed": { "added": [ " version = get_version('alpha')" ], "deleted": [ " version = get_version(0,2)", " version_file = open('__version__.py','w')", " version_file.write('__version__ = %s\\n'%(repr(version)))", " version_file.close()" ] } } ] }, { "hash": "fd3855d4fecb6a962a752c8e0f5d51eb34400a5e", "msg": "refined get_version", "author": { "name": "Pearu Peterson", "email": "pearu.peterson@gmail.com" }, "committer": { "name": "Pearu Peterson", "email": "pearu.peterson@gmail.com" }, "author_date": "2002-01-05T12:03:04+00:00", "author_timezone": 0, "committer_date": "2002-01-05T12:03:04+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "c1a5d613bb52d1ae45cc8bb90e056c9181cad18b" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 2, "insertions": 2, "lines": 4, "files": 1, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": "scipy_distutils/__version__.py", "new_path": "scipy_distutils/__version__.py", "filename": "__version__.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -1,4 +1,4 @@\n # This file is automatically updated with get_version\n # function from scipy_distutils.misc_utils.py\n-version = '0.1.19-alpha-45'\n-version_info = (0, 1, 19, 'alpha', 45)\n+version = '0.1.19-alpha-47'\n+version_info = (0, 1, 19, 'alpha', 47)\n", "added_lines": 2, "deleted_lines": 2, "source_code": "# This file is automatically updated with get_version\n# function from scipy_distutils.misc_utils.py\nversion = '0.1.19-alpha-47'\nversion_info = (0, 1, 19, 'alpha', 47)\n", "source_code_before": "# This file is automatically updated with get_version\n# function from scipy_distutils.misc_utils.py\nversion = '0.1.19-alpha-45'\nversion_info = (0, 1, 19, 'alpha', 45)\n", "methods": [], "methods_before": [], "changed_methods": [], "nloc": 2, "complexity": 0, "token_count": 16, "diff_parsed": { "added": [ "version = '0.1.19-alpha-47'", "version_info = (0, 1, 19, 'alpha', 47)" ], "deleted": [ "version = '0.1.19-alpha-45'", "version_info = (0, 1, 19, 'alpha', 45)" ] } } ] }, { "hash": "f2e5fb8573178cb7a8924d57e70bf9c199034622", "msg": "changed import of fastumath as \"optional\" with a try/except clause. This allows people without SciPy, but with Numeric to use blitz.", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-05T17:07:10+00:00", "author_timezone": 0, "committer_date": "2002-01-05T17:07:10+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "fd3855d4fecb6a962a752c8e0f5d51eb34400a5e" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 3, "insertions": 19, "lines": 22, "files": 3, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": "weave/blitz_tools.py", "new_path": "weave/blitz_tools.py", "filename": "blitz_tools.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -8,8 +8,14 @@\n import size_check\n \n from ast_tools import *\n+\n from Numeric import *\n-from fastumath import *\n+# The following try/except so that non-SciPy users can still use blitz\n+try:\n+ from fastumath import *\n+except:\n+ pass # fastumath not available \n+ \n from types import *\n \n import inline_tools\n", "added_lines": 7, "deleted_lines": 1, "source_code": "import parser\nimport string\nimport copy\nimport os,sys\nimport ast_tools\nimport token,symbol\nimport slice_handler\nimport size_check\n\nfrom ast_tools import *\n\nfrom Numeric import *\n# The following try/except so that non-SciPy users can still use blitz\ntry:\n from fastumath import *\nexcept:\n pass # fastumath not available \n \nfrom types import *\n\nimport inline_tools\nfrom inline_tools import attempt_function_call\nfunction_catalog = inline_tools.function_catalog\nfunction_cache = inline_tools.function_cache\n\n# this is pretty much the same as the default factories.\n# We've just replaced the array specification with the blitz\n# specification\nimport base_spec\nimport scalar_spec\nimport sequence_spec\nimport common_spec\nfrom blitz_spec import array_specification\nblitz_type_factories = [sequence_spec.string_specification(),\n sequence_spec.list_specification(),\n sequence_spec.dict_specification(),\n sequence_spec.tuple_specification(),\n scalar_spec.int_specification(),\n scalar_spec.float_specification(),\n scalar_spec.complex_specification(),\n common_spec.file_specification(),\n common_spec.callable_specification(),\n array_specification()]\n #common_spec.instance_specification(), \n #common_spec.module_specification()]\n\ntry: \n # this is currently safe because it doesn't import wxPython.\n import wx_spec\n default_type_factories.append(wx_spec.wx_specification())\nexcept: \n pass \n \ndef blitz(expr,local_dict=None, global_dict=None,check_size=1,verbose=0):\n # this could call inline, but making a copy of the\n # code here is more efficient for several reasons.\n global function_catalog\n \n # this grabs the local variables from the *previous* call\n # frame -- that is the locals from the function that called\n # inline.\n call_frame = sys._getframe().f_back\n if local_dict is None:\n local_dict = call_frame.f_locals\n if global_dict is None:\n global_dict = call_frame.f_globals\n\n # 1. Check the sizes of the arrays and make sure they are compatible.\n # This is expensive, so unsetting the check_size flag can save a lot\n # of time. It also can cause core-dumps if the sizes of the inputs \n # aren't compatible. \n if check_size and not size_check.check_expr(expr,local_dict,global_dict):\n raise 'inputs failed to pass size check.'\n \n # 2. try local cache \n try:\n results = apply(function_cache[expr],(local_dict,global_dict))\n return results\n except: \n pass\n try:\n results = attempt_function_call(expr,local_dict,global_dict)\n # 3. build the function \n except ValueError:\n # This section is pretty much the only difference \n # between blitz and inline\n ast = parser.suite(expr)\n ast_list = ast.tolist()\n expr_code = ast_to_blitz_expr(ast_list)\n arg_names = harvest_variables(ast_list)\n module_dir = global_dict.get('__file__',None)\n #func = inline_tools.compile_function(expr_code,arg_names,\n # local_dict,global_dict,\n # module_dir,auto_downcast = 1)\n func = inline_tools.compile_function(expr_code,arg_names,local_dict, \n global_dict,module_dir,\n compiler='gcc',auto_downcast=1,\n verbose = verbose,\n type_factories = blitz_type_factories)\n function_catalog.add_function(expr,func,module_dir)\n try: \n results = attempt_function_call(expr,local_dict,global_dict)\n except ValueError: \n print 'warning: compilation failed. Executing as python code'\n exec expr in global_dict, local_dict\n \ndef ast_to_blitz_expr(ast_seq):\n \"\"\" Convert an ast_sequence to a blitz expression.\n \"\"\"\n \n # Don't overwrite orignal sequence in call to transform slices.\n ast_seq = copy.deepcopy(ast_seq) \n slice_handler.transform_slices(ast_seq)\n \n # Build the actual program statement from ast_seq\n expr = ast_tools.ast_to_string(ast_seq)\n \n # Now find and replace specific symbols to convert this to\n # a blitz++ compatible statement.\n # I'm doing this with string replacement here. It could\n # also be done on the actual ast tree (and probably should from\n # a purest standpoint...).\n \n # this one isn't necessary but it helps code readability\n # and compactness. It requires that \n # Range _all = blitz::Range::all();\n # be included in the generated code. \n # These could all alternatively be done to the ast in\n # build_slice_atom()\n expr = string.replace(expr,'slice(_beg,_end)', '_all' ) \n expr = string.replace(expr,'slice', 'blitz::Range' )\n expr = string.replace(expr,'[','(')\n expr = string.replace(expr,']', ')' )\n expr = string.replace(expr,'_stp', '1' )\n \n # Instead of blitz::fromStart and blitz::toEnd. This requires\n # the following in the generated code.\n # Range _beg = blitz::fromStart;\n # Range _end = blitz::toEnd;\n #expr = string.replace(expr,'_beg', 'blitz::fromStart' )\n #expr = string.replace(expr,'_end', 'blitz::toEnd' )\n \n return expr + ';\\n'\n\ndef test_function():\n from code_blocks import module_header\n\n expr = \"ex[:,1:,1:] = k + ca_x[:,1:,1:] * ex[:,1:,1:]\" \\\n \"+ cb_y_x[:,1:,1:] * (hz[:,1:,1:] - hz[:,:-1,1:])\"\\\n \"- cb_z_x[:,1:,1:] * (hy[:,1:,1:] - hy[:,1:,:-1])\" \n #ast = parser.suite('a = (b + c) * sin(d)')\n ast = parser.suite(expr)\n k = 1.\n ex = ones((1,1,1),typecode=Float32)\n ca_x = ones((1,1,1),typecode=Float32)\n cb_y_x = ones((1,1,1),typecode=Float32)\n cb_z_x = ones((1,1,1),typecode=Float32)\n hz = ones((1,1,1),typecode=Float32)\n hy = ones((1,1,1),typecode=Float32)\n blitz(expr)\n \"\"\"\n ast_list = ast.tolist()\n \n expr_code = ast_to_blitz_expr(ast_list)\n arg_list = harvest_variables(ast_list)\n arg_specs = assign_variable_types(arg_list,locals())\n \n func,template_types = create_function('test_function',expr_code,arg_list,arg_specs)\n init,used_names = create_module_init('compile_sample','test_function',template_types)\n #wrapper = create_wrapper(mod_name,func_name,used_names)\n return string.join( [module_header,func,init],'\\n')\n \"\"\"\ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n\nif __name__ == \"__main__\":\n test_function()", "source_code_before": "import parser\nimport string\nimport copy\nimport os,sys\nimport ast_tools\nimport token,symbol\nimport slice_handler\nimport size_check\n\nfrom ast_tools import *\nfrom Numeric import *\nfrom fastumath import *\nfrom types import *\n\nimport inline_tools\nfrom inline_tools import attempt_function_call\nfunction_catalog = inline_tools.function_catalog\nfunction_cache = inline_tools.function_cache\n\n# this is pretty much the same as the default factories.\n# We've just replaced the array specification with the blitz\n# specification\nimport base_spec\nimport scalar_spec\nimport sequence_spec\nimport common_spec\nfrom blitz_spec import array_specification\nblitz_type_factories = [sequence_spec.string_specification(),\n sequence_spec.list_specification(),\n sequence_spec.dict_specification(),\n sequence_spec.tuple_specification(),\n scalar_spec.int_specification(),\n scalar_spec.float_specification(),\n scalar_spec.complex_specification(),\n common_spec.file_specification(),\n common_spec.callable_specification(),\n array_specification()]\n #common_spec.instance_specification(), \n #common_spec.module_specification()]\n\ntry: \n # this is currently safe because it doesn't import wxPython.\n import wx_spec\n default_type_factories.append(wx_spec.wx_specification())\nexcept: \n pass \n \ndef blitz(expr,local_dict=None, global_dict=None,check_size=1,verbose=0):\n # this could call inline, but making a copy of the\n # code here is more efficient for several reasons.\n global function_catalog\n \n # this grabs the local variables from the *previous* call\n # frame -- that is the locals from the function that called\n # inline.\n call_frame = sys._getframe().f_back\n if local_dict is None:\n local_dict = call_frame.f_locals\n if global_dict is None:\n global_dict = call_frame.f_globals\n\n # 1. Check the sizes of the arrays and make sure they are compatible.\n # This is expensive, so unsetting the check_size flag can save a lot\n # of time. It also can cause core-dumps if the sizes of the inputs \n # aren't compatible. \n if check_size and not size_check.check_expr(expr,local_dict,global_dict):\n raise 'inputs failed to pass size check.'\n \n # 2. try local cache \n try:\n results = apply(function_cache[expr],(local_dict,global_dict))\n return results\n except: \n pass\n try:\n results = attempt_function_call(expr,local_dict,global_dict)\n # 3. build the function \n except ValueError:\n # This section is pretty much the only difference \n # between blitz and inline\n ast = parser.suite(expr)\n ast_list = ast.tolist()\n expr_code = ast_to_blitz_expr(ast_list)\n arg_names = harvest_variables(ast_list)\n module_dir = global_dict.get('__file__',None)\n #func = inline_tools.compile_function(expr_code,arg_names,\n # local_dict,global_dict,\n # module_dir,auto_downcast = 1)\n func = inline_tools.compile_function(expr_code,arg_names,local_dict, \n global_dict,module_dir,\n compiler='gcc',auto_downcast=1,\n verbose = verbose,\n type_factories = blitz_type_factories)\n function_catalog.add_function(expr,func,module_dir)\n try: \n results = attempt_function_call(expr,local_dict,global_dict)\n except ValueError: \n print 'warning: compilation failed. Executing as python code'\n exec expr in global_dict, local_dict\n \ndef ast_to_blitz_expr(ast_seq):\n \"\"\" Convert an ast_sequence to a blitz expression.\n \"\"\"\n \n # Don't overwrite orignal sequence in call to transform slices.\n ast_seq = copy.deepcopy(ast_seq) \n slice_handler.transform_slices(ast_seq)\n \n # Build the actual program statement from ast_seq\n expr = ast_tools.ast_to_string(ast_seq)\n \n # Now find and replace specific symbols to convert this to\n # a blitz++ compatible statement.\n # I'm doing this with string replacement here. It could\n # also be done on the actual ast tree (and probably should from\n # a purest standpoint...).\n \n # this one isn't necessary but it helps code readability\n # and compactness. It requires that \n # Range _all = blitz::Range::all();\n # be included in the generated code. \n # These could all alternatively be done to the ast in\n # build_slice_atom()\n expr = string.replace(expr,'slice(_beg,_end)', '_all' ) \n expr = string.replace(expr,'slice', 'blitz::Range' )\n expr = string.replace(expr,'[','(')\n expr = string.replace(expr,']', ')' )\n expr = string.replace(expr,'_stp', '1' )\n \n # Instead of blitz::fromStart and blitz::toEnd. This requires\n # the following in the generated code.\n # Range _beg = blitz::fromStart;\n # Range _end = blitz::toEnd;\n #expr = string.replace(expr,'_beg', 'blitz::fromStart' )\n #expr = string.replace(expr,'_end', 'blitz::toEnd' )\n \n return expr + ';\\n'\n\ndef test_function():\n from code_blocks import module_header\n\n expr = \"ex[:,1:,1:] = k + ca_x[:,1:,1:] * ex[:,1:,1:]\" \\\n \"+ cb_y_x[:,1:,1:] * (hz[:,1:,1:] - hz[:,:-1,1:])\"\\\n \"- cb_z_x[:,1:,1:] * (hy[:,1:,1:] - hy[:,1:,:-1])\" \n #ast = parser.suite('a = (b + c) * sin(d)')\n ast = parser.suite(expr)\n k = 1.\n ex = ones((1,1,1),typecode=Float32)\n ca_x = ones((1,1,1),typecode=Float32)\n cb_y_x = ones((1,1,1),typecode=Float32)\n cb_z_x = ones((1,1,1),typecode=Float32)\n hz = ones((1,1,1),typecode=Float32)\n hy = ones((1,1,1),typecode=Float32)\n blitz(expr)\n \"\"\"\n ast_list = ast.tolist()\n \n expr_code = ast_to_blitz_expr(ast_list)\n arg_list = harvest_variables(ast_list)\n arg_specs = assign_variable_types(arg_list,locals())\n \n func,template_types = create_function('test_function',expr_code,arg_list,arg_specs)\n init,used_names = create_module_init('compile_sample','test_function',template_types)\n #wrapper = create_wrapper(mod_name,func_name,used_names)\n return string.join( [module_header,func,init],'\\n')\n \"\"\"\ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n\nif __name__ == \"__main__\":\n test_function()", "methods": [ { "name": "blitz", "long_name": "blitz( expr , local_dict = None , global_dict = None , check_size = 1 , verbose = 0 )", "filename": "blitz_tools.py", "nloc": 33, "complexity": 8, "token_count": 208, "parameters": [ "expr", "local_dict", "global_dict", "check_size", "verbose" ], "start_line": 54, "end_line": 105, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 52, "top_nesting_level": 0 }, { "name": "ast_to_blitz_expr", "long_name": "ast_to_blitz_expr( ast_seq )", "filename": "blitz_tools.py", "nloc": 10, "complexity": 1, "token_count": 92, "parameters": [ "ast_seq" ], "start_line": 107, "end_line": 143, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 37, "top_nesting_level": 0 }, { "name": "test_function", "long_name": "test_function( )", "filename": "blitz_tools.py", "nloc": 26, "complexity": 1, "token_count": 128, "parameters": [], "start_line": 145, "end_line": 172, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 28, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "blitz_tools.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 173, "end_line": 175, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "blitz_tools.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 177, "end_line": 179, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "methods_before": [ { "name": "blitz", "long_name": "blitz( expr , local_dict = None , global_dict = None , check_size = 1 , verbose = 0 )", "filename": "blitz_tools.py", "nloc": 33, "complexity": 8, "token_count": 208, "parameters": [ "expr", "local_dict", "global_dict", "check_size", "verbose" ], "start_line": 48, "end_line": 99, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 52, "top_nesting_level": 0 }, { "name": "ast_to_blitz_expr", "long_name": "ast_to_blitz_expr( ast_seq )", "filename": "blitz_tools.py", "nloc": 10, "complexity": 1, "token_count": 92, "parameters": [ "ast_seq" ], "start_line": 101, "end_line": 137, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 37, "top_nesting_level": 0 }, { "name": "test_function", "long_name": "test_function( )", "filename": "blitz_tools.py", "nloc": 26, "complexity": 1, "token_count": 128, "parameters": [], "start_line": 139, "end_line": 166, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 28, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "blitz_tools.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 167, "end_line": 169, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "blitz_tools.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 171, "end_line": 173, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "changed_methods": [], "nloc": 116, "complexity": 12, "token_count": 617, "diff_parsed": { "added": [ "", "# The following try/except so that non-SciPy users can still use blitz", "try:", " from fastumath import *", "except:", " pass # fastumath not available", "" ], "deleted": [ "from fastumath import *" ] } }, { "old_path": "weave/size_check.py", "new_path": "weave/size_check.py", "filename": "size_check.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -1,5 +1,11 @@\n from Numeric import *\n-from fastumath import *\n+\n+# The following try/except so that non-SciPy users can still use blitz\n+try:\n+ from fastumath import *\n+except:\n+ pass # fastumath not available \n+\n from ast_tools import *\n from types import *\n import sys\n", "added_lines": 7, "deleted_lines": 1, "source_code": "from Numeric import *\n\n# The following try/except so that non-SciPy users can still use blitz\ntry:\n from fastumath import *\nexcept:\n pass # fastumath not available \n\nfrom ast_tools import *\nfrom types import *\nimport sys\n\ndef time_it():\n import time\n \n expr = \"ex[:,1:,1:] = ca_x[:,1:,1:] * ex[:,1:,1:]\" \\\n \"+ cb_y_x[:,1:,1:] * (hz[:,1:,1:] - hz[:,:-1,1:])\" \\\n \"- cb_z_x[:,1:,1:] * (hy[:,1:,1:] - hy[:,1:,:-1])\" \n ex = ones((10,10,10),typecode=Float32)\n ca_x = ones((10,10,10),typecode=Float32)\n cb_y_x = ones((10,10,10),typecode=Float32)\n cb_z_x = ones((10,10,10),typecode=Float32)\n hz = ones((10,10,10),typecode=Float32)\n hy = ones((10,10,10),typecode=Float32)\n \n N = 1\n t1 = time.time()\n for i in range(N):\n passed = check_expr(expr,locals())\n t2 = time.time()\n print 'time per call:', (t2 - t1)/N\n print 'passed:', passed\n \ndef check_expr(expr,local_vars,global_vars={}):\n \"\"\" Currently only checks expressions (not suites).\n Doesn't check that lhs = rhs. checked by compiled func though\n \"\"\"\n values ={}\n \n #first handle the globals\n for var,val in global_vars.items():\n if type(val) in [ArrayType]: \n values[var] = dummy_array(val,name=var)\n elif type(val) in [IntType,LongType,FloatType,ComplexType]: \n values[var] = val\n #now handle the locals \n for var,val in local_vars.items():\n if type(val) in [ArrayType]: \n values[var] = dummy_array(val,name=var)\n elif type(val) in [IntType,LongType,FloatType,ComplexType]: \n values[var] = val\n exec(expr,values)\n try:\n exec(expr,values)\n except:\n try:\n eval(expr,values)\n except:\n return 0 \n return 1 \n \nempty = array(())\nempty_slice = slice(None)\n\ndef make_same_length(x,y):\n try:\n Nx = len(x)\n except:\n Nx = 0\n try:\n Ny = len(y)\n except:\n Ny = 0\n if Nx == Ny == 0:\n return empty,empty\n elif Nx == Ny:\n return asarray(x),asarray(y)\n else: \n diff = abs(Nx - Ny)\n front = ones(diff,Int)\n if Nx > Ny:\n return asarray(x), concatenate((front,y))\n elif Ny > Nx:\n return concatenate((front,x)),asarray(y) \n\ndef binary_op_size(xx,yy):\n \"\"\" This returns the resulting size from operating on xx, and yy\n with a binary operator. It accounts for broadcasting, and\n throws errors if the array sizes are incompatible.\n \"\"\"\n x,y = make_same_length(xx,yy)\n res = zeros(len(x))\n for i in range(len(x)):\n if x[i] == y[i]:\n res[i] = x[i]\n elif x[i] == 1:\n res[i] = y[i]\n elif y[i] == 1:\n res[i] = x[i]\n else:\n # offer more information here about which variables.\n raise ValueError, \"frames are not aligned\"\n return res \nclass dummy_array:\n def __init__(self,ary,ary_is_shape = 0,name=None):\n self.name = name\n if ary_is_shape:\n self.shape = ary\n #self.shape = asarray(ary)\n else:\n try:\n self.shape = shape(ary)\n except:\n self.shape = empty\n #self.value = ary \n def binary_op(self,other):\n try: \n x = other.shape\n except AttributeError:\n x = empty \n new_shape = binary_op_size(self.shape,x)\n return dummy_array(new_shape,1)\n def __cmp__(self,other):\n # This isn't an exact compare, but does work for == \n # cluge for Numeric\n if type(other) in [IntType,LongType,FloatType,ComplexType]:\n return 0\n if len(self.shape) == len(other.shape) == 0:\n return 0\n return not alltrue(equal(self.shape,other.shape))\n\n def __add__(self,other): return self.binary_op(other)\n def __radd__(self,other): return self.binary_op(other)\n def __sub__(self,other): return self.binary_op(other)\n def __rsub__(self,other): return self.binary_op(other)\n def __mul__(self,other): return self.binary_op(other)\n def __rmul__(self,other): return self.binary_op(other)\n def __div__(self,other): return self.binary_op(other)\n def __rdiv__(self,other): return self.binary_op(other)\n def __mod__(self,other): return self.binary_op(other)\n def __rmod__(self,other): return self.binary_op(other)\n def __lshift__(self,other): return self.binary_op(other)\n def __rshift__(self,other): return self.binary_op(other)\n # unary ops\n def __neg__(self,other): return self\n def __pos__(self,other): return self\n def __abs__(self,other): return self\n def __invert__(self,other): return self \n # Not sure what to do with coersion ops. Ignore for now.\n #\n # not currently supported by compiler.\n # __divmod__\n # __pow__\n # __rpow__\n # __and__\n # __or__\n # __xor__\n # item access and slicing \n def __setitem__(self,indices,val):\n #ignore for now\n pass\n def __len__(self):\n return self.shape[0]\n def __getslice__(self,i,j):\n # enabling the following would make class compatible with\n # lists. Its current incarnation is compatible with arrays.\n # Both this and Numeric should have this FIXED to correspond\n # to lists.\n #i = max(i, 0); j = max(j, 0)\n return self.__getitem__((slice(i,j),))\n def __getitem__(self,indices):\n # ayeyaya this is a mess\n #print indices, type(indices), indices.shape \n if type(indices) is not TupleType:\n indices = (indices,)\n if Ellipsis in indices:\n raise IndexError, \"Ellipsis not currently supported\"\n new_dims = [] \n dim = 0 \n for index in indices:\n try:\n dim_len = self.shape[dim]\n except IndexError:\n raise IndexError, \"To many indices specified\"\n \n #if (type(index) is SliceType and index.start == index.stop == index.step):\n if (index is empty_slice):\n slc_len = dim_len\n elif type(index) is SliceType:\n beg,end,step = index.start,index.stop,index.step \n # handle if they are dummy arrays\n #if hasattr(beg,'value') and type(beg.value) != ArrayType:\n # beg = beg.value\n #if hasattr(end,'value') and type(end.value) != ArrayType:\n # end = end.value\n #if hasattr(step,'value') and type(step.value) != ArrayType:\n # step = step.value \n if beg is None: beg = 0\n if end == sys.maxint or end is None:\n end = dim_len\n if step is None: \n step = 1\n \n if beg < 0: beg += dim_len\n if end < 0: end += dim_len\n # the following is list like behavior,\n # which isn't adhered to by arrays. \n # FIX THIS ANOMOLY IN NUMERIC!\n if beg < 0: beg = 0\n if beg > dim_len: beg = dim_len\n if end < 0: end = 0\n if end > dim_len: end = dim_len\n # This is rubbish. \n if beg == end:\n beg,end,step = 0,0,1\n elif beg >= dim_len and step > 0:\n beg,end,step = 0,0,1\n #elif index.step > 0 and beg <= end:\n elif step > 0 and beg <= end:\n pass #slc_len = abs(divide(end-beg-1,step)+1) \n # handle [::-1] and [-1::-1] correctly \n #elif index.step > 0 and beg > end:\n elif step > 0 and beg > end:\n beg,end,step = 0,0,1\n elif(step < 0 and index.start is None and index.stop is None):\n beg,end,step = 0,dim_len,-step\n elif(step < 0 and index.start is None):\n # +1 because negative stepping is inclusive\n beg,end,step = end+1,dim_len,-step \n elif(step < 0 and index.stop is None):\n beg,end,step = 0,beg+1,-step\n elif(step < 0 and beg > end): \n beg,end,step = end,beg,-step\n elif(step < 0 and beg < end): \n beg,end,step = 0,0,-step\n slc_len = abs(divide(end-beg-1,step)+1)\n new_dims.append(slc_len)\n else:\n if index < 0: index += dim_len\n if index >=0 and index < dim_len:\n #this reduces the array dimensions by one\n pass\n else:\n raise IndexError, \"Index out of range\" \n dim += 1 \n new_dims.extend(self.shape[dim:])\n if 0 in new_dims:\n raise IndexError, \"Zero length slices not currently supported\"\n return dummy_array(new_dims,1)\n def __repr__(self):\n val = str((self.name, str(self.shape)))\n return val \n\ndef unary(ary):\n return ary\n\ndef not_implemented(ary):\n return ary\n \n#all imported from Numeric and need to be reassigned.\nunary_op = [arccos, arcsin, arctan, cos, cosh, sin, sinh, \n exp,ceil,floor,fabs,log,log10,sqrt]\n\nunsupported = [argmin,argmax, argsort,around, absolute,sign,negative,floor]\n\nfor func in unary_op:\n func = unary\n \nfor func in unsupported:\n func = not_implemented\n \ndef reduction(ary,axis=0):\n if axis < 0:\n axis += len(ary.shape) \n if axis < 0 or axis >= len(ary.shape):\n raise ValueError, \"Dimension not in array\" \n new_dims = list(ary.shape[:axis]) + list(ary.shape[axis+1:])\n return dummy_array(new_dims,1) \n\n# functions currently not supported by compiler\n# reductions are gonna take some array reordering for the general case,\n# so this is gonna take some thought (probably some tree manipulation).\ndef take(ary,axis=0): raise NotImplemented\n# and all the rest\n \ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n ", "source_code_before": "from Numeric import *\nfrom fastumath import *\nfrom ast_tools import *\nfrom types import *\nimport sys\n\ndef time_it():\n import time\n \n expr = \"ex[:,1:,1:] = ca_x[:,1:,1:] * ex[:,1:,1:]\" \\\n \"+ cb_y_x[:,1:,1:] * (hz[:,1:,1:] - hz[:,:-1,1:])\" \\\n \"- cb_z_x[:,1:,1:] * (hy[:,1:,1:] - hy[:,1:,:-1])\" \n ex = ones((10,10,10),typecode=Float32)\n ca_x = ones((10,10,10),typecode=Float32)\n cb_y_x = ones((10,10,10),typecode=Float32)\n cb_z_x = ones((10,10,10),typecode=Float32)\n hz = ones((10,10,10),typecode=Float32)\n hy = ones((10,10,10),typecode=Float32)\n \n N = 1\n t1 = time.time()\n for i in range(N):\n passed = check_expr(expr,locals())\n t2 = time.time()\n print 'time per call:', (t2 - t1)/N\n print 'passed:', passed\n \ndef check_expr(expr,local_vars,global_vars={}):\n \"\"\" Currently only checks expressions (not suites).\n Doesn't check that lhs = rhs. checked by compiled func though\n \"\"\"\n values ={}\n \n #first handle the globals\n for var,val in global_vars.items():\n if type(val) in [ArrayType]: \n values[var] = dummy_array(val,name=var)\n elif type(val) in [IntType,LongType,FloatType,ComplexType]: \n values[var] = val\n #now handle the locals \n for var,val in local_vars.items():\n if type(val) in [ArrayType]: \n values[var] = dummy_array(val,name=var)\n elif type(val) in [IntType,LongType,FloatType,ComplexType]: \n values[var] = val\n exec(expr,values)\n try:\n exec(expr,values)\n except:\n try:\n eval(expr,values)\n except:\n return 0 \n return 1 \n \nempty = array(())\nempty_slice = slice(None)\n\ndef make_same_length(x,y):\n try:\n Nx = len(x)\n except:\n Nx = 0\n try:\n Ny = len(y)\n except:\n Ny = 0\n if Nx == Ny == 0:\n return empty,empty\n elif Nx == Ny:\n return asarray(x),asarray(y)\n else: \n diff = abs(Nx - Ny)\n front = ones(diff,Int)\n if Nx > Ny:\n return asarray(x), concatenate((front,y))\n elif Ny > Nx:\n return concatenate((front,x)),asarray(y) \n\ndef binary_op_size(xx,yy):\n \"\"\" This returns the resulting size from operating on xx, and yy\n with a binary operator. It accounts for broadcasting, and\n throws errors if the array sizes are incompatible.\n \"\"\"\n x,y = make_same_length(xx,yy)\n res = zeros(len(x))\n for i in range(len(x)):\n if x[i] == y[i]:\n res[i] = x[i]\n elif x[i] == 1:\n res[i] = y[i]\n elif y[i] == 1:\n res[i] = x[i]\n else:\n # offer more information here about which variables.\n raise ValueError, \"frames are not aligned\"\n return res \nclass dummy_array:\n def __init__(self,ary,ary_is_shape = 0,name=None):\n self.name = name\n if ary_is_shape:\n self.shape = ary\n #self.shape = asarray(ary)\n else:\n try:\n self.shape = shape(ary)\n except:\n self.shape = empty\n #self.value = ary \n def binary_op(self,other):\n try: \n x = other.shape\n except AttributeError:\n x = empty \n new_shape = binary_op_size(self.shape,x)\n return dummy_array(new_shape,1)\n def __cmp__(self,other):\n # This isn't an exact compare, but does work for == \n # cluge for Numeric\n if type(other) in [IntType,LongType,FloatType,ComplexType]:\n return 0\n if len(self.shape) == len(other.shape) == 0:\n return 0\n return not alltrue(equal(self.shape,other.shape))\n\n def __add__(self,other): return self.binary_op(other)\n def __radd__(self,other): return self.binary_op(other)\n def __sub__(self,other): return self.binary_op(other)\n def __rsub__(self,other): return self.binary_op(other)\n def __mul__(self,other): return self.binary_op(other)\n def __rmul__(self,other): return self.binary_op(other)\n def __div__(self,other): return self.binary_op(other)\n def __rdiv__(self,other): return self.binary_op(other)\n def __mod__(self,other): return self.binary_op(other)\n def __rmod__(self,other): return self.binary_op(other)\n def __lshift__(self,other): return self.binary_op(other)\n def __rshift__(self,other): return self.binary_op(other)\n # unary ops\n def __neg__(self,other): return self\n def __pos__(self,other): return self\n def __abs__(self,other): return self\n def __invert__(self,other): return self \n # Not sure what to do with coersion ops. Ignore for now.\n #\n # not currently supported by compiler.\n # __divmod__\n # __pow__\n # __rpow__\n # __and__\n # __or__\n # __xor__\n # item access and slicing \n def __setitem__(self,indices,val):\n #ignore for now\n pass\n def __len__(self):\n return self.shape[0]\n def __getslice__(self,i,j):\n # enabling the following would make class compatible with\n # lists. Its current incarnation is compatible with arrays.\n # Both this and Numeric should have this FIXED to correspond\n # to lists.\n #i = max(i, 0); j = max(j, 0)\n return self.__getitem__((slice(i,j),))\n def __getitem__(self,indices):\n # ayeyaya this is a mess\n #print indices, type(indices), indices.shape \n if type(indices) is not TupleType:\n indices = (indices,)\n if Ellipsis in indices:\n raise IndexError, \"Ellipsis not currently supported\"\n new_dims = [] \n dim = 0 \n for index in indices:\n try:\n dim_len = self.shape[dim]\n except IndexError:\n raise IndexError, \"To many indices specified\"\n \n #if (type(index) is SliceType and index.start == index.stop == index.step):\n if (index is empty_slice):\n slc_len = dim_len\n elif type(index) is SliceType:\n beg,end,step = index.start,index.stop,index.step \n # handle if they are dummy arrays\n #if hasattr(beg,'value') and type(beg.value) != ArrayType:\n # beg = beg.value\n #if hasattr(end,'value') and type(end.value) != ArrayType:\n # end = end.value\n #if hasattr(step,'value') and type(step.value) != ArrayType:\n # step = step.value \n if beg is None: beg = 0\n if end == sys.maxint or end is None:\n end = dim_len\n if step is None: \n step = 1\n \n if beg < 0: beg += dim_len\n if end < 0: end += dim_len\n # the following is list like behavior,\n # which isn't adhered to by arrays. \n # FIX THIS ANOMOLY IN NUMERIC!\n if beg < 0: beg = 0\n if beg > dim_len: beg = dim_len\n if end < 0: end = 0\n if end > dim_len: end = dim_len\n # This is rubbish. \n if beg == end:\n beg,end,step = 0,0,1\n elif beg >= dim_len and step > 0:\n beg,end,step = 0,0,1\n #elif index.step > 0 and beg <= end:\n elif step > 0 and beg <= end:\n pass #slc_len = abs(divide(end-beg-1,step)+1) \n # handle [::-1] and [-1::-1] correctly \n #elif index.step > 0 and beg > end:\n elif step > 0 and beg > end:\n beg,end,step = 0,0,1\n elif(step < 0 and index.start is None and index.stop is None):\n beg,end,step = 0,dim_len,-step\n elif(step < 0 and index.start is None):\n # +1 because negative stepping is inclusive\n beg,end,step = end+1,dim_len,-step \n elif(step < 0 and index.stop is None):\n beg,end,step = 0,beg+1,-step\n elif(step < 0 and beg > end): \n beg,end,step = end,beg,-step\n elif(step < 0 and beg < end): \n beg,end,step = 0,0,-step\n slc_len = abs(divide(end-beg-1,step)+1)\n new_dims.append(slc_len)\n else:\n if index < 0: index += dim_len\n if index >=0 and index < dim_len:\n #this reduces the array dimensions by one\n pass\n else:\n raise IndexError, \"Index out of range\" \n dim += 1 \n new_dims.extend(self.shape[dim:])\n if 0 in new_dims:\n raise IndexError, \"Zero length slices not currently supported\"\n return dummy_array(new_dims,1)\n def __repr__(self):\n val = str((self.name, str(self.shape)))\n return val \n\ndef unary(ary):\n return ary\n\ndef not_implemented(ary):\n return ary\n \n#all imported from Numeric and need to be reassigned.\nunary_op = [arccos, arcsin, arctan, cos, cosh, sin, sinh, \n exp,ceil,floor,fabs,log,log10,sqrt]\n\nunsupported = [argmin,argmax, argsort,around, absolute,sign,negative,floor]\n\nfor func in unary_op:\n func = unary\n \nfor func in unsupported:\n func = not_implemented\n \ndef reduction(ary,axis=0):\n if axis < 0:\n axis += len(ary.shape) \n if axis < 0 or axis >= len(ary.shape):\n raise ValueError, \"Dimension not in array\" \n new_dims = list(ary.shape[:axis]) + list(ary.shape[axis+1:])\n return dummy_array(new_dims,1) \n\n# functions currently not supported by compiler\n# reductions are gonna take some array reordering for the general case,\n# so this is gonna take some thought (probably some tree manipulation).\ndef take(ary,axis=0): raise NotImplemented\n# and all the rest\n \ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n ", "methods": [ { "name": "time_it", "long_name": "time_it( )", "filename": "size_check.py", "nloc": 18, "complexity": 2, "token_count": 158, "parameters": [], "start_line": 13, "end_line": 32, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 }, { "name": "check_expr", "long_name": "check_expr( expr , local_vars , global_vars = { } )", "filename": "size_check.py", "nloc": 21, "complexity": 9, "token_count": 159, "parameters": [ "expr", "local_vars", "global_vars" ], "start_line": 34, "end_line": 60, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 27, "top_nesting_level": 0 }, { "name": "make_same_length", "long_name": "make_same_length( x , y )", "filename": "size_check.py", "nloc": 20, "complexity": 7, "token_count": 115, "parameters": [ "x", "y" ], "start_line": 65, "end_line": 84, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 }, { "name": "binary_op_size", "long_name": "binary_op_size( xx , yy )", "filename": "size_check.py", "nloc": 13, "complexity": 5, "token_count": 100, "parameters": [ "xx", "yy" ], "start_line": 86, "end_line": 103, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 0 }, { "name": "__init__", "long_name": "__init__( self , ary , ary_is_shape = 0 , name = None )", "filename": "size_check.py", "nloc": 9, "complexity": 3, "token_count": 47, "parameters": [ "self", "ary", "ary_is_shape", "name" ], "start_line": 105, "end_line": 114, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "binary_op", "long_name": "binary_op( self , other )", "filename": "size_check.py", "nloc": 7, "complexity": 2, "token_count": 37, "parameters": [ "self", "other" ], "start_line": 116, "end_line": 122, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "__cmp__", "long_name": "__cmp__( self , other )", "filename": "size_check.py", "nloc": 6, "complexity": 3, "token_count": 59, "parameters": [ "self", "other" ], "start_line": 123, "end_line": 130, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "__setitem__", "long_name": "__setitem__( self , indices , val )", "filename": "size_check.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "self", "indices", "val" ], "start_line": 159, "end_line": 161, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "__len__", "long_name": "__len__( self )", "filename": "size_check.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "self" ], "start_line": 162, "end_line": 163, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__getslice__", "long_name": "__getslice__( self , i , j )", "filename": "size_check.py", "nloc": 2, "complexity": 1, "token_count": 24, "parameters": [ "self", "i", "j" ], "start_line": 164, "end_line": 170, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "__getitem__", "long_name": "__getitem__( self , indices )", "filename": "size_check.py", "nloc": 58, "complexity": 39, "token_count": 450, "parameters": [ "self", "indices" ], "start_line": 171, "end_line": 249, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 79, "top_nesting_level": 1 }, { "name": "__repr__", "long_name": "__repr__( self )", "filename": "size_check.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 250, "end_line": 252, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "unary", "long_name": "unary( ary )", "filename": "size_check.py", "nloc": 2, "complexity": 1, "token_count": 7, "parameters": [ "ary" ], "start_line": 254, "end_line": 255, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "not_implemented", "long_name": "not_implemented( ary )", "filename": "size_check.py", "nloc": 2, "complexity": 1, "token_count": 7, "parameters": [ "ary" ], "start_line": 257, "end_line": 258, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "reduction", "long_name": "reduction( ary , axis = 0 )", "filename": "size_check.py", "nloc": 7, "complexity": 4, "token_count": 72, "parameters": [ "ary", "axis" ], "start_line": 272, "end_line": 278, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "size_check.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 286, "end_line": 288, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "size_check.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 290, "end_line": 292, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "methods_before": [ { "name": "time_it", "long_name": "time_it( )", "filename": "size_check.py", "nloc": 18, "complexity": 2, "token_count": 158, "parameters": [], "start_line": 7, "end_line": 26, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 }, { "name": "check_expr", "long_name": "check_expr( expr , local_vars , global_vars = { } )", "filename": "size_check.py", "nloc": 21, "complexity": 9, "token_count": 159, "parameters": [ "expr", "local_vars", "global_vars" ], "start_line": 28, "end_line": 54, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 27, "top_nesting_level": 0 }, { "name": "make_same_length", "long_name": "make_same_length( x , y )", "filename": "size_check.py", "nloc": 20, "complexity": 7, "token_count": 115, "parameters": [ "x", "y" ], "start_line": 59, "end_line": 78, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 }, { "name": "binary_op_size", "long_name": "binary_op_size( xx , yy )", "filename": "size_check.py", "nloc": 13, "complexity": 5, "token_count": 100, "parameters": [ "xx", "yy" ], "start_line": 80, "end_line": 97, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 0 }, { "name": "__init__", "long_name": "__init__( self , ary , ary_is_shape = 0 , name = None )", "filename": "size_check.py", "nloc": 9, "complexity": 3, "token_count": 47, "parameters": [ "self", "ary", "ary_is_shape", "name" ], "start_line": 99, "end_line": 108, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "binary_op", "long_name": "binary_op( self , other )", "filename": "size_check.py", "nloc": 7, "complexity": 2, "token_count": 37, "parameters": [ "self", "other" ], "start_line": 110, "end_line": 116, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "__cmp__", "long_name": "__cmp__( self , other )", "filename": "size_check.py", "nloc": 6, "complexity": 3, "token_count": 59, "parameters": [ "self", "other" ], "start_line": 117, "end_line": 124, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "__setitem__", "long_name": "__setitem__( self , indices , val )", "filename": "size_check.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "self", "indices", "val" ], "start_line": 153, "end_line": 155, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "__len__", "long_name": "__len__( self )", "filename": "size_check.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "self" ], "start_line": 156, "end_line": 157, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "__getslice__", "long_name": "__getslice__( self , i , j )", "filename": "size_check.py", "nloc": 2, "complexity": 1, "token_count": 24, "parameters": [ "self", "i", "j" ], "start_line": 158, "end_line": 164, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "__getitem__", "long_name": "__getitem__( self , indices )", "filename": "size_check.py", "nloc": 58, "complexity": 39, "token_count": 450, "parameters": [ "self", "indices" ], "start_line": 165, "end_line": 243, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 79, "top_nesting_level": 1 }, { "name": "__repr__", "long_name": "__repr__( self )", "filename": "size_check.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 244, "end_line": 246, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "unary", "long_name": "unary( ary )", "filename": "size_check.py", "nloc": 2, "complexity": 1, "token_count": 7, "parameters": [ "ary" ], "start_line": 248, "end_line": 249, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "not_implemented", "long_name": "not_implemented( ary )", "filename": "size_check.py", "nloc": 2, "complexity": 1, "token_count": 7, "parameters": [ "ary" ], "start_line": 251, "end_line": 252, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "reduction", "long_name": "reduction( ary , axis = 0 )", "filename": "size_check.py", "nloc": 7, "complexity": 4, "token_count": 72, "parameters": [ "ary", "axis" ], "start_line": 266, "end_line": 272, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "size_check.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 280, "end_line": 282, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "size_check.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 284, "end_line": 286, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "changed_methods": [], "nloc": 213, "complexity": 82, "token_count": 1664, "diff_parsed": { "added": [ "", "# The following try/except so that non-SciPy users can still use blitz", "try:", " from fastumath import *", "except:", " pass # fastumath not available", "" ], "deleted": [ "from fastumath import *" ] } }, { "old_path": "weave/tests/test_standard_array_spec.py", "new_path": "weave/tests/test_standard_array_spec.py", "filename": "test_standard_array_spec.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -1,6 +1,10 @@\n import unittest\n from Numeric import *\n-from fastumath import *\n+# The following try/except so that non-SciPy users can still use blitz\n+try:\n+ from fastumath import *\n+except:\n+ pass # fastumath not available \n import RandomArray\n import time\n \n", "added_lines": 5, "deleted_lines": 1, "source_code": "import unittest\nfrom Numeric import *\n# The following try/except so that non-SciPy users can still use blitz\ntry:\n from fastumath import *\nexcept:\n pass # fastumath not available \nimport RandomArray\nimport time\n\nfrom scipy_distutils.misc_util import add_grandparent_to_path, restore_path\n\nadd_grandparent_to_path(__name__)\nimport standard_array_spec\nrestore_path()\n\ndef remove_whitespace(in_str):\n import string\n out = string.replace(in_str,\" \",\"\")\n out = string.replace(out,\"\\t\",\"\")\n out = string.replace(out,\"\\n\",\"\")\n return out\n \ndef print_assert_equal(test_string,actual,desired):\n \"\"\"this should probably be in scipy.scipy_test\n \"\"\"\n import pprint\n try:\n assert(actual == desired)\n except AssertionError:\n import cStringIO\n msg = cStringIO.StringIO()\n msg.write(test_string)\n msg.write(' failed\\nACTUAL: \\n')\n pprint.pprint(actual,msg)\n msg.write('DESIRED: \\n')\n pprint.pprint(desired,msg)\n raise AssertionError, msg.getvalue()\n\nclass test_array_specification(unittest.TestCase): \n def check_type_match_string(self):\n s = standard_array_spec.array_specification()\n assert( not s.type_match('string') )\n def check_type_match_int(self):\n s = standard_array_spec.array_specification() \n assert(not s.type_match(5))\n def check_type_match_array(self):\n s = standard_array_spec.array_specification() \n assert(s.type_match(arange(4)))\n\ndef test_suite():\n suites = []\n \n suites.append( unittest.makeSuite(test_array_specification,'check_'))\n\n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\nif __name__ == \"__main__\":\n test()\n", "source_code_before": "import unittest\nfrom Numeric import *\nfrom fastumath import *\nimport RandomArray\nimport time\n\nfrom scipy_distutils.misc_util import add_grandparent_to_path, restore_path\n\nadd_grandparent_to_path(__name__)\nimport standard_array_spec\nrestore_path()\n\ndef remove_whitespace(in_str):\n import string\n out = string.replace(in_str,\" \",\"\")\n out = string.replace(out,\"\\t\",\"\")\n out = string.replace(out,\"\\n\",\"\")\n return out\n \ndef print_assert_equal(test_string,actual,desired):\n \"\"\"this should probably be in scipy.scipy_test\n \"\"\"\n import pprint\n try:\n assert(actual == desired)\n except AssertionError:\n import cStringIO\n msg = cStringIO.StringIO()\n msg.write(test_string)\n msg.write(' failed\\nACTUAL: \\n')\n pprint.pprint(actual,msg)\n msg.write('DESIRED: \\n')\n pprint.pprint(desired,msg)\n raise AssertionError, msg.getvalue()\n\nclass test_array_specification(unittest.TestCase): \n def check_type_match_string(self):\n s = standard_array_spec.array_specification()\n assert( not s.type_match('string') )\n def check_type_match_int(self):\n s = standard_array_spec.array_specification() \n assert(not s.type_match(5))\n def check_type_match_array(self):\n s = standard_array_spec.array_specification() \n assert(s.type_match(arange(4)))\n\ndef test_suite():\n suites = []\n \n suites.append( unittest.makeSuite(test_array_specification,'check_'))\n\n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\nif __name__ == \"__main__\":\n test()\n", "methods": [ { "name": "remove_whitespace", "long_name": "remove_whitespace( in_str )", "filename": "test_standard_array_spec.py", "nloc": 6, "complexity": 1, "token_count": 45, "parameters": [ "in_str" ], "start_line": 17, "end_line": 22, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 }, { "name": "print_assert_equal", "long_name": "print_assert_equal( test_string , actual , desired )", "filename": "test_standard_array_spec.py", "nloc": 13, "complexity": 2, "token_count": 74, "parameters": [ "test_string", "actual", "desired" ], "start_line": 24, "end_line": 38, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "check_type_match_string", "long_name": "check_type_match_string( self )", "filename": "test_standard_array_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 41, "end_line": 43, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_int", "long_name": "check_type_match_int( self )", "filename": "test_standard_array_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 44, "end_line": 46, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_array", "long_name": "check_type_match_array( self )", "filename": "test_standard_array_spec.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 47, "end_line": 49, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_standard_array_spec.py", "nloc": 5, "complexity": 1, "token_count": 31, "parameters": [], "start_line": 51, "end_line": 57, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_standard_array_spec.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 59, "end_line": 63, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "methods_before": [ { "name": "remove_whitespace", "long_name": "remove_whitespace( in_str )", "filename": "test_standard_array_spec.py", "nloc": 6, "complexity": 1, "token_count": 45, "parameters": [ "in_str" ], "start_line": 13, "end_line": 18, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 }, { "name": "print_assert_equal", "long_name": "print_assert_equal( test_string , actual , desired )", "filename": "test_standard_array_spec.py", "nloc": 13, "complexity": 2, "token_count": 74, "parameters": [ "test_string", "actual", "desired" ], "start_line": 20, "end_line": 34, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "check_type_match_string", "long_name": "check_type_match_string( self )", "filename": "test_standard_array_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 37, "end_line": 39, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_int", "long_name": "check_type_match_int( self )", "filename": "test_standard_array_spec.py", "nloc": 3, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 40, "end_line": 42, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_type_match_array", "long_name": "check_type_match_array( self )", "filename": "test_standard_array_spec.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 43, "end_line": 45, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_standard_array_spec.py", "nloc": 5, "complexity": 1, "token_count": 31, "parameters": [], "start_line": 47, "end_line": 53, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_standard_array_spec.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 55, "end_line": 59, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "changed_methods": [], "nloc": 53, "complexity": 8, "token_count": 301, "diff_parsed": { "added": [ "# The following try/except so that non-SciPy users can still use blitz", "try:", " from fastumath import *", "except:", " pass # fastumath not available" ], "deleted": [ "from fastumath import *" ] } } ] }, { "hash": "9c3800541fde7929f892892af41b89efec29a186", "msg": "converted all files (hopefully) from DOS style line endings to UNIX style line endings. Some of the Unix users were having problems with files with DOS style endings. Windows doesn't seem to be as picky about this issue.", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-05T17:42:47+00:00", "author_timezone": 0, "committer_date": "2002-01-05T17:42:47+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "f2e5fb8573178cb7a8924d57e70bf9c199034622" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 3, "insertions": 15, "lines": 18, "files": 3, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": "weave/tests/test_ast_tools.py", "new_path": "weave/tests/test_ast_tools.py", "filename": "test_ast_tools.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -1,6 +1,10 @@\n import unittest\n from Numeric import *\n-from fastumath import *\n+# The following try/except so that non-SciPy users can still use blitz\n+try:\n+ from fastumath import *\n+except:\n+ pass # fastumath not available \n import RandomArray\n import time\n \n", "added_lines": 5, "deleted_lines": 1, "source_code": "import unittest\nfrom Numeric import *\n# The following try/except so that non-SciPy users can still use blitz\ntry:\n from fastumath import *\nexcept:\n pass # fastumath not available \nimport RandomArray\nimport time\n\nfrom scipy_distutils.misc_util import add_grandparent_to_path, restore_path\nfrom scipy_distutils.misc_util import add_local_to_path\n\nadd_grandparent_to_path(__name__)\nimport ast_tools\nrestore_path()\n\nadd_local_to_path(__name__)\nfrom weave_test_utils import *\nrestore_path()\n\nclass test_harvest_variables(unittest.TestCase):\n \"\"\" Not much testing going on here, but \n at least it is a flame test.\n \"\"\" \n def generic_test(self,expr,desired):\n import parser\n ast_list = parser.suite(expr).tolist()\n actual = ast_tools.harvest_variables(ast_list)\n print_assert_equal(expr,actual,desired)\n\n def check_simple_expr(self):\n \"\"\"convert simple expr to blitz\n \n a[:1:2] = b[:1+i+2:]\n \"\"\"\n expr = \"a[:1:2] = b[:1+i+2:]\" \n desired = ['a','b','i'] \n self.generic_test(expr,desired)\n\n\ndef test_suite():\n suites = []\n suites.append( unittest.makeSuite(test_harvest_variables,'check_') )\n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\nif __name__ == \"__main__\":\n test()\n", "source_code_before": "import unittest\nfrom Numeric import *\nfrom fastumath import *\nimport RandomArray\nimport time\n\nfrom scipy_distutils.misc_util import add_grandparent_to_path, restore_path\nfrom scipy_distutils.misc_util import add_local_to_path\n\nadd_grandparent_to_path(__name__)\nimport ast_tools\nrestore_path()\n\nadd_local_to_path(__name__)\nfrom weave_test_utils import *\nrestore_path()\n\nclass test_harvest_variables(unittest.TestCase):\n \"\"\" Not much testing going on here, but \n at least it is a flame test.\n \"\"\" \n def generic_test(self,expr,desired):\n import parser\n ast_list = parser.suite(expr).tolist()\n actual = ast_tools.harvest_variables(ast_list)\n print_assert_equal(expr,actual,desired)\n\n def check_simple_expr(self):\n \"\"\"convert simple expr to blitz\n \n a[:1:2] = b[:1+i+2:]\n \"\"\"\n expr = \"a[:1:2] = b[:1+i+2:]\" \n desired = ['a','b','i'] \n self.generic_test(expr,desired)\n\n\ndef test_suite():\n suites = []\n suites.append( unittest.makeSuite(test_harvest_variables,'check_') )\n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\nif __name__ == \"__main__\":\n test()\n", "methods": [ { "name": "generic_test", "long_name": "generic_test( self , expr , desired )", "filename": "test_ast_tools.py", "nloc": 5, "complexity": 1, "token_count": 39, "parameters": [ "self", "expr", "desired" ], "start_line": 26, "end_line": 30, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_simple_expr", "long_name": "check_simple_expr( self )", "filename": "test_ast_tools.py", "nloc": 4, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 32, "end_line": 39, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_ast_tools.py", "nloc": 5, "complexity": 1, "token_count": 31, "parameters": [], "start_line": 42, "end_line": 46, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_ast_tools.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 48, "end_line": 52, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "methods_before": [ { "name": "generic_test", "long_name": "generic_test( self , expr , desired )", "filename": "test_ast_tools.py", "nloc": 5, "complexity": 1, "token_count": 39, "parameters": [ "self", "expr", "desired" ], "start_line": 22, "end_line": 26, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_simple_expr", "long_name": "check_simple_expr( self )", "filename": "test_ast_tools.py", "nloc": 4, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 28, "end_line": 35, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_ast_tools.py", "nloc": 5, "complexity": 1, "token_count": 31, "parameters": [], "start_line": 38, "end_line": 42, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_ast_tools.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 44, "end_line": 48, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "changed_methods": [], "nloc": 41, "complexity": 4, "token_count": 194, "diff_parsed": { "added": [ "# The following try/except so that non-SciPy users can still use blitz", "try:", " from fastumath import *", "except:", " pass # fastumath not available" ], "deleted": [ "from fastumath import *" ] } }, { "old_path": "weave/tests/test_blitz_tools.py", "new_path": "weave/tests/test_blitz_tools.py", "filename": "test_blitz_tools.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -1,6 +1,10 @@\n import unittest\n from Numeric import *\n-from fastumath import *\n+# The following try/except so that non-SciPy users can still use blitz\n+try:\n+ from fastumath import *\n+except:\n+ pass # fastumath not available \n import RandomArray\n import os\n import time\n", "added_lines": 5, "deleted_lines": 1, "source_code": "import unittest\nfrom Numeric import *\n# The following try/except so that non-SciPy users can still use blitz\ntry:\n from fastumath import *\nexcept:\n pass # fastumath not available \nimport RandomArray\nimport os\nimport time\n\nfrom scipy_distutils.misc_util import add_grandparent_to_path,restore_path\nfrom scipy_distutils.misc_util import add_local_to_path\n\nadd_grandparent_to_path(__name__)\nimport blitz_tools\nfrom ast_tools import *\nfrom weave_test_utils import *\nrestore_path()\n\nadd_local_to_path(__name__)\nimport test_scalar_spec\nrestore_path()\n\nclass test_ast_to_blitz_expr(unittest.TestCase):\n\n def generic_test(self,expr,desired):\n import parser\n ast = parser.suite(expr)\n ast_list = ast.tolist()\n actual = blitz_tools.ast_to_blitz_expr(ast_list)\n actual = remove_whitespace(actual)\n desired = remove_whitespace(desired)\n print_assert_equal(expr,actual,desired)\n\n def check_simple_expr(self):\n \"\"\"convert simple expr to blitz\n \n a[:1:2] = b[:1+i+2:]\n \"\"\"\n expr = \"a[:1:2] = b[:1+i+2:]\" \n desired = \"a(blitz::Range(_beg,1-1,2))=\"\\\n \"b(blitz::Range(_beg,1+i+2-1));\"\n self.generic_test(expr,desired)\n\n def check_fdtd_expr(self):\n \"\"\" convert fdtd equation to blitz.\n ex[:,1:,1:] = ca_x[:,1:,1:] * ex[:,1:,1:] \n + cb_y_x[:,1:,1:] * (hz[:,1:,1:] - hz[:,:-1,:])\n - cb_z_x[:,1:,1:] * (hy[:,1:,1:] - hy[:,1:,:-1]);\n Note: This really should have \"\\\" at the end of each line\n to indicate continuation. \n \"\"\"\n expr = \"ex[:,1:,1:] = ca_x[:,1:,1:] * ex[:,1:,1:]\" \\\n \"+ cb_y_x[:,1:,1:] * (hz[:,1:,1:] - hz[:,:-1,:])\"\\\n \"- cb_z_x[:,1:,1:] * (hy[:,1:,1:] - hy[:,1:,:-1])\" \n desired = 'ex(_all,blitz::Range(1,_end),blitz::Range(1,_end))='\\\n ' ca_x(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n ' *ex(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '+cb_y_x(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '*(hz(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n ' -hz(_all,blitz::Range(_beg,_Nhz(1)-1-1),_all))'\\\n ' -cb_z_x(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '*(hy(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '-hy(_all,blitz::Range(1,_end),blitz::Range(_beg,_Nhy(2)-1-1)));'\n self.generic_test(expr,desired)\n\nclass test_blitz(unittest.TestCase):\n \"\"\"* These are long running tests...\n \n I'd like to benchmark these things somehow.\n *\"\"\"\n def generic_test(self,expr,arg_dict,type,size):\n mod_location = setup_test_location()\n clean_result = array(arg_dict['result'],copy=1)\n t1 = time.time()\n exec expr in globals(),arg_dict\n t2 = time.time()\n standard = t2 - t1\n desired = arg_dict['result']\n arg_dict['result'] = clean_result\n t1 = time.time()\n old_env = os.environ.get('PYTHONCOMPILED','')\n os.environ['PYTHONCOMPILED'] = mod_location\n blitz_tools.blitz(expr,arg_dict,{},verbose=0)\n os.environ['PYTHONCOMPILED'] = old_env\n t2 = time.time()\n compiled = t2 - t1\n actual = arg_dict['result']\n # this really should give more info...\n try:\n # this isn't very stringent. Need to tighten this up and\n # learn where failures are occuring.\n assert(allclose(abs(actual.flat),abs(desired.flat),1e-4,1e-6))\n except:\n diff = actual-desired\n print diff[:4,:4]\n print diff[:4,-4:]\n print diff[-4:,:4]\n print diff[-4:,-4:]\n print sum(abs(diff.flat)) \n teardown_test_location()\n raise AssertionError \n teardown_test_location() \n return standard,compiled\n \n def generic_2d(self,expr):\n \"\"\" The complex testing is pretty lame...\n \"\"\"\n import parser\n ast = parser.suite(expr)\n arg_list = harvest_variables(ast.tolist())\n #print arg_list\n all_types = [Float32,Float64,Complex32,Complex64]\n all_sizes = [(10,10), (50,50), (100,100), (500,500), (1000,1000)]\n print '\\nExpression:', expr\n for typ in all_types:\n for size in all_sizes:\n result = zeros(size,typ)\n arg_dict = {}\n for arg in arg_list:\n arg_dict[arg] = RandomArray.normal(0,1,size).astype(typ)\n arg_dict[arg].savespace(1)\n # set imag part of complex values to non-zero value\n try: arg_dict[arg].imag = arg_dict[arg].real\n except: pass \n print 'Run:', size,typ\n standard,compiled = self.generic_test(expr,arg_dict,type,size)\n try:\n speed_up = standard/compiled\n except:\n speed_up = -1.\n print \"1st run(Numeric,compiled,speed up): %3.4f, %3.4f, \" \\\n \"%3.4f\" % (standard,compiled,speed_up) \n standard,compiled = self.generic_test(expr,arg_dict,type,size)\n try:\n speed_up = standard/compiled\n except:\n speed_up = -1. \n print \"2nd run(Numeric,compiled,speed up): %3.4f, %3.4f, \" \\\n \"%3.4f\" % (standard,compiled,speed_up) \n #def check_simple_2d(self):\n # \"\"\" result = a + b\"\"\" \n # expr = \"result = a + b\"\n # self.generic_2d(expr)\n def check_5point_avg_2d(self):\n \"\"\" result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\n + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n \"\"\" \n expr = \"result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n self.generic_2d(expr)\n \n def setUp(self):\n # try and get rid of any shared libraries that currently exist in \n # test directory. If some other program is using them though,\n # (another process is running exact same tests, this will to \n # fail clean-up stuff on NT) \n #remove_test_files()\n pass\n def tearDown(self):\n #print '\\n\\n\\ntearing down\\n\\n\\n'\n #remove_test_files()\n # Get rid of any files created by the test such as function catalogs\n # and compiled modules.\n # We'll assume any .pyd, .so files, .cpp, .def or .o \n # in the test directory is a test file. To make sure we\n # don't abliterate something desireable, we'll move it\n # to a file called 'test_trash'\n teardown_test_location()\n \ndef remove_test_files():\n import os,glob\n test_dir = compiler.compile_code.home_dir(__file__)\n trash = os.path.join(test_dir,'test_trash')\n files = glob.glob(os.path.join(test_dir,'*.so'))\n files += glob.glob(os.path.join(test_dir,'*.o'))\n files += glob.glob(os.path.join(test_dir,'*.a'))\n files += glob.glob(os.path.join(test_dir,'*.cpp'))\n files += glob.glob(os.path.join(test_dir,'*.pyd'))\n files += glob.glob(os.path.join(test_dir,'*.def'))\n files += glob.glob(os.path.join(test_dir,'*compiled_catalog*'))\n for i in files:\n try:\n #print i\n os.remove(i)\n except: \n pass \n #all this was to handle \"saving files in trash, but doesn't fly on NT\n #d,f=os.path.split(i)\n #trash_file = os.path.join(trash,f)\n #print 'tf:',trash_file\n #if os.path.exists(trash_file):\n # os.remove(trash_file)\n # print trash_file\n #os.renames(i,trash_file)\n\ndef setup_test_location():\n import tempfile\n pth = os.path.join(tempfile.gettempdir(),'test_files')\n if not os.path.exists(pth):\n os.mkdir(pth)\n #sys.path.insert(0,pth) \n return pth\n\ndef teardown_test_location():\n pass\n #import tempfile \n #pth = os.path.join(tempfile.gettempdir(),'test_files')\n #if sys.path[0] == pth:\n # sys.path = sys.path[1:]\n #return pth\n\ndef test_suite():\n suites = []\n suites.append( unittest.makeSuite(test_ast_to_blitz_expr,'check_') )\n suites.append( unittest.makeSuite(test_blitz,'check_') ) \n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\nif __name__ == \"__main__\":\n test()\n", "source_code_before": "import unittest\nfrom Numeric import *\nfrom fastumath import *\nimport RandomArray\nimport os\nimport time\n\nfrom scipy_distutils.misc_util import add_grandparent_to_path,restore_path\nfrom scipy_distutils.misc_util import add_local_to_path\n\nadd_grandparent_to_path(__name__)\nimport blitz_tools\nfrom ast_tools import *\nfrom weave_test_utils import *\nrestore_path()\n\nadd_local_to_path(__name__)\nimport test_scalar_spec\nrestore_path()\n\nclass test_ast_to_blitz_expr(unittest.TestCase):\n\n def generic_test(self,expr,desired):\n import parser\n ast = parser.suite(expr)\n ast_list = ast.tolist()\n actual = blitz_tools.ast_to_blitz_expr(ast_list)\n actual = remove_whitespace(actual)\n desired = remove_whitespace(desired)\n print_assert_equal(expr,actual,desired)\n\n def check_simple_expr(self):\n \"\"\"convert simple expr to blitz\n \n a[:1:2] = b[:1+i+2:]\n \"\"\"\n expr = \"a[:1:2] = b[:1+i+2:]\" \n desired = \"a(blitz::Range(_beg,1-1,2))=\"\\\n \"b(blitz::Range(_beg,1+i+2-1));\"\n self.generic_test(expr,desired)\n\n def check_fdtd_expr(self):\n \"\"\" convert fdtd equation to blitz.\n ex[:,1:,1:] = ca_x[:,1:,1:] * ex[:,1:,1:] \n + cb_y_x[:,1:,1:] * (hz[:,1:,1:] - hz[:,:-1,:])\n - cb_z_x[:,1:,1:] * (hy[:,1:,1:] - hy[:,1:,:-1]);\n Note: This really should have \"\\\" at the end of each line\n to indicate continuation. \n \"\"\"\n expr = \"ex[:,1:,1:] = ca_x[:,1:,1:] * ex[:,1:,1:]\" \\\n \"+ cb_y_x[:,1:,1:] * (hz[:,1:,1:] - hz[:,:-1,:])\"\\\n \"- cb_z_x[:,1:,1:] * (hy[:,1:,1:] - hy[:,1:,:-1])\" \n desired = 'ex(_all,blitz::Range(1,_end),blitz::Range(1,_end))='\\\n ' ca_x(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n ' *ex(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '+cb_y_x(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '*(hz(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n ' -hz(_all,blitz::Range(_beg,_Nhz(1)-1-1),_all))'\\\n ' -cb_z_x(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '*(hy(_all,blitz::Range(1,_end),blitz::Range(1,_end))'\\\n '-hy(_all,blitz::Range(1,_end),blitz::Range(_beg,_Nhy(2)-1-1)));'\n self.generic_test(expr,desired)\n\nclass test_blitz(unittest.TestCase):\n \"\"\"* These are long running tests...\n \n I'd like to benchmark these things somehow.\n *\"\"\"\n def generic_test(self,expr,arg_dict,type,size):\n mod_location = setup_test_location()\n clean_result = array(arg_dict['result'],copy=1)\n t1 = time.time()\n exec expr in globals(),arg_dict\n t2 = time.time()\n standard = t2 - t1\n desired = arg_dict['result']\n arg_dict['result'] = clean_result\n t1 = time.time()\n old_env = os.environ.get('PYTHONCOMPILED','')\n os.environ['PYTHONCOMPILED'] = mod_location\n blitz_tools.blitz(expr,arg_dict,{},verbose=0)\n os.environ['PYTHONCOMPILED'] = old_env\n t2 = time.time()\n compiled = t2 - t1\n actual = arg_dict['result']\n # this really should give more info...\n try:\n # this isn't very stringent. Need to tighten this up and\n # learn where failures are occuring.\n assert(allclose(abs(actual.flat),abs(desired.flat),1e-4,1e-6))\n except:\n diff = actual-desired\n print diff[:4,:4]\n print diff[:4,-4:]\n print diff[-4:,:4]\n print diff[-4:,-4:]\n print sum(abs(diff.flat)) \n teardown_test_location()\n raise AssertionError \n teardown_test_location() \n return standard,compiled\n \n def generic_2d(self,expr):\n \"\"\" The complex testing is pretty lame...\n \"\"\"\n import parser\n ast = parser.suite(expr)\n arg_list = harvest_variables(ast.tolist())\n #print arg_list\n all_types = [Float32,Float64,Complex32,Complex64]\n all_sizes = [(10,10), (50,50), (100,100), (500,500), (1000,1000)]\n print '\\nExpression:', expr\n for typ in all_types:\n for size in all_sizes:\n result = zeros(size,typ)\n arg_dict = {}\n for arg in arg_list:\n arg_dict[arg] = RandomArray.normal(0,1,size).astype(typ)\n arg_dict[arg].savespace(1)\n # set imag part of complex values to non-zero value\n try: arg_dict[arg].imag = arg_dict[arg].real\n except: pass \n print 'Run:', size,typ\n standard,compiled = self.generic_test(expr,arg_dict,type,size)\n try:\n speed_up = standard/compiled\n except:\n speed_up = -1.\n print \"1st run(Numeric,compiled,speed up): %3.4f, %3.4f, \" \\\n \"%3.4f\" % (standard,compiled,speed_up) \n standard,compiled = self.generic_test(expr,arg_dict,type,size)\n try:\n speed_up = standard/compiled\n except:\n speed_up = -1. \n print \"2nd run(Numeric,compiled,speed up): %3.4f, %3.4f, \" \\\n \"%3.4f\" % (standard,compiled,speed_up) \n #def check_simple_2d(self):\n # \"\"\" result = a + b\"\"\" \n # expr = \"result = a + b\"\n # self.generic_2d(expr)\n def check_5point_avg_2d(self):\n \"\"\" result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\n + b[1:-1,2:] + b[1:-1,:-2]) / 5.\n \"\"\" \n expr = \"result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]\" \\\n \"+ b[1:-1,2:] + b[1:-1,:-2]) / 5.\"\n self.generic_2d(expr)\n \n def setUp(self):\n # try and get rid of any shared libraries that currently exist in \n # test directory. If some other program is using them though,\n # (another process is running exact same tests, this will to \n # fail clean-up stuff on NT) \n #remove_test_files()\n pass\n def tearDown(self):\n #print '\\n\\n\\ntearing down\\n\\n\\n'\n #remove_test_files()\n # Get rid of any files created by the test such as function catalogs\n # and compiled modules.\n # We'll assume any .pyd, .so files, .cpp, .def or .o \n # in the test directory is a test file. To make sure we\n # don't abliterate something desireable, we'll move it\n # to a file called 'test_trash'\n teardown_test_location()\n \ndef remove_test_files():\n import os,glob\n test_dir = compiler.compile_code.home_dir(__file__)\n trash = os.path.join(test_dir,'test_trash')\n files = glob.glob(os.path.join(test_dir,'*.so'))\n files += glob.glob(os.path.join(test_dir,'*.o'))\n files += glob.glob(os.path.join(test_dir,'*.a'))\n files += glob.glob(os.path.join(test_dir,'*.cpp'))\n files += glob.glob(os.path.join(test_dir,'*.pyd'))\n files += glob.glob(os.path.join(test_dir,'*.def'))\n files += glob.glob(os.path.join(test_dir,'*compiled_catalog*'))\n for i in files:\n try:\n #print i\n os.remove(i)\n except: \n pass \n #all this was to handle \"saving files in trash, but doesn't fly on NT\n #d,f=os.path.split(i)\n #trash_file = os.path.join(trash,f)\n #print 'tf:',trash_file\n #if os.path.exists(trash_file):\n # os.remove(trash_file)\n # print trash_file\n #os.renames(i,trash_file)\n\ndef setup_test_location():\n import tempfile\n pth = os.path.join(tempfile.gettempdir(),'test_files')\n if not os.path.exists(pth):\n os.mkdir(pth)\n #sys.path.insert(0,pth) \n return pth\n\ndef teardown_test_location():\n pass\n #import tempfile \n #pth = os.path.join(tempfile.gettempdir(),'test_files')\n #if sys.path[0] == pth:\n # sys.path = sys.path[1:]\n #return pth\n\ndef test_suite():\n suites = []\n suites.append( unittest.makeSuite(test_ast_to_blitz_expr,'check_') )\n suites.append( unittest.makeSuite(test_blitz,'check_') ) \n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\nif __name__ == \"__main__\":\n test()\n", "methods": [ { "name": "generic_test", "long_name": "generic_test( self , expr , desired )", "filename": "test_blitz_tools.py", "nloc": 8, "complexity": 1, "token_count": 54, "parameters": [ "self", "expr", "desired" ], "start_line": 27, "end_line": 34, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "check_simple_expr", "long_name": "check_simple_expr( self )", "filename": "test_blitz_tools.py", "nloc": 5, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 36, "end_line": 44, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "check_fdtd_expr", "long_name": "check_fdtd_expr( self )", "filename": "test_blitz_tools.py", "nloc": 14, "complexity": 1, "token_count": 40, "parameters": [ "self" ], "start_line": 46, "end_line": 66, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 21, "top_nesting_level": 1 }, { "name": "generic_test", "long_name": "generic_test( self , expr , arg_dict , type , size )", "filename": "test_blitz_tools.py", "nloc": 30, "complexity": 2, "token_count": 236, "parameters": [ "self", "expr", "arg_dict", "type", "size" ], "start_line": 73, "end_line": 105, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 33, "top_nesting_level": 1 }, { "name": "generic_2d", "long_name": "generic_2d( self , expr )", "filename": "test_blitz_tools.py", "nloc": 31, "complexity": 7, "token_count": 240, "parameters": [ "self", "expr" ], "start_line": 107, "end_line": 141, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 35, "top_nesting_level": 1 }, { "name": "check_5point_avg_2d", "long_name": "check_5point_avg_2d( self )", "filename": "test_blitz_tools.py", "nloc": 4, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 146, "end_line": 152, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "setUp", "long_name": "setUp( self )", "filename": "test_blitz_tools.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 154, "end_line": 160, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "tearDown", "long_name": "tearDown( self )", "filename": "test_blitz_tools.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 161, "end_line": 170, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "remove_test_files", "long_name": "remove_test_files( )", "filename": "test_blitz_tools.py", "nloc": 16, "complexity": 3, "token_count": 165, "parameters": [], "start_line": 172, "end_line": 188, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 0 }, { "name": "setup_test_location", "long_name": "setup_test_location( )", "filename": "test_blitz_tools.py", "nloc": 6, "complexity": 2, "token_count": 41, "parameters": [], "start_line": 198, "end_line": 204, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "teardown_test_location", "long_name": "teardown_test_location( )", "filename": "test_blitz_tools.py", "nloc": 2, "complexity": 1, "token_count": 5, "parameters": [], "start_line": 206, "end_line": 207, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_blitz_tools.py", "nloc": 6, "complexity": 1, "token_count": 44, "parameters": [], "start_line": 214, "end_line": 219, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_blitz_tools.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 221, "end_line": 225, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "methods_before": [ { "name": "generic_test", "long_name": "generic_test( self , expr , desired )", "filename": "test_blitz_tools.py", "nloc": 8, "complexity": 1, "token_count": 54, "parameters": [ "self", "expr", "desired" ], "start_line": 23, "end_line": 30, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "check_simple_expr", "long_name": "check_simple_expr( self )", "filename": "test_blitz_tools.py", "nloc": 5, "complexity": 1, "token_count": 22, "parameters": [ "self" ], "start_line": 32, "end_line": 40, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 1 }, { "name": "check_fdtd_expr", "long_name": "check_fdtd_expr( self )", "filename": "test_blitz_tools.py", "nloc": 14, "complexity": 1, "token_count": 40, "parameters": [ "self" ], "start_line": 42, "end_line": 62, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 21, "top_nesting_level": 1 }, { "name": "generic_test", "long_name": "generic_test( self , expr , arg_dict , type , size )", "filename": "test_blitz_tools.py", "nloc": 30, "complexity": 2, "token_count": 236, "parameters": [ "self", "expr", "arg_dict", "type", "size" ], "start_line": 69, "end_line": 101, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 33, "top_nesting_level": 1 }, { "name": "generic_2d", "long_name": "generic_2d( self , expr )", "filename": "test_blitz_tools.py", "nloc": 31, "complexity": 7, "token_count": 240, "parameters": [ "self", "expr" ], "start_line": 103, "end_line": 137, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 35, "top_nesting_level": 1 }, { "name": "check_5point_avg_2d", "long_name": "check_5point_avg_2d( self )", "filename": "test_blitz_tools.py", "nloc": 4, "complexity": 1, "token_count": 17, "parameters": [ "self" ], "start_line": 142, "end_line": 148, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "setUp", "long_name": "setUp( self )", "filename": "test_blitz_tools.py", "nloc": 2, "complexity": 1, "token_count": 6, "parameters": [ "self" ], "start_line": 150, "end_line": 156, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "tearDown", "long_name": "tearDown( self )", "filename": "test_blitz_tools.py", "nloc": 2, "complexity": 1, "token_count": 8, "parameters": [ "self" ], "start_line": 157, "end_line": 166, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "remove_test_files", "long_name": "remove_test_files( )", "filename": "test_blitz_tools.py", "nloc": 16, "complexity": 3, "token_count": 165, "parameters": [], "start_line": 168, "end_line": 184, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 0 }, { "name": "setup_test_location", "long_name": "setup_test_location( )", "filename": "test_blitz_tools.py", "nloc": 6, "complexity": 2, "token_count": 41, "parameters": [], "start_line": 194, "end_line": 200, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "teardown_test_location", "long_name": "teardown_test_location( )", "filename": "test_blitz_tools.py", "nloc": 2, "complexity": 1, "token_count": 5, "parameters": [], "start_line": 202, "end_line": 203, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_blitz_tools.py", "nloc": 6, "complexity": 1, "token_count": 44, "parameters": [], "start_line": 210, "end_line": 215, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_blitz_tools.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 217, "end_line": 221, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "changed_methods": [], "nloc": 158, "complexity": 23, "token_count": 1001, "diff_parsed": { "added": [ "# The following try/except so that non-SciPy users can still use blitz", "try:", " from fastumath import *", "except:", " pass # fastumath not available" ], "deleted": [ "from fastumath import *" ] } }, { "old_path": "weave/tests/test_size_check.py", "new_path": "weave/tests/test_size_check.py", "filename": "test_size_check.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -1,6 +1,10 @@\n import unittest, os\n from Numeric import *\n-from fastumath import *\n+# The following try/except so that non-SciPy users can still use blitz\n+try:\n+ from fastumath import *\n+except:\n+ pass # fastumath not available \n \n from scipy_distutils.misc_util import add_grandparent_to_path, restore_path\n \n", "added_lines": 5, "deleted_lines": 1, "source_code": "import unittest, os\nfrom Numeric import *\n# The following try/except so that non-SciPy users can still use blitz\ntry:\n from fastumath import *\nexcept:\n pass # fastumath not available \n\nfrom scipy_distutils.misc_util import add_grandparent_to_path, restore_path\n\nadd_grandparent_to_path(__name__)\nimport size_check\nfrom ast_tools import *\nrestore_path()\n\nempty = array(())\n \ndef array_assert_equal(test_string,actual,desired):\n \"\"\"this should probably be in scipy.scipy_test\n \"\"\"\n import pprint \n try:\n assert(alltrue(equal(actual,desired)))\n except AssertionError:\n try:\n # kluge for bug in Numeric\n assert (len(actual[0]) == len(actual[1]) == \n len(desired[0]) == len(desired[1]) == 0)\n except: \n import cStringIO\n msg = cStringIO.StringIO()\n msg.write(test_string)\n msg.write(' failed\\nACTUAL: \\n')\n pprint.pprint(actual,msg)\n msg.write('DESIRED: \\n')\n pprint.pprint(desired,msg)\n raise AssertionError, msg.getvalue()\n\nclass test_make_same_length(unittest.TestCase):\n\n def generic_test(self,x,y,desired):\n actual = size_check.make_same_length(x,y)\n desired = desired\n array_assert_equal('',actual,desired)\n\n def check_scalar(self):\n x,y = (),()\n desired = empty,empty \n self.generic_test(x,y,desired)\n def check_x_scalar(self):\n x,y = (),(1,2)\n desired = array((1,1)),array((1,2))\n self.generic_test(x,y,desired)\n def check_y_scalar(self):\n x,y = (1,2),()\n desired = array((1,2)),array((1,1))\n self.generic_test(x,y,desired)\n def check_x_short(self):\n x,y = (1,2),(1,2,3)\n desired = array((1,1,2)),array((1,2,3))\n self.generic_test(x,y,desired)\n def check_y_short(self):\n x,y = (1,2,3),(1,2)\n desired = array((1,2,3)),array((1,1,2))\n self.generic_test(x,y,desired)\n\nclass test_binary_op_size(unittest.TestCase):\n def generic_test(self,x,y,desired):\n actual = size_check.binary_op_size(x,y)\n desired = desired\n array_assert_equal('',actual,desired)\n def generic_error_test(self,x,y):\n try:\n actual = size_check.binary_op_size(x,y)\n #print actual\n raise AttributeError, \"Should have raised ValueError\"\n except ValueError:\n pass \n def desired_type(self,val):\n return array(val) \n def check_scalar(self):\n x,y = (),()\n desired = self.desired_type(())\n self.generic_test(x,y,desired)\n def check_x1(self):\n x,y = (1,),()\n desired = self.desired_type((1,))\n self.generic_test(x,y,desired)\n def check_y1(self):\n x,y = (),(1,)\n desired = self.desired_type((1,))\n self.generic_test(x,y,desired)\n def check_x_y(self):\n x,y = (5,),(5,)\n desired = self.desired_type((5,))\n self.generic_test(x,y,desired)\n def check_x_y2(self):\n x,y = (5,10),(5,10)\n desired = self.desired_type((5,10))\n self.generic_test(x,y,desired)\n def check_x_y3(self):\n x,y = (5,10),(1,10)\n desired = self.desired_type((5,10))\n self.generic_test(x,y,desired)\n def check_x_y4(self):\n x,y = (1,10),(5,10)\n desired = self.desired_type((5,10))\n self.generic_test(x,y,desired)\n def check_x_y5(self):\n x,y = (5,1),(1,10)\n desired = self.desired_type((5,10))\n self.generic_test(x,y,desired)\n def check_x_y6(self):\n x,y = (1,10),(5,1)\n desired = self.desired_type((5,10))\n self.generic_test(x,y,desired)\n def check_x_y7(self):\n x,y = (5,4,3,2,1),(3,2,1)\n desired = self.desired_type((5,4,3,2,1))\n self.generic_test(x,y,desired)\n \n def check_error1(self):\n x,y = (5,),(4,)\n self.generic_error_test(x,y)\n def check_error2(self):\n x,y = (5,5),(4,5)\n self.generic_error_test(x,y)\n\nclass test_dummy_array(test_binary_op_size):\n def array_assert_equal(self,test_string,actual,desired):\n \"\"\"this should probably be in scipy.scipy_test\n \"\"\"\n import pprint \n try:\n assert(actual == desired)\n except AssertionError:\n import cStringIO\n msg = cStringIO.StringIO()\n msg.write(test_string)\n msg.write(' failed\\nACTUAL: \\n')\n pprint.pprint(actual,msg)\n msg.write('DESIRED: \\n')\n pprint.pprint(desired,msg)\n raise AssertionError, msg.getvalue() \n def generic_test(self,x,y,desired):\n if type(x) is type(()):\n x = ones(x)\n if type(y) is type(()):\n y = ones(y)\n xx = size_check.dummy_array(x)\n yy = size_check.dummy_array(y)\n ops = ['+', '-', '/', '*', '<<', '>>']\n for op in ops:\n actual = eval('xx' + op + 'yy')\n desired = desired\n self.array_assert_equal('',actual,desired)\n def generic_error_test(self,x,y):\n try:\n self.generic_test('',x,y)\n raise AttributeError, \"Should have raised ValueError\"\n except ValueError:\n pass \n def desired_type(self,val):\n return size_check.dummy_array(array(val),1)\n\nclass test_dummy_array_indexing(unittest.TestCase):\n def array_assert_equal(self,test_string,actual,desired):\n \"\"\"this should probably be in scipy.scipy_test\n \"\"\"\n import pprint \n try:\n assert(alltrue(equal(actual,desired))) \n except AssertionError:\n import cStringIO\n msg = cStringIO.StringIO()\n msg.write(test_string)\n msg.write(' failed\\nACTUAL: \\n')\n pprint.pprint(actual,msg)\n msg.write('DESIRED: \\n')\n pprint.pprint(desired,msg)\n raise AssertionError, msg.getvalue()\n def generic_test(self,ary,expr,desired):\n a = size_check.dummy_array(ary)\n actual = eval(expr).shape \n #print desired, actual\n self.array_assert_equal(expr,actual,desired)\n def generic_wrap(self,a,expr):\n #print expr ,eval(expr)\n desired = array(eval(expr).shape)\n try:\n self.generic_test(a,expr,desired)\n except IndexError:\n if 0 not in desired:\n msg = '%s raised IndexError in dummy_array, but forms\\n' \\\n 'valid array shape -> %s' % (expr, str(desired))\n raise AttributeError, msg \n def generic_1d(self,expr):\n a = arange(10)\n self.generic_wrap(a,expr)\n def generic_2d(self,expr):\n a = ones((10,20))\n self.generic_wrap(a,expr)\n def generic_3d(self,expr):\n a = ones((10,20,1))\n self.generic_wrap(a,expr)\n \n def generic_1d_index(self,expr):\n a = arange(10)\n #print expr ,eval(expr)\n desired = array(())\n self.generic_test(a,expr,desired)\n def check_1d_index_0(self):\n self.generic_1d_index('a[0]')\n def check_1d_index_1(self):\n self.generic_1d_index('a[4]')\n def check_1d_index_2(self):\n self.generic_1d_index('a[-4]')\n def check_1d_index_3(self):\n try: self.generic_1d('a[12]')\n except IndexError: pass \n def check_1d_index_calculated(self):\n self.generic_1d_index('a[0+1]')\n def check_1d_0(self):\n self.generic_1d('a[:]')\n def check_1d_1(self): \n self.generic_1d('a[1:]')\n def check_1d_2(self): \n self.generic_1d('a[-1:]')\n def check_1d_3(self):\n # dummy_array is \"bug for bug\" equiv to Numeric.array\n # on wrapping of indices.\n self.generic_1d('a[-11:]')\n def check_1d_4(self): \n self.generic_1d('a[:1]')\n def check_1d_5(self): \n self.generic_1d('a[:-1]')\n def check_1d_6(self): \n self.generic_1d('a[:-11]')\n def check_1d_7(self): \n self.generic_1d('a[1:5]')\n def check_1d_8(self): \n self.generic_1d('a[1:-5]')\n def check_1d_9(self):\n # don't support zero length slicing at the moment.\n try: self.generic_1d('a[-1:-5]')\n except IndexError: pass \n def check_1d_10(self): \n self.generic_1d('a[-5:-1]')\n \n def check_1d_stride_0(self): \n self.generic_1d('a[::1]') \n def check_1d_stride_1(self): \n self.generic_1d('a[::-1]') \n def check_1d_stride_2(self): \n self.generic_1d('a[1::1]') \n def check_1d_stride_3(self): \n self.generic_1d('a[1::-1]') \n def check_1d_stride_4(self): \n # don't support zero length slicing at the moment.\n try: self.generic_1d('a[1:5:-1]') \n except IndexError: pass \n def check_1d_stride_5(self): \n self.generic_1d('a[5:1:-1]') \n def check_1d_stride_6(self): \n self.generic_1d('a[:4:1]') \n def check_1d_stride_7(self): \n self.generic_1d('a[:4:-1]') \n def check_1d_stride_8(self): \n self.generic_1d('a[:-4:1]') \n def check_1d_stride_9(self): \n self.generic_1d('a[:-4:-1]') \n def check_1d_stride_10(self): \n self.generic_1d('a[:-3:2]') \n def check_1d_stride_11(self): \n self.generic_1d('a[:-3:-2]') \n def check_1d_stride_12(self): \n self.generic_1d('a[:-3:-7]') \n def check_1d_random(self):\n \"\"\" through a bunch of different indexes at it for good measure.\n \"\"\"\n import whrandom\n choices = map(lambda x: `x`,range(50)) + range(50) + ['']*50\n for i in range(100):\n try:\n beg = whrandom.choice(choices)\n end = whrandom.choice(choices)\n step = whrandom.choice(choices) \n self.generic_1d('a[%s:%s:%s]' %(beg,end,step)) \n except IndexError:\n pass\n\n def check_2d_0(self):\n self.generic_2d('a[:]')\n def check_2d_1(self):\n self.generic_2d('a[:2]')\n def check_2d_2(self):\n self.generic_2d('a[:,:]')\n def check_2d_random(self):\n \"\"\" through a bunch of different indexes at it for good measure.\n \"\"\"\n import whrandom\n choices = map(lambda x: `x`,range(50)) + range(50) + ['']*50 \n for i in range(100):\n try:\n beg = whrandom.choice(choices)\n end = whrandom.choice(choices)\n step = whrandom.choice(choices) \n beg2 = whrandom.choice(choices)\n end2 = whrandom.choice(choices)\n step2 = whrandom.choice(choices) \n expr = 'a[%s:%s:%s,%s:%s:%s]' %(beg,end,step,beg2,end2,step2)\n self.generic_2d(expr) \n except IndexError:\n pass\n def check_3d_random(self):\n \"\"\" through a bunch of different indexes at it for good measure.\n \"\"\"\n import whrandom\n choices = map(lambda x: `x`,range(50)) + range(50) + ['']*50 \n for i in range(100):\n try:\n idx = []\n for i in range(9):\n idx.append(whrandom.choice(choices))\n expr = 'a[%s:%s:%s,%s:%s:%s,%s:%s:%s]' % tuple(idx)\n self.generic_3d(expr) \n except IndexError:\n pass\n\nclass test_reduction(unittest.TestCase):\n def check_1d_0(self):\n a = ones((5,))\n actual = size_check.reduction(a,0)\n desired = size_check.dummy_array((),1)\n array_assert_equal('',actual.shape,desired.shape) \n def check_2d_0(self):\n a = ones((5,10))\n actual = size_check.reduction(a,0)\n desired = size_check.dummy_array((10,),1)\n array_assert_equal('',actual.shape,desired.shape) \n def check_2d_1(self):\n a = ones((5,10))\n actual = size_check.reduction(a,1)\n desired = size_check.dummy_array((5,),1)\n array_assert_equal('',actual.shape,desired.shape) \n def check_3d_0(self):\n a = ones((5,6,7))\n actual = size_check.reduction(a,1)\n desired = size_check.dummy_array((5,7),1)\n array_assert_equal('',actual.shape,desired.shape) \n def check_error0(self):\n a = ones((5,))\n try:\n actual = size_check.reduction(a,-2)\n except ValueError:\n pass \n def check_error1(self):\n a = ones((5,))\n try:\n actual = size_check.reduction(a,1)\n except ValueError:\n pass \n\nclass test_expressions(unittest.TestCase): \n def array_assert_equal(self,test_string,actual,desired):\n \"\"\"this should probably be in scipy.scipy_test\n \"\"\"\n import pprint \n try:\n assert(alltrue(equal(actual,desired))) \n except AssertionError:\n import cStringIO\n msg = cStringIO.StringIO()\n msg.write(test_string)\n msg.write(' failed\\nACTUAL: \\n')\n pprint.pprint(actual,msg)\n msg.write('DESIRED: \\n')\n pprint.pprint(desired,msg)\n raise AssertionError, msg.getvalue()\n def generic_test(self,expr,desired,**kw):\n import parser\n ast_list = parser.expr(expr).tolist()\n args = harvest_variables(ast_list)\n loc = locals().update(kw)\n for var in args:\n s='%s = size_check.dummy_array(%s)'% (var,var)\n exec(s,loc)\n try: \n actual = eval(expr,locals()).shape \n except:\n actual = 'failed' \n if actual is 'failed' and desired is 'failed':\n return\n try: \n self.array_assert_equal(expr,actual,desired)\n except:\n print 'EXPR:',expr\n print 'ACTUAL:',actual\n print 'DEISRED:',desired\n def generic_wrap(self,expr,**kw):\n try:\n x = array(eval(expr,kw))\n try:\n desired = x.shape\n except:\n desired = zeros(())\n except:\n desired = 'failed'\n self.generic_test(expr,desired,**kw)\n def check_generic_1d(self):\n a = arange(10) \n expr = 'a[:]' \n self.generic_wrap(expr,a=a)\n expr = 'a[:] + a' \n self.generic_wrap(expr,a=a)\n bad_expr = 'a[4:] + a' \n self.generic_wrap(bad_expr,a=a)\n a = arange(10) \n b = ones((1,10))\n expr = 'a + b' \n self.generic_wrap(expr,a=a,b=b)\n bad_expr = 'a[:5] + b' \n self.generic_wrap(bad_expr,a=a,b=b)\n def check_single_index(self): \n a = arange(10) \n expr = 'a[5] + a[3]' \n self.generic_wrap(expr,a=a)\n \n def check_calculated_index(self): \n a = arange(10) \n nx = 0\n expr = 'a[5] + a[nx+3]' \n size_check.check_expr(expr,locals())\n def check_calculated_index2(self): \n a = arange(10) \n nx = 0\n expr = 'a[1:5] + a[nx+1:5+nx]' \n size_check.check_expr(expr,locals())\n def generic_2d(self,expr):\n a = ones((10,20))\n self.generic_wrap(a,expr)\n def generic_3d(self,expr):\n a = ones((10,20,1))\n self.generic_wrap(a,expr)\n \ndef test_suite():\n suites = []\n suites.append( unittest.makeSuite(test_make_same_length,'check_') )\n suites.append( unittest.makeSuite(test_binary_op_size,'check_') )\n suites.append( unittest.makeSuite(test_dummy_array,'check_') )\n suites.append( unittest.makeSuite(test_dummy_array_indexing,'check_') )\n suites.append( unittest.makeSuite(test_reduction,'check_') )\n suites.append( unittest.makeSuite(test_expressions,'check_') )\n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\nif __name__ == \"__main__\":\n test()\n", "source_code_before": "import unittest, os\nfrom Numeric import *\nfrom fastumath import *\n\nfrom scipy_distutils.misc_util import add_grandparent_to_path, restore_path\n\nadd_grandparent_to_path(__name__)\nimport size_check\nfrom ast_tools import *\nrestore_path()\n\nempty = array(())\n \ndef array_assert_equal(test_string,actual,desired):\n \"\"\"this should probably be in scipy.scipy_test\n \"\"\"\n import pprint \n try:\n assert(alltrue(equal(actual,desired)))\n except AssertionError:\n try:\n # kluge for bug in Numeric\n assert (len(actual[0]) == len(actual[1]) == \n len(desired[0]) == len(desired[1]) == 0)\n except: \n import cStringIO\n msg = cStringIO.StringIO()\n msg.write(test_string)\n msg.write(' failed\\nACTUAL: \\n')\n pprint.pprint(actual,msg)\n msg.write('DESIRED: \\n')\n pprint.pprint(desired,msg)\n raise AssertionError, msg.getvalue()\n\nclass test_make_same_length(unittest.TestCase):\n\n def generic_test(self,x,y,desired):\n actual = size_check.make_same_length(x,y)\n desired = desired\n array_assert_equal('',actual,desired)\n\n def check_scalar(self):\n x,y = (),()\n desired = empty,empty \n self.generic_test(x,y,desired)\n def check_x_scalar(self):\n x,y = (),(1,2)\n desired = array((1,1)),array((1,2))\n self.generic_test(x,y,desired)\n def check_y_scalar(self):\n x,y = (1,2),()\n desired = array((1,2)),array((1,1))\n self.generic_test(x,y,desired)\n def check_x_short(self):\n x,y = (1,2),(1,2,3)\n desired = array((1,1,2)),array((1,2,3))\n self.generic_test(x,y,desired)\n def check_y_short(self):\n x,y = (1,2,3),(1,2)\n desired = array((1,2,3)),array((1,1,2))\n self.generic_test(x,y,desired)\n\nclass test_binary_op_size(unittest.TestCase):\n def generic_test(self,x,y,desired):\n actual = size_check.binary_op_size(x,y)\n desired = desired\n array_assert_equal('',actual,desired)\n def generic_error_test(self,x,y):\n try:\n actual = size_check.binary_op_size(x,y)\n #print actual\n raise AttributeError, \"Should have raised ValueError\"\n except ValueError:\n pass \n def desired_type(self,val):\n return array(val) \n def check_scalar(self):\n x,y = (),()\n desired = self.desired_type(())\n self.generic_test(x,y,desired)\n def check_x1(self):\n x,y = (1,),()\n desired = self.desired_type((1,))\n self.generic_test(x,y,desired)\n def check_y1(self):\n x,y = (),(1,)\n desired = self.desired_type((1,))\n self.generic_test(x,y,desired)\n def check_x_y(self):\n x,y = (5,),(5,)\n desired = self.desired_type((5,))\n self.generic_test(x,y,desired)\n def check_x_y2(self):\n x,y = (5,10),(5,10)\n desired = self.desired_type((5,10))\n self.generic_test(x,y,desired)\n def check_x_y3(self):\n x,y = (5,10),(1,10)\n desired = self.desired_type((5,10))\n self.generic_test(x,y,desired)\n def check_x_y4(self):\n x,y = (1,10),(5,10)\n desired = self.desired_type((5,10))\n self.generic_test(x,y,desired)\n def check_x_y5(self):\n x,y = (5,1),(1,10)\n desired = self.desired_type((5,10))\n self.generic_test(x,y,desired)\n def check_x_y6(self):\n x,y = (1,10),(5,1)\n desired = self.desired_type((5,10))\n self.generic_test(x,y,desired)\n def check_x_y7(self):\n x,y = (5,4,3,2,1),(3,2,1)\n desired = self.desired_type((5,4,3,2,1))\n self.generic_test(x,y,desired)\n \n def check_error1(self):\n x,y = (5,),(4,)\n self.generic_error_test(x,y)\n def check_error2(self):\n x,y = (5,5),(4,5)\n self.generic_error_test(x,y)\n\nclass test_dummy_array(test_binary_op_size):\n def array_assert_equal(self,test_string,actual,desired):\n \"\"\"this should probably be in scipy.scipy_test\n \"\"\"\n import pprint \n try:\n assert(actual == desired)\n except AssertionError:\n import cStringIO\n msg = cStringIO.StringIO()\n msg.write(test_string)\n msg.write(' failed\\nACTUAL: \\n')\n pprint.pprint(actual,msg)\n msg.write('DESIRED: \\n')\n pprint.pprint(desired,msg)\n raise AssertionError, msg.getvalue() \n def generic_test(self,x,y,desired):\n if type(x) is type(()):\n x = ones(x)\n if type(y) is type(()):\n y = ones(y)\n xx = size_check.dummy_array(x)\n yy = size_check.dummy_array(y)\n ops = ['+', '-', '/', '*', '<<', '>>']\n for op in ops:\n actual = eval('xx' + op + 'yy')\n desired = desired\n self.array_assert_equal('',actual,desired)\n def generic_error_test(self,x,y):\n try:\n self.generic_test('',x,y)\n raise AttributeError, \"Should have raised ValueError\"\n except ValueError:\n pass \n def desired_type(self,val):\n return size_check.dummy_array(array(val),1)\n\nclass test_dummy_array_indexing(unittest.TestCase):\n def array_assert_equal(self,test_string,actual,desired):\n \"\"\"this should probably be in scipy.scipy_test\n \"\"\"\n import pprint \n try:\n assert(alltrue(equal(actual,desired))) \n except AssertionError:\n import cStringIO\n msg = cStringIO.StringIO()\n msg.write(test_string)\n msg.write(' failed\\nACTUAL: \\n')\n pprint.pprint(actual,msg)\n msg.write('DESIRED: \\n')\n pprint.pprint(desired,msg)\n raise AssertionError, msg.getvalue()\n def generic_test(self,ary,expr,desired):\n a = size_check.dummy_array(ary)\n actual = eval(expr).shape \n #print desired, actual\n self.array_assert_equal(expr,actual,desired)\n def generic_wrap(self,a,expr):\n #print expr ,eval(expr)\n desired = array(eval(expr).shape)\n try:\n self.generic_test(a,expr,desired)\n except IndexError:\n if 0 not in desired:\n msg = '%s raised IndexError in dummy_array, but forms\\n' \\\n 'valid array shape -> %s' % (expr, str(desired))\n raise AttributeError, msg \n def generic_1d(self,expr):\n a = arange(10)\n self.generic_wrap(a,expr)\n def generic_2d(self,expr):\n a = ones((10,20))\n self.generic_wrap(a,expr)\n def generic_3d(self,expr):\n a = ones((10,20,1))\n self.generic_wrap(a,expr)\n \n def generic_1d_index(self,expr):\n a = arange(10)\n #print expr ,eval(expr)\n desired = array(())\n self.generic_test(a,expr,desired)\n def check_1d_index_0(self):\n self.generic_1d_index('a[0]')\n def check_1d_index_1(self):\n self.generic_1d_index('a[4]')\n def check_1d_index_2(self):\n self.generic_1d_index('a[-4]')\n def check_1d_index_3(self):\n try: self.generic_1d('a[12]')\n except IndexError: pass \n def check_1d_index_calculated(self):\n self.generic_1d_index('a[0+1]')\n def check_1d_0(self):\n self.generic_1d('a[:]')\n def check_1d_1(self): \n self.generic_1d('a[1:]')\n def check_1d_2(self): \n self.generic_1d('a[-1:]')\n def check_1d_3(self):\n # dummy_array is \"bug for bug\" equiv to Numeric.array\n # on wrapping of indices.\n self.generic_1d('a[-11:]')\n def check_1d_4(self): \n self.generic_1d('a[:1]')\n def check_1d_5(self): \n self.generic_1d('a[:-1]')\n def check_1d_6(self): \n self.generic_1d('a[:-11]')\n def check_1d_7(self): \n self.generic_1d('a[1:5]')\n def check_1d_8(self): \n self.generic_1d('a[1:-5]')\n def check_1d_9(self):\n # don't support zero length slicing at the moment.\n try: self.generic_1d('a[-1:-5]')\n except IndexError: pass \n def check_1d_10(self): \n self.generic_1d('a[-5:-1]')\n \n def check_1d_stride_0(self): \n self.generic_1d('a[::1]') \n def check_1d_stride_1(self): \n self.generic_1d('a[::-1]') \n def check_1d_stride_2(self): \n self.generic_1d('a[1::1]') \n def check_1d_stride_3(self): \n self.generic_1d('a[1::-1]') \n def check_1d_stride_4(self): \n # don't support zero length slicing at the moment.\n try: self.generic_1d('a[1:5:-1]') \n except IndexError: pass \n def check_1d_stride_5(self): \n self.generic_1d('a[5:1:-1]') \n def check_1d_stride_6(self): \n self.generic_1d('a[:4:1]') \n def check_1d_stride_7(self): \n self.generic_1d('a[:4:-1]') \n def check_1d_stride_8(self): \n self.generic_1d('a[:-4:1]') \n def check_1d_stride_9(self): \n self.generic_1d('a[:-4:-1]') \n def check_1d_stride_10(self): \n self.generic_1d('a[:-3:2]') \n def check_1d_stride_11(self): \n self.generic_1d('a[:-3:-2]') \n def check_1d_stride_12(self): \n self.generic_1d('a[:-3:-7]') \n def check_1d_random(self):\n \"\"\" through a bunch of different indexes at it for good measure.\n \"\"\"\n import whrandom\n choices = map(lambda x: `x`,range(50)) + range(50) + ['']*50\n for i in range(100):\n try:\n beg = whrandom.choice(choices)\n end = whrandom.choice(choices)\n step = whrandom.choice(choices) \n self.generic_1d('a[%s:%s:%s]' %(beg,end,step)) \n except IndexError:\n pass\n\n def check_2d_0(self):\n self.generic_2d('a[:]')\n def check_2d_1(self):\n self.generic_2d('a[:2]')\n def check_2d_2(self):\n self.generic_2d('a[:,:]')\n def check_2d_random(self):\n \"\"\" through a bunch of different indexes at it for good measure.\n \"\"\"\n import whrandom\n choices = map(lambda x: `x`,range(50)) + range(50) + ['']*50 \n for i in range(100):\n try:\n beg = whrandom.choice(choices)\n end = whrandom.choice(choices)\n step = whrandom.choice(choices) \n beg2 = whrandom.choice(choices)\n end2 = whrandom.choice(choices)\n step2 = whrandom.choice(choices) \n expr = 'a[%s:%s:%s,%s:%s:%s]' %(beg,end,step,beg2,end2,step2)\n self.generic_2d(expr) \n except IndexError:\n pass\n def check_3d_random(self):\n \"\"\" through a bunch of different indexes at it for good measure.\n \"\"\"\n import whrandom\n choices = map(lambda x: `x`,range(50)) + range(50) + ['']*50 \n for i in range(100):\n try:\n idx = []\n for i in range(9):\n idx.append(whrandom.choice(choices))\n expr = 'a[%s:%s:%s,%s:%s:%s,%s:%s:%s]' % tuple(idx)\n self.generic_3d(expr) \n except IndexError:\n pass\n\nclass test_reduction(unittest.TestCase):\n def check_1d_0(self):\n a = ones((5,))\n actual = size_check.reduction(a,0)\n desired = size_check.dummy_array((),1)\n array_assert_equal('',actual.shape,desired.shape) \n def check_2d_0(self):\n a = ones((5,10))\n actual = size_check.reduction(a,0)\n desired = size_check.dummy_array((10,),1)\n array_assert_equal('',actual.shape,desired.shape) \n def check_2d_1(self):\n a = ones((5,10))\n actual = size_check.reduction(a,1)\n desired = size_check.dummy_array((5,),1)\n array_assert_equal('',actual.shape,desired.shape) \n def check_3d_0(self):\n a = ones((5,6,7))\n actual = size_check.reduction(a,1)\n desired = size_check.dummy_array((5,7),1)\n array_assert_equal('',actual.shape,desired.shape) \n def check_error0(self):\n a = ones((5,))\n try:\n actual = size_check.reduction(a,-2)\n except ValueError:\n pass \n def check_error1(self):\n a = ones((5,))\n try:\n actual = size_check.reduction(a,1)\n except ValueError:\n pass \n\nclass test_expressions(unittest.TestCase): \n def array_assert_equal(self,test_string,actual,desired):\n \"\"\"this should probably be in scipy.scipy_test\n \"\"\"\n import pprint \n try:\n assert(alltrue(equal(actual,desired))) \n except AssertionError:\n import cStringIO\n msg = cStringIO.StringIO()\n msg.write(test_string)\n msg.write(' failed\\nACTUAL: \\n')\n pprint.pprint(actual,msg)\n msg.write('DESIRED: \\n')\n pprint.pprint(desired,msg)\n raise AssertionError, msg.getvalue()\n def generic_test(self,expr,desired,**kw):\n import parser\n ast_list = parser.expr(expr).tolist()\n args = harvest_variables(ast_list)\n loc = locals().update(kw)\n for var in args:\n s='%s = size_check.dummy_array(%s)'% (var,var)\n exec(s,loc)\n try: \n actual = eval(expr,locals()).shape \n except:\n actual = 'failed' \n if actual is 'failed' and desired is 'failed':\n return\n try: \n self.array_assert_equal(expr,actual,desired)\n except:\n print 'EXPR:',expr\n print 'ACTUAL:',actual\n print 'DEISRED:',desired\n def generic_wrap(self,expr,**kw):\n try:\n x = array(eval(expr,kw))\n try:\n desired = x.shape\n except:\n desired = zeros(())\n except:\n desired = 'failed'\n self.generic_test(expr,desired,**kw)\n def check_generic_1d(self):\n a = arange(10) \n expr = 'a[:]' \n self.generic_wrap(expr,a=a)\n expr = 'a[:] + a' \n self.generic_wrap(expr,a=a)\n bad_expr = 'a[4:] + a' \n self.generic_wrap(bad_expr,a=a)\n a = arange(10) \n b = ones((1,10))\n expr = 'a + b' \n self.generic_wrap(expr,a=a,b=b)\n bad_expr = 'a[:5] + b' \n self.generic_wrap(bad_expr,a=a,b=b)\n def check_single_index(self): \n a = arange(10) \n expr = 'a[5] + a[3]' \n self.generic_wrap(expr,a=a)\n \n def check_calculated_index(self): \n a = arange(10) \n nx = 0\n expr = 'a[5] + a[nx+3]' \n size_check.check_expr(expr,locals())\n def check_calculated_index2(self): \n a = arange(10) \n nx = 0\n expr = 'a[1:5] + a[nx+1:5+nx]' \n size_check.check_expr(expr,locals())\n def generic_2d(self,expr):\n a = ones((10,20))\n self.generic_wrap(a,expr)\n def generic_3d(self,expr):\n a = ones((10,20,1))\n self.generic_wrap(a,expr)\n \ndef test_suite():\n suites = []\n suites.append( unittest.makeSuite(test_make_same_length,'check_') )\n suites.append( unittest.makeSuite(test_binary_op_size,'check_') )\n suites.append( unittest.makeSuite(test_dummy_array,'check_') )\n suites.append( unittest.makeSuite(test_dummy_array_indexing,'check_') )\n suites.append( unittest.makeSuite(test_reduction,'check_') )\n suites.append( unittest.makeSuite(test_expressions,'check_') )\n total_suite = unittest.TestSuite(suites)\n return total_suite\n\ndef test():\n all_tests = test_suite()\n runner = unittest.TextTestRunner()\n runner.run(all_tests)\n return runner\n\nif __name__ == \"__main__\":\n test()\n", "methods": [ { "name": "array_assert_equal", "long_name": "array_assert_equal( test_string , actual , desired )", "filename": "test_size_check.py", "nloc": 17, "complexity": 3, "token_count": 120, "parameters": [ "test_string", "actual", "desired" ], "start_line": 18, "end_line": 37, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 }, { "name": "generic_test", "long_name": "generic_test( self , x , y , desired )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 32, "parameters": [ "self", "x", "y", "desired" ], "start_line": 41, "end_line": 44, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_scalar", "long_name": "check_scalar( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 29, "parameters": [ "self" ], "start_line": 46, "end_line": 49, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_scalar", "long_name": "check_x_scalar( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 46, "parameters": [ "self" ], "start_line": 50, "end_line": 53, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_y_scalar", "long_name": "check_y_scalar( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 46, "parameters": [ "self" ], "start_line": 54, "end_line": 57, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_short", "long_name": "check_x_short( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 55, "parameters": [ "self" ], "start_line": 58, "end_line": 61, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_y_short", "long_name": "check_y_short( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 55, "parameters": [ "self" ], "start_line": 62, "end_line": 65, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "generic_test", "long_name": "generic_test( self , x , y , desired )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 32, "parameters": [ "self", "x", "y", "desired" ], "start_line": 68, "end_line": 71, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "generic_error_test", "long_name": "generic_error_test( self , x , y )", "filename": "test_size_check.py", "nloc": 6, "complexity": 2, "token_count": 29, "parameters": [ "self", "x", "y" ], "start_line": 72, "end_line": 78, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "desired_type", "long_name": "desired_type( self , val )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "self", "val" ], "start_line": 79, "end_line": 80, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_scalar", "long_name": "check_scalar( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 33, "parameters": [ "self" ], "start_line": 81, "end_line": 84, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x1", "long_name": "check_x1( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 37, "parameters": [ "self" ], "start_line": 85, "end_line": 88, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_y1", "long_name": "check_y1( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 37, "parameters": [ "self" ], "start_line": 89, "end_line": 92, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y", "long_name": "check_x_y( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 39, "parameters": [ "self" ], "start_line": 93, "end_line": 96, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y2", "long_name": "check_x_y2( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 42, "parameters": [ "self" ], "start_line": 97, "end_line": 100, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y3", "long_name": "check_x_y3( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 42, "parameters": [ "self" ], "start_line": 101, "end_line": 104, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y4", "long_name": "check_x_y4( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 42, "parameters": [ "self" ], "start_line": 105, "end_line": 108, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y5", "long_name": "check_x_y5( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 42, "parameters": [ "self" ], "start_line": 109, "end_line": 112, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y6", "long_name": "check_x_y6( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 42, "parameters": [ "self" ], "start_line": 113, "end_line": 116, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y7", "long_name": "check_x_y7( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 56, "parameters": [ "self" ], "start_line": 117, "end_line": 120, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_error1", "long_name": "check_error1( self )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 122, "end_line": 124, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_error2", "long_name": "check_error2( self )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 28, "parameters": [ "self" ], "start_line": 125, "end_line": 127, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "array_assert_equal", "long_name": "array_assert_equal( self , test_string , actual , desired )", "filename": "test_size_check.py", "nloc": 13, "complexity": 2, "token_count": 76, "parameters": [ "self", "test_string", "actual", "desired" ], "start_line": 130, "end_line": 144, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "generic_test", "long_name": "generic_test( self , x , y , desired )", "filename": "test_size_check.py", "nloc": 12, "complexity": 4, "token_count": 106, "parameters": [ "self", "x", "y", "desired" ], "start_line": 145, "end_line": 156, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 12, "top_nesting_level": 1 }, { "name": "generic_error_test", "long_name": "generic_error_test( self , x , y )", "filename": "test_size_check.py", "nloc": 6, "complexity": 2, "token_count": 29, "parameters": [ "self", "x", "y" ], "start_line": 157, "end_line": 162, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "desired_type", "long_name": "desired_type( self , val )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self", "val" ], "start_line": 163, "end_line": 164, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "array_assert_equal", "long_name": "array_assert_equal( self , test_string , actual , desired )", "filename": "test_size_check.py", "nloc": 13, "complexity": 2, "token_count": 82, "parameters": [ "self", "test_string", "actual", "desired" ], "start_line": 167, "end_line": 181, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "generic_test", "long_name": "generic_test( self , ary , expr , desired )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 37, "parameters": [ "self", "ary", "expr", "desired" ], "start_line": 182, "end_line": 186, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "generic_wrap", "long_name": "generic_wrap( self , a , expr )", "filename": "test_size_check.py", "nloc": 9, "complexity": 3, "token_count": 59, "parameters": [ "self", "a", "expr" ], "start_line": 187, "end_line": 196, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "generic_1d", "long_name": "generic_1d( self , expr )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 21, "parameters": [ "self", "expr" ], "start_line": 197, "end_line": 199, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "generic_2d", "long_name": "generic_2d( self , expr )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 25, "parameters": [ "self", "expr" ], "start_line": 200, "end_line": 202, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "generic_3d", "long_name": "generic_3d( self , expr )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 27, "parameters": [ "self", "expr" ], "start_line": 203, "end_line": 205, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "generic_1d_index", "long_name": "generic_1d_index( self , expr )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 30, "parameters": [ "self", "expr" ], "start_line": 207, "end_line": 211, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_1d_index_0", "long_name": "check_1d_index_0( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 212, "end_line": 213, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_index_1", "long_name": "check_1d_index_1( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 214, "end_line": 215, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_index_2", "long_name": "check_1d_index_2( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 216, "end_line": 217, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_index_3", "long_name": "check_1d_index_3( self )", "filename": "test_size_check.py", "nloc": 3, "complexity": 2, "token_count": 17, "parameters": [ "self" ], "start_line": 218, "end_line": 220, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_1d_index_calculated", "long_name": "check_1d_index_calculated( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 221, "end_line": 222, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_0", "long_name": "check_1d_0( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 223, "end_line": 224, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_1", "long_name": "check_1d_1( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 225, "end_line": 226, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_2", "long_name": "check_1d_2( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 227, "end_line": 228, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_3", "long_name": "check_1d_3( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 229, "end_line": 232, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_1d_4", "long_name": "check_1d_4( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 233, "end_line": 234, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_5", "long_name": "check_1d_5( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 235, "end_line": 236, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_6", "long_name": "check_1d_6( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 237, "end_line": 238, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_7", "long_name": "check_1d_7( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 239, "end_line": 240, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_8", "long_name": "check_1d_8( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 241, "end_line": 242, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_9", "long_name": "check_1d_9( self )", "filename": "test_size_check.py", "nloc": 3, "complexity": 2, "token_count": 17, "parameters": [ "self" ], "start_line": 243, "end_line": 246, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_1d_10", "long_name": "check_1d_10( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 247, "end_line": 248, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_0", "long_name": "check_1d_stride_0( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 250, "end_line": 251, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_1", "long_name": "check_1d_stride_1( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 252, "end_line": 253, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_2", "long_name": "check_1d_stride_2( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 254, "end_line": 255, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_3", "long_name": "check_1d_stride_3( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 256, "end_line": 257, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_4", "long_name": "check_1d_stride_4( self )", "filename": "test_size_check.py", "nloc": 3, "complexity": 2, "token_count": 17, "parameters": [ "self" ], "start_line": 258, "end_line": 261, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_1d_stride_5", "long_name": "check_1d_stride_5( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 262, "end_line": 263, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_6", "long_name": "check_1d_stride_6( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 264, "end_line": 265, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_7", "long_name": "check_1d_stride_7( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 266, "end_line": 267, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_8", "long_name": "check_1d_stride_8( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 268, "end_line": 269, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_9", "long_name": "check_1d_stride_9( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 270, "end_line": 271, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_10", "long_name": "check_1d_stride_10( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 272, "end_line": 273, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_11", "long_name": "check_1d_stride_11( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 274, "end_line": 275, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_12", "long_name": "check_1d_stride_12( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 276, "end_line": 277, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_random", "long_name": "check_1d_random( self )", "filename": "test_size_check.py", "nloc": 11, "complexity": 3, "token_count": 87, "parameters": [ "self" ], "start_line": 278, "end_line": 290, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "check_2d_0", "long_name": "check_2d_0( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 292, "end_line": 293, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_2d_1", "long_name": "check_2d_1( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 294, "end_line": 295, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_2d_2", "long_name": "check_2d_2( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 296, "end_line": 297, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_2d_random", "long_name": "check_2d_random( self )", "filename": "test_size_check.py", "nloc": 15, "complexity": 3, "token_count": 120, "parameters": [ "self" ], "start_line": 298, "end_line": 314, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 1 }, { "name": "check_3d_random", "long_name": "check_3d_random( self )", "filename": "test_size_check.py", "nloc": 12, "complexity": 4, "token_count": 86, "parameters": [ "self" ], "start_line": 315, "end_line": 328, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 1 }, { "name": "check_1d_0", "long_name": "check_1d_0( self )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 47, "parameters": [ "self" ], "start_line": 331, "end_line": 335, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_2d_0", "long_name": "check_2d_0( self )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 50, "parameters": [ "self" ], "start_line": 336, "end_line": 340, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_2d_1", "long_name": "check_2d_1( self )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 50, "parameters": [ "self" ], "start_line": 341, "end_line": 345, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_3d_0", "long_name": "check_3d_0( self )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 53, "parameters": [ "self" ], "start_line": 346, "end_line": 350, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_error0", "long_name": "check_error0( self )", "filename": "test_size_check.py", "nloc": 6, "complexity": 2, "token_count": 31, "parameters": [ "self" ], "start_line": 351, "end_line": 356, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "check_error1", "long_name": "check_error1( self )", "filename": "test_size_check.py", "nloc": 6, "complexity": 2, "token_count": 30, "parameters": [ "self" ], "start_line": 357, "end_line": 362, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "array_assert_equal", "long_name": "array_assert_equal( self , test_string , actual , desired )", "filename": "test_size_check.py", "nloc": 13, "complexity": 2, "token_count": 82, "parameters": [ "self", "test_string", "actual", "desired" ], "start_line": 365, "end_line": 379, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "generic_test", "long_name": "generic_test( self , expr , desired , ** kw )", "filename": "test_size_check.py", "nloc": 20, "complexity": 6, "token_count": 117, "parameters": [ "self", "expr", "desired", "kw" ], "start_line": 380, "end_line": 399, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 1 }, { "name": "generic_wrap", "long_name": "generic_wrap( self , expr , ** kw )", "filename": "test_size_check.py", "nloc": 10, "complexity": 3, "token_count": 55, "parameters": [ "self", "expr", "kw" ], "start_line": 400, "end_line": 409, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "check_generic_1d", "long_name": "check_generic_1d( self )", "filename": "test_size_check.py", "nloc": 14, "complexity": 1, "token_count": 100, "parameters": [ "self" ], "start_line": 410, "end_line": 423, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 1 }, { "name": "check_single_index", "long_name": "check_single_index( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 424, "end_line": 427, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_calculated_index", "long_name": "check_calculated_index( self )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 27, "parameters": [ "self" ], "start_line": 429, "end_line": 433, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_calculated_index2", "long_name": "check_calculated_index2( self )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 27, "parameters": [ "self" ], "start_line": 434, "end_line": 438, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "generic_2d", "long_name": "generic_2d( self , expr )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 25, "parameters": [ "self", "expr" ], "start_line": 439, "end_line": 441, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "generic_3d", "long_name": "generic_3d( self , expr )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 27, "parameters": [ "self", "expr" ], "start_line": 442, "end_line": 444, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_size_check.py", "nloc": 10, "complexity": 1, "token_count": 96, "parameters": [], "start_line": 446, "end_line": 455, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 457, "end_line": 461, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "methods_before": [ { "name": "array_assert_equal", "long_name": "array_assert_equal( test_string , actual , desired )", "filename": "test_size_check.py", "nloc": 17, "complexity": 3, "token_count": 120, "parameters": [ "test_string", "actual", "desired" ], "start_line": 14, "end_line": 33, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 0 }, { "name": "generic_test", "long_name": "generic_test( self , x , y , desired )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 32, "parameters": [ "self", "x", "y", "desired" ], "start_line": 37, "end_line": 40, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_scalar", "long_name": "check_scalar( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 29, "parameters": [ "self" ], "start_line": 42, "end_line": 45, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_scalar", "long_name": "check_x_scalar( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 46, "parameters": [ "self" ], "start_line": 46, "end_line": 49, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_y_scalar", "long_name": "check_y_scalar( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 46, "parameters": [ "self" ], "start_line": 50, "end_line": 53, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_short", "long_name": "check_x_short( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 55, "parameters": [ "self" ], "start_line": 54, "end_line": 57, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_y_short", "long_name": "check_y_short( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 55, "parameters": [ "self" ], "start_line": 58, "end_line": 61, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "generic_test", "long_name": "generic_test( self , x , y , desired )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 32, "parameters": [ "self", "x", "y", "desired" ], "start_line": 64, "end_line": 67, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "generic_error_test", "long_name": "generic_error_test( self , x , y )", "filename": "test_size_check.py", "nloc": 6, "complexity": 2, "token_count": 29, "parameters": [ "self", "x", "y" ], "start_line": 68, "end_line": 74, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "desired_type", "long_name": "desired_type( self , val )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "self", "val" ], "start_line": 75, "end_line": 76, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_scalar", "long_name": "check_scalar( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 33, "parameters": [ "self" ], "start_line": 77, "end_line": 80, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x1", "long_name": "check_x1( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 37, "parameters": [ "self" ], "start_line": 81, "end_line": 84, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_y1", "long_name": "check_y1( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 37, "parameters": [ "self" ], "start_line": 85, "end_line": 88, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y", "long_name": "check_x_y( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 39, "parameters": [ "self" ], "start_line": 89, "end_line": 92, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y2", "long_name": "check_x_y2( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 42, "parameters": [ "self" ], "start_line": 93, "end_line": 96, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y3", "long_name": "check_x_y3( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 42, "parameters": [ "self" ], "start_line": 97, "end_line": 100, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y4", "long_name": "check_x_y4( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 42, "parameters": [ "self" ], "start_line": 101, "end_line": 104, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y5", "long_name": "check_x_y5( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 42, "parameters": [ "self" ], "start_line": 105, "end_line": 108, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y6", "long_name": "check_x_y6( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 42, "parameters": [ "self" ], "start_line": 109, "end_line": 112, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_x_y7", "long_name": "check_x_y7( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 56, "parameters": [ "self" ], "start_line": 113, "end_line": 116, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_error1", "long_name": "check_error1( self )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 26, "parameters": [ "self" ], "start_line": 118, "end_line": 120, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_error2", "long_name": "check_error2( self )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 28, "parameters": [ "self" ], "start_line": 121, "end_line": 123, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "array_assert_equal", "long_name": "array_assert_equal( self , test_string , actual , desired )", "filename": "test_size_check.py", "nloc": 13, "complexity": 2, "token_count": 76, "parameters": [ "self", "test_string", "actual", "desired" ], "start_line": 126, "end_line": 140, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "generic_test", "long_name": "generic_test( self , x , y , desired )", "filename": "test_size_check.py", "nloc": 12, "complexity": 4, "token_count": 106, "parameters": [ "self", "x", "y", "desired" ], "start_line": 141, "end_line": 152, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 12, "top_nesting_level": 1 }, { "name": "generic_error_test", "long_name": "generic_error_test( self , x , y )", "filename": "test_size_check.py", "nloc": 6, "complexity": 2, "token_count": 29, "parameters": [ "self", "x", "y" ], "start_line": 153, "end_line": 158, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "desired_type", "long_name": "desired_type( self , val )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self", "val" ], "start_line": 159, "end_line": 160, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "array_assert_equal", "long_name": "array_assert_equal( self , test_string , actual , desired )", "filename": "test_size_check.py", "nloc": 13, "complexity": 2, "token_count": 82, "parameters": [ "self", "test_string", "actual", "desired" ], "start_line": 163, "end_line": 177, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "generic_test", "long_name": "generic_test( self , ary , expr , desired )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 37, "parameters": [ "self", "ary", "expr", "desired" ], "start_line": 178, "end_line": 182, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "generic_wrap", "long_name": "generic_wrap( self , a , expr )", "filename": "test_size_check.py", "nloc": 9, "complexity": 3, "token_count": 59, "parameters": [ "self", "a", "expr" ], "start_line": 183, "end_line": 192, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "generic_1d", "long_name": "generic_1d( self , expr )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 21, "parameters": [ "self", "expr" ], "start_line": 193, "end_line": 195, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "generic_2d", "long_name": "generic_2d( self , expr )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 25, "parameters": [ "self", "expr" ], "start_line": 196, "end_line": 198, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "generic_3d", "long_name": "generic_3d( self , expr )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 27, "parameters": [ "self", "expr" ], "start_line": 199, "end_line": 201, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "generic_1d_index", "long_name": "generic_1d_index( self , expr )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 30, "parameters": [ "self", "expr" ], "start_line": 203, "end_line": 207, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_1d_index_0", "long_name": "check_1d_index_0( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 208, "end_line": 209, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_index_1", "long_name": "check_1d_index_1( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 210, "end_line": 211, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_index_2", "long_name": "check_1d_index_2( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 212, "end_line": 213, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_index_3", "long_name": "check_1d_index_3( self )", "filename": "test_size_check.py", "nloc": 3, "complexity": 2, "token_count": 17, "parameters": [ "self" ], "start_line": 214, "end_line": 216, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "check_1d_index_calculated", "long_name": "check_1d_index_calculated( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 217, "end_line": 218, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_0", "long_name": "check_1d_0( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 219, "end_line": 220, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_1", "long_name": "check_1d_1( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 221, "end_line": 222, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_2", "long_name": "check_1d_2( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 223, "end_line": 224, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_3", "long_name": "check_1d_3( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 225, "end_line": 228, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_1d_4", "long_name": "check_1d_4( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 229, "end_line": 230, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_5", "long_name": "check_1d_5( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 231, "end_line": 232, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_6", "long_name": "check_1d_6( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 233, "end_line": 234, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_7", "long_name": "check_1d_7( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 235, "end_line": 236, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_8", "long_name": "check_1d_8( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 237, "end_line": 238, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_9", "long_name": "check_1d_9( self )", "filename": "test_size_check.py", "nloc": 3, "complexity": 2, "token_count": 17, "parameters": [ "self" ], "start_line": 239, "end_line": 242, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_1d_10", "long_name": "check_1d_10( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 243, "end_line": 244, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_0", "long_name": "check_1d_stride_0( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 246, "end_line": 247, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_1", "long_name": "check_1d_stride_1( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 248, "end_line": 249, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_2", "long_name": "check_1d_stride_2( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 250, "end_line": 251, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_3", "long_name": "check_1d_stride_3( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 252, "end_line": 253, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_4", "long_name": "check_1d_stride_4( self )", "filename": "test_size_check.py", "nloc": 3, "complexity": 2, "token_count": 17, "parameters": [ "self" ], "start_line": 254, "end_line": 257, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_1d_stride_5", "long_name": "check_1d_stride_5( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 258, "end_line": 259, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_6", "long_name": "check_1d_stride_6( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 260, "end_line": 261, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_7", "long_name": "check_1d_stride_7( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 262, "end_line": 263, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_8", "long_name": "check_1d_stride_8( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 264, "end_line": 265, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_9", "long_name": "check_1d_stride_9( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 266, "end_line": 267, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_10", "long_name": "check_1d_stride_10( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 268, "end_line": 269, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_11", "long_name": "check_1d_stride_11( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 270, "end_line": 271, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_stride_12", "long_name": "check_1d_stride_12( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 272, "end_line": 273, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_1d_random", "long_name": "check_1d_random( self )", "filename": "test_size_check.py", "nloc": 11, "complexity": 3, "token_count": 87, "parameters": [ "self" ], "start_line": 274, "end_line": 286, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "check_2d_0", "long_name": "check_2d_0( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 288, "end_line": 289, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_2d_1", "long_name": "check_2d_1( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 290, "end_line": 291, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_2d_2", "long_name": "check_2d_2( self )", "filename": "test_size_check.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 292, "end_line": 293, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "check_2d_random", "long_name": "check_2d_random( self )", "filename": "test_size_check.py", "nloc": 15, "complexity": 3, "token_count": 120, "parameters": [ "self" ], "start_line": 294, "end_line": 310, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 1 }, { "name": "check_3d_random", "long_name": "check_3d_random( self )", "filename": "test_size_check.py", "nloc": 12, "complexity": 4, "token_count": 86, "parameters": [ "self" ], "start_line": 311, "end_line": 324, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 1 }, { "name": "check_1d_0", "long_name": "check_1d_0( self )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 47, "parameters": [ "self" ], "start_line": 327, "end_line": 331, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_2d_0", "long_name": "check_2d_0( self )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 50, "parameters": [ "self" ], "start_line": 332, "end_line": 336, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_2d_1", "long_name": "check_2d_1( self )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 50, "parameters": [ "self" ], "start_line": 337, "end_line": 341, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_3d_0", "long_name": "check_3d_0( self )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 53, "parameters": [ "self" ], "start_line": 342, "end_line": 346, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_error0", "long_name": "check_error0( self )", "filename": "test_size_check.py", "nloc": 6, "complexity": 2, "token_count": 31, "parameters": [ "self" ], "start_line": 347, "end_line": 352, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "check_error1", "long_name": "check_error1( self )", "filename": "test_size_check.py", "nloc": 6, "complexity": 2, "token_count": 30, "parameters": [ "self" ], "start_line": 353, "end_line": 358, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "array_assert_equal", "long_name": "array_assert_equal( self , test_string , actual , desired )", "filename": "test_size_check.py", "nloc": 13, "complexity": 2, "token_count": 82, "parameters": [ "self", "test_string", "actual", "desired" ], "start_line": 361, "end_line": 375, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "generic_test", "long_name": "generic_test( self , expr , desired , ** kw )", "filename": "test_size_check.py", "nloc": 20, "complexity": 6, "token_count": 117, "parameters": [ "self", "expr", "desired", "kw" ], "start_line": 376, "end_line": 395, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 20, "top_nesting_level": 1 }, { "name": "generic_wrap", "long_name": "generic_wrap( self , expr , ** kw )", "filename": "test_size_check.py", "nloc": 10, "complexity": 3, "token_count": 55, "parameters": [ "self", "expr", "kw" ], "start_line": 396, "end_line": 405, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "check_generic_1d", "long_name": "check_generic_1d( self )", "filename": "test_size_check.py", "nloc": 14, "complexity": 1, "token_count": 100, "parameters": [ "self" ], "start_line": 406, "end_line": 419, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 1 }, { "name": "check_single_index", "long_name": "check_single_index( self )", "filename": "test_size_check.py", "nloc": 4, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 420, "end_line": 423, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "check_calculated_index", "long_name": "check_calculated_index( self )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 27, "parameters": [ "self" ], "start_line": 425, "end_line": 429, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "check_calculated_index2", "long_name": "check_calculated_index2( self )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 27, "parameters": [ "self" ], "start_line": 430, "end_line": 434, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 1 }, { "name": "generic_2d", "long_name": "generic_2d( self , expr )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 25, "parameters": [ "self", "expr" ], "start_line": 435, "end_line": 437, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "generic_3d", "long_name": "generic_3d( self , expr )", "filename": "test_size_check.py", "nloc": 3, "complexity": 1, "token_count": 27, "parameters": [ "self", "expr" ], "start_line": 438, "end_line": 440, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 1 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "test_size_check.py", "nloc": 10, "complexity": 1, "token_count": 96, "parameters": [], "start_line": 442, "end_line": 451, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "test_size_check.py", "nloc": 5, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 453, "end_line": 457, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 5, "top_nesting_level": 0 } ], "changed_methods": [], "nloc": 420, "complexity": 116, "token_count": 3145, "diff_parsed": { "added": [ "# The following try/except so that non-SciPy users can still use blitz", "try:", " from fastumath import *", "except:", " pass # fastumath not available" ], "deleted": [ "from fastumath import *" ] } } ] }, { "hash": "6d46146f04ab8ef404eefb093b2147b1d64a5d22", "msg": "converted DOS line endings to UNIX", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-06T02:46:54+00:00", "author_timezone": 0, "committer_date": "2002-01-06T02:46:54+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "9c3800541fde7929f892892af41b89efec29a186" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 221, "insertions": 0, "lines": 221, "files": 1, "dmm_unit_size": 0.0, "dmm_unit_complexity": 0.2912621359223301, "dmm_unit_interfacing": 0.14563106796116504, "modified_files": [ { "old_path": "weave/ast_tools.py", "new_path": "weave/ast_tools.py", "filename": "ast_tools.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -1,221 +0,0 @@\n-import token\n-import symbol\n-import parser\n-\n-from types import ListType, TupleType, StringType, IntType\n-\n-def int_to_symbol(i):\n- \"\"\" Convert numeric symbol or token to a desriptive name.\n- \"\"\"\n- try: \n- return symbol.sym_name[i]\n- except KeyError:\n- return token.tok_name[i]\n- \n-def translate_symbols(ast_tuple):\n- \"\"\" Translate numeric grammar symbols in an ast_tuple descriptive names.\n- \n- This simply traverses the tree converting any integer value to values\n- found in symbol.sym_name or token.tok_name.\n- \"\"\" \n- new_list = []\n- for item in ast_tuple:\n- if type(item) == IntType:\n- new_list.append(int_to_symbol(item))\n- elif type(item) in [TupleType,ListType]:\n- new_list.append(translate_symbols(item))\n- else: \n- new_list.append(item)\n- if type(ast_tuple) == TupleType:\n- return tuple(new_list)\n- else:\n- return new_list\n-\n-def ast_to_string(ast_seq):\n- \"\"\"* Traverse an ast tree sequence, printing out all leaf nodes.\n- \n- This effectively rebuilds the expression the tree was built\n- from. I guess its probably missing whitespace. How bout\n- indent stuff and new lines? Haven't checked this since we're\n- currently only dealing with simple expressions.\n- *\"\"\"\n- output = ''\n- for item in ast_seq:\n- if type(item) is StringType:\n- output = output + item\n- elif type(item) in [ListType,TupleType]:\n- output = output + ast_to_string(item)\n- return output \n-\n-def build_atom(expr_string):\n- \"\"\" Build an ast for an atom from the given expr string.\n- \n- If expr_string is not a string, it is converted to a string\n- before parsing to an ast_tuple.\n- \"\"\"\n- # the [1][1] indexing below starts atoms at the third level\n- # deep in the resulting parse tree. parser.expr will return\n- # a tree rooted with eval_input -> test_list -> test ...\n- # I'm considering test to be the root of atom symbols.\n- # It might be a better idea to move down a little in the\n- # parse tree. Any benefits? Right now, this works fine. \n- if type(expr_string) == StringType:\n- ast = parser.expr(expr_string).totuple()[1][1]\n- else:\n- ast = parser.expr(`expr_string`).totuple()[1][1]\n- return ast\n-\n-def atom_tuple(expr_string):\n- return build_atom(expr_string)\n-\n-def atom_list(expr_string):\n- return tuples_to_lists(build_atom(expr_string))\n- \n-def find_first_pattern(ast_tuple,pattern_list):\n- \"\"\"* Find the first occurence of a pattern one of a list of patterns \n- in ast_tuple.\n- \n- Used for testing at the moment.\n- \n- ast_tuple -- tuple or list created by ast.totuple() or ast.tolist().\n- pattern_list -- A single pattern or list of patterns to search\n- for in the ast_tuple. If a single pattern is \n- used, it MUST BE A IN A TUPLE format.\n- Returns:\n- found -- true/false indicating whether pattern was found\n- data -- dictionary of data from first matching pattern in tree.\n- (see match function by Jeremy Hylton). \n- *\"\"\"\n- found,data = 0,{}\n- \n- # convert to a list if input wasn't a list\n- if type(pattern_list) != ListType:\n- pattern_list = [pattern_list]\n-\n- # look for any of the patterns in a list of patterns \n- for pattern in pattern_list:\n- found,data = match(pattern,ast_tuple)\n- if found: \n- break \n- \n- # if we didn't find the pattern, search sub-trees of the parse tree\n- if not found: \n- for item in ast_tuple: \n- if type(item) in [TupleType,ListType]:\n- # only search sub items if they are a list or tuple.\n- found, data = find_first_pattern(item,pattern_list)\n- if found: \n- break \n- return found,data\n-\n-name_pattern = (token.NAME, ['var'])\n-\n-def remove_duplicates(lst):\n- output = []\n- for item in lst:\n- if item not in output:\n- output.append(item)\n- return output\n-\n-reserved_names = ['sin']\n-\n-def remove_reserved_names(lst):\n- \"\"\" These are functions names -- don't create variables for them\n- There is a more reobust approach, but this ought to work pretty\n- well.\n- \"\"\"\n- output = []\n- for item in lst:\n- if item not in reserved_names:\n- output.append(item)\n- return output\n-\n-def harvest_variables(ast_list): \n- \"\"\" Retreive all the variables that need to be defined.\n- \"\"\" \n- variables = []\n- if type(ast_list) in (ListType,TupleType):\n- found,data = match(name_pattern,ast_list)\n- if found:\n- variables.append(data['var'])\n- for item in ast_list:\n- if type(item) in (ListType,TupleType):\n- variables.extend(harvest_variables(item))\n- variables = remove_duplicates(variables) \n- variables = remove_reserved_names(variables) \n- return variables\n-\n-def match(pattern, data, vars=None):\n- \"\"\"Match `data' to `pattern', with variable extraction.\n-\n- pattern\n- Pattern to match against, possibly containing variables.\n-\n- data\n- Data to be checked and against which variables are extracted.\n-\n- vars\n- Dictionary of variables which have already been found. If not\n- provided, an empty dictionary is created.\n-\n- The `pattern' value may contain variables of the form ['varname'] which\n- are allowed to match anything. The value that is matched is returned as\n- part of a dictionary which maps 'varname' to the matched value. 'varname'\n- is not required to be a string object, but using strings makes patterns\n- and the code which uses them more readable.\n-\n- This function returns two values: a boolean indicating whether a match\n- was found and a dictionary mapping variable names to their associated\n- values.\n- \n- From the Demo/Parser/example.py file\n- \"\"\"\n- if vars is None:\n- vars = {}\n- if type(pattern) is ListType: # 'variables' are ['varname']\n- vars[pattern[0]] = data\n- return 1, vars\n- if type(pattern) is not TupleType:\n- return (pattern == data), vars\n- if len(data) != len(pattern):\n- return 0, vars\n- for pattern, data in map(None, pattern, data):\n- same, vars = match(pattern, data, vars)\n- if not same:\n- break\n- return same, vars\n-\n-\n-def tuples_to_lists(ast_tuple):\n- \"\"\" Convert an ast object tree in tuple form to list form.\n- \"\"\"\n- if type(ast_tuple) not in [ListType,TupleType]:\n- return ast_tuple\n- \n- new_list = []\n- for item in ast_tuple:\n- new_list.append(tuples_to_lists(item))\n- return new_list\n-\n-def test():\n- from scipy_test import module_test\n- module_test(__name__,__file__)\n-\n-def test_suite():\n- from scipy_test import module_test_suite\n- return module_test_suite(__name__,__file__) \n- \n-\"\"\"\n-A little tree I built to help me understand the parse trees.\n- -----------303------------------------------\n- | | \n- 304 -------------------------307-------------------------\n- | | | | | |\n- 1 'result' 9 '[' 308 12 ',' 308 10 ']'\n- | |\n- ---------309-------- -----309-------- \n- | | | | \n- 291|304 291|304 291|304 |\n- | | | |\n- 1 'a1' 11 ':' 1 'a2' 2 '10' 11 ':' \n-\"\"\"\n", "added_lines": 0, "deleted_lines": 221, "source_code": null, "source_code_before": "import token\nimport symbol\nimport parser\n\nfrom types import ListType, TupleType, StringType, IntType\n\ndef int_to_symbol(i):\n \"\"\" Convert numeric symbol or token to a desriptive name.\n \"\"\"\n try: \n return symbol.sym_name[i]\n except KeyError:\n return token.tok_name[i]\n \ndef translate_symbols(ast_tuple):\n \"\"\" Translate numeric grammar symbols in an ast_tuple descriptive names.\n \n This simply traverses the tree converting any integer value to values\n found in symbol.sym_name or token.tok_name.\n \"\"\" \n new_list = []\n for item in ast_tuple:\n if type(item) == IntType:\n new_list.append(int_to_symbol(item))\n elif type(item) in [TupleType,ListType]:\n new_list.append(translate_symbols(item))\n else: \n new_list.append(item)\n if type(ast_tuple) == TupleType:\n return tuple(new_list)\n else:\n return new_list\n\ndef ast_to_string(ast_seq):\n \"\"\"* Traverse an ast tree sequence, printing out all leaf nodes.\n \n This effectively rebuilds the expression the tree was built\n from. I guess its probably missing whitespace. How bout\n indent stuff and new lines? Haven't checked this since we're\n currently only dealing with simple expressions.\n *\"\"\"\n output = ''\n for item in ast_seq:\n if type(item) is StringType:\n output = output + item\n elif type(item) in [ListType,TupleType]:\n output = output + ast_to_string(item)\n return output \n\ndef build_atom(expr_string):\n \"\"\" Build an ast for an atom from the given expr string.\n \n If expr_string is not a string, it is converted to a string\n before parsing to an ast_tuple.\n \"\"\"\n # the [1][1] indexing below starts atoms at the third level\n # deep in the resulting parse tree. parser.expr will return\n # a tree rooted with eval_input -> test_list -> test ...\n # I'm considering test to be the root of atom symbols.\n # It might be a better idea to move down a little in the\n # parse tree. Any benefits? Right now, this works fine. \n if type(expr_string) == StringType:\n ast = parser.expr(expr_string).totuple()[1][1]\n else:\n ast = parser.expr(`expr_string`).totuple()[1][1]\n return ast\n\ndef atom_tuple(expr_string):\n return build_atom(expr_string)\n\ndef atom_list(expr_string):\n return tuples_to_lists(build_atom(expr_string))\n \ndef find_first_pattern(ast_tuple,pattern_list):\n \"\"\"* Find the first occurence of a pattern one of a list of patterns \n in ast_tuple.\n \n Used for testing at the moment.\n \n ast_tuple -- tuple or list created by ast.totuple() or ast.tolist().\n pattern_list -- A single pattern or list of patterns to search\n for in the ast_tuple. If a single pattern is \n used, it MUST BE A IN A TUPLE format.\n Returns:\n found -- true/false indicating whether pattern was found\n data -- dictionary of data from first matching pattern in tree.\n (see match function by Jeremy Hylton). \n *\"\"\"\n found,data = 0,{}\n \n # convert to a list if input wasn't a list\n if type(pattern_list) != ListType:\n pattern_list = [pattern_list]\n\n # look for any of the patterns in a list of patterns \n for pattern in pattern_list:\n found,data = match(pattern,ast_tuple)\n if found: \n break \n \n # if we didn't find the pattern, search sub-trees of the parse tree\n if not found: \n for item in ast_tuple: \n if type(item) in [TupleType,ListType]:\n # only search sub items if they are a list or tuple.\n found, data = find_first_pattern(item,pattern_list)\n if found: \n break \n return found,data\n\nname_pattern = (token.NAME, ['var'])\n\ndef remove_duplicates(lst):\n output = []\n for item in lst:\n if item not in output:\n output.append(item)\n return output\n\nreserved_names = ['sin']\n\ndef remove_reserved_names(lst):\n \"\"\" These are functions names -- don't create variables for them\n There is a more reobust approach, but this ought to work pretty\n well.\n \"\"\"\n output = []\n for item in lst:\n if item not in reserved_names:\n output.append(item)\n return output\n\ndef harvest_variables(ast_list): \n \"\"\" Retreive all the variables that need to be defined.\n \"\"\" \n variables = []\n if type(ast_list) in (ListType,TupleType):\n found,data = match(name_pattern,ast_list)\n if found:\n variables.append(data['var'])\n for item in ast_list:\n if type(item) in (ListType,TupleType):\n variables.extend(harvest_variables(item))\n variables = remove_duplicates(variables) \n variables = remove_reserved_names(variables) \n return variables\n\ndef match(pattern, data, vars=None):\n \"\"\"Match `data' to `pattern', with variable extraction.\n\n pattern\n Pattern to match against, possibly containing variables.\n\n data\n Data to be checked and against which variables are extracted.\n\n vars\n Dictionary of variables which have already been found. If not\n provided, an empty dictionary is created.\n\n The `pattern' value may contain variables of the form ['varname'] which\n are allowed to match anything. The value that is matched is returned as\n part of a dictionary which maps 'varname' to the matched value. 'varname'\n is not required to be a string object, but using strings makes patterns\n and the code which uses them more readable.\n\n This function returns two values: a boolean indicating whether a match\n was found and a dictionary mapping variable names to their associated\n values.\n \n From the Demo/Parser/example.py file\n \"\"\"\n if vars is None:\n vars = {}\n if type(pattern) is ListType: # 'variables' are ['varname']\n vars[pattern[0]] = data\n return 1, vars\n if type(pattern) is not TupleType:\n return (pattern == data), vars\n if len(data) != len(pattern):\n return 0, vars\n for pattern, data in map(None, pattern, data):\n same, vars = match(pattern, data, vars)\n if not same:\n break\n return same, vars\n\n\ndef tuples_to_lists(ast_tuple):\n \"\"\" Convert an ast object tree in tuple form to list form.\n \"\"\"\n if type(ast_tuple) not in [ListType,TupleType]:\n return ast_tuple\n \n new_list = []\n for item in ast_tuple:\n new_list.append(tuples_to_lists(item))\n return new_list\n\ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n \n\"\"\"\nA little tree I built to help me understand the parse trees.\n -----------303------------------------------\n | | \n 304 -------------------------307-------------------------\n | | | | | |\n 1 'result' 9 '[' 308 12 ',' 308 10 ']'\n | |\n ---------309-------- -----309-------- \n | | | | \n 291|304 291|304 291|304 |\n | | | |\n 1 'a1' 11 ':' 1 'a2' 2 '10' 11 ':' \n\"\"\"\n", "methods": [], "methods_before": [ { "name": "int_to_symbol", "long_name": "int_to_symbol( i )", "filename": "ast_tools.py", "nloc": 5, "complexity": 2, "token_count": 25, "parameters": [ "i" ], "start_line": 7, "end_line": 13, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "translate_symbols", "long_name": "translate_symbols( ast_tuple )", "filename": "ast_tools.py", "nloc": 13, "complexity": 5, "token_count": 78, "parameters": [ "ast_tuple" ], "start_line": 15, "end_line": 32, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 0 }, { "name": "ast_to_string", "long_name": "ast_to_string( ast_seq )", "filename": "ast_tools.py", "nloc": 8, "complexity": 4, "token_count": 49, "parameters": [ "ast_seq" ], "start_line": 34, "end_line": 48, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "build_atom", "long_name": "build_atom( expr_string )", "filename": "ast_tools.py", "nloc": 6, "complexity": 2, "token_count": 56, "parameters": [ "expr_string" ], "start_line": 50, "end_line": 66, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 0 }, { "name": "atom_tuple", "long_name": "atom_tuple( expr_string )", "filename": "ast_tools.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "expr_string" ], "start_line": 68, "end_line": 69, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "atom_list", "long_name": "atom_list( expr_string )", "filename": "ast_tools.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "expr_string" ], "start_line": 71, "end_line": 72, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "find_first_pattern", "long_name": "find_first_pattern( ast_tuple , pattern_list )", "filename": "ast_tools.py", "nloc": 15, "complexity": 8, "token_count": 87, "parameters": [ "ast_tuple", "pattern_list" ], "start_line": 74, "end_line": 109, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 36, "top_nesting_level": 0 }, { "name": "remove_duplicates", "long_name": "remove_duplicates( lst )", "filename": "ast_tools.py", "nloc": 6, "complexity": 3, "token_count": 28, "parameters": [ "lst" ], "start_line": 113, "end_line": 118, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 }, { "name": "remove_reserved_names", "long_name": "remove_reserved_names( lst )", "filename": "ast_tools.py", "nloc": 6, "complexity": 3, "token_count": 29, "parameters": [ "lst" ], "start_line": 122, "end_line": 131, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "harvest_variables", "long_name": "harvest_variables( ast_list )", "filename": "ast_tools.py", "nloc": 12, "complexity": 5, "token_count": 84, "parameters": [ "ast_list" ], "start_line": 133, "end_line": 146, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 0 }, { "name": "match", "long_name": "match( pattern , data , vars = None )", "filename": "ast_tools.py", "nloc": 15, "complexity": 7, "token_count": 109, "parameters": [ "pattern", "data", "vars" ], "start_line": 148, "end_line": 186, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 39, "top_nesting_level": 0 }, { "name": "tuples_to_lists", "long_name": "tuples_to_lists( ast_tuple )", "filename": "ast_tools.py", "nloc": 7, "complexity": 3, "token_count": 41, "parameters": [ "ast_tuple" ], "start_line": 189, "end_line": 198, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "ast_tools.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 200, "end_line": 202, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "ast_tools.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 204, "end_line": 206, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "translate_symbols", "long_name": "translate_symbols( ast_tuple )", "filename": "ast_tools.py", "nloc": 13, "complexity": 5, "token_count": 78, "parameters": [ "ast_tuple" ], "start_line": 15, "end_line": 32, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 0 }, { "name": "harvest_variables", "long_name": "harvest_variables( ast_list )", "filename": "ast_tools.py", "nloc": 12, "complexity": 5, "token_count": 84, "parameters": [ "ast_list" ], "start_line": 133, "end_line": 146, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 0 }, { "name": "atom_tuple", "long_name": "atom_tuple( expr_string )", "filename": "ast_tools.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "expr_string" ], "start_line": 68, "end_line": 69, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "int_to_symbol", "long_name": "int_to_symbol( i )", "filename": "ast_tools.py", "nloc": 5, "complexity": 2, "token_count": 25, "parameters": [ "i" ], "start_line": 7, "end_line": 13, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "tuples_to_lists", "long_name": "tuples_to_lists( ast_tuple )", "filename": "ast_tools.py", "nloc": 7, "complexity": 3, "token_count": 41, "parameters": [ "ast_tuple" ], "start_line": 189, "end_line": 198, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "atom_list", "long_name": "atom_list( expr_string )", "filename": "ast_tools.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "expr_string" ], "start_line": 71, "end_line": 72, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "match", "long_name": "match( pattern , data , vars = None )", "filename": "ast_tools.py", "nloc": 15, "complexity": 7, "token_count": 109, "parameters": [ "pattern", "data", "vars" ], "start_line": 148, "end_line": 186, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 39, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "ast_tools.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 200, "end_line": 202, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "build_atom", "long_name": "build_atom( expr_string )", "filename": "ast_tools.py", "nloc": 6, "complexity": 2, "token_count": 56, "parameters": [ "expr_string" ], "start_line": 50, "end_line": 66, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "ast_tools.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 204, "end_line": 206, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "ast_to_string", "long_name": "ast_to_string( ast_seq )", "filename": "ast_tools.py", "nloc": 8, "complexity": 4, "token_count": 49, "parameters": [ "ast_seq" ], "start_line": 34, "end_line": 48, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "remove_reserved_names", "long_name": "remove_reserved_names( lst )", "filename": "ast_tools.py", "nloc": 6, "complexity": 3, "token_count": 29, "parameters": [ "lst" ], "start_line": 122, "end_line": 131, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "find_first_pattern", "long_name": "find_first_pattern( ast_tuple , pattern_list )", "filename": "ast_tools.py", "nloc": 15, "complexity": 8, "token_count": 87, "parameters": [ "ast_tuple", "pattern_list" ], "start_line": 74, "end_line": 109, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 36, "top_nesting_level": 0 }, { "name": "remove_duplicates", "long_name": "remove_duplicates( lst )", "filename": "ast_tools.py", "nloc": 6, "complexity": 3, "token_count": 28, "parameters": [ "lst" ], "start_line": 113, "end_line": 118, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 } ], "nloc": null, "complexity": null, "token_count": null, "diff_parsed": { "added": [], "deleted": [ "import token", "import symbol", "import parser", "", "from types import ListType, TupleType, StringType, IntType", "", "def int_to_symbol(i):", " \"\"\" Convert numeric symbol or token to a desriptive name.", " \"\"\"", " try:", " return symbol.sym_name[i]", " except KeyError:", " return token.tok_name[i]", "", "def translate_symbols(ast_tuple):", " \"\"\" Translate numeric grammar symbols in an ast_tuple descriptive names.", "", " This simply traverses the tree converting any integer value to values", " found in symbol.sym_name or token.tok_name.", " \"\"\"", " new_list = []", " for item in ast_tuple:", " if type(item) == IntType:", " new_list.append(int_to_symbol(item))", " elif type(item) in [TupleType,ListType]:", " new_list.append(translate_symbols(item))", " else:", " new_list.append(item)", " if type(ast_tuple) == TupleType:", " return tuple(new_list)", " else:", " return new_list", "", "def ast_to_string(ast_seq):", " \"\"\"* Traverse an ast tree sequence, printing out all leaf nodes.", "", " This effectively rebuilds the expression the tree was built", " from. I guess its probably missing whitespace. How bout", " indent stuff and new lines? Haven't checked this since we're", " currently only dealing with simple expressions.", " *\"\"\"", " output = ''", " for item in ast_seq:", " if type(item) is StringType:", " output = output + item", " elif type(item) in [ListType,TupleType]:", " output = output + ast_to_string(item)", " return output", "", "def build_atom(expr_string):", " \"\"\" Build an ast for an atom from the given expr string.", "", " If expr_string is not a string, it is converted to a string", " before parsing to an ast_tuple.", " \"\"\"", " # the [1][1] indexing below starts atoms at the third level", " # deep in the resulting parse tree. parser.expr will return", " # a tree rooted with eval_input -> test_list -> test ...", " # I'm considering test to be the root of atom symbols.", " # It might be a better idea to move down a little in the", " # parse tree. Any benefits? Right now, this works fine.", " if type(expr_string) == StringType:", " ast = parser.expr(expr_string).totuple()[1][1]", " else:", " ast = parser.expr(`expr_string`).totuple()[1][1]", " return ast", "", "def atom_tuple(expr_string):", " return build_atom(expr_string)", "", "def atom_list(expr_string):", " return tuples_to_lists(build_atom(expr_string))", "", "def find_first_pattern(ast_tuple,pattern_list):", " \"\"\"* Find the first occurence of a pattern one of a list of patterns", " in ast_tuple.", "", " Used for testing at the moment.", "", " ast_tuple -- tuple or list created by ast.totuple() or ast.tolist().", " pattern_list -- A single pattern or list of patterns to search", " for in the ast_tuple. If a single pattern is", " used, it MUST BE A IN A TUPLE format.", " Returns:", " found -- true/false indicating whether pattern was found", " data -- dictionary of data from first matching pattern in tree.", " (see match function by Jeremy Hylton).", " *\"\"\"", " found,data = 0,{}", "", " # convert to a list if input wasn't a list", " if type(pattern_list) != ListType:", " pattern_list = [pattern_list]", "", " # look for any of the patterns in a list of patterns", " for pattern in pattern_list:", " found,data = match(pattern,ast_tuple)", " if found:", " break", "", " # if we didn't find the pattern, search sub-trees of the parse tree", " if not found:", " for item in ast_tuple:", " if type(item) in [TupleType,ListType]:", " # only search sub items if they are a list or tuple.", " found, data = find_first_pattern(item,pattern_list)", " if found:", " break", " return found,data", "", "name_pattern = (token.NAME, ['var'])", "", "def remove_duplicates(lst):", " output = []", " for item in lst:", " if item not in output:", " output.append(item)", " return output", "", "reserved_names = ['sin']", "", "def remove_reserved_names(lst):", " \"\"\" These are functions names -- don't create variables for them", " There is a more reobust approach, but this ought to work pretty", " well.", " \"\"\"", " output = []", " for item in lst:", " if item not in reserved_names:", " output.append(item)", " return output", "", "def harvest_variables(ast_list):", " \"\"\" Retreive all the variables that need to be defined.", " \"\"\"", " variables = []", " if type(ast_list) in (ListType,TupleType):", " found,data = match(name_pattern,ast_list)", " if found:", " variables.append(data['var'])", " for item in ast_list:", " if type(item) in (ListType,TupleType):", " variables.extend(harvest_variables(item))", " variables = remove_duplicates(variables)", " variables = remove_reserved_names(variables)", " return variables", "", "def match(pattern, data, vars=None):", " \"\"\"Match `data' to `pattern', with variable extraction.", "", " pattern", " Pattern to match against, possibly containing variables.", "", " data", " Data to be checked and against which variables are extracted.", "", " vars", " Dictionary of variables which have already been found. If not", " provided, an empty dictionary is created.", "", " The `pattern' value may contain variables of the form ['varname'] which", " are allowed to match anything. The value that is matched is returned as", " part of a dictionary which maps 'varname' to the matched value. 'varname'", " is not required to be a string object, but using strings makes patterns", " and the code which uses them more readable.", "", " This function returns two values: a boolean indicating whether a match", " was found and a dictionary mapping variable names to their associated", " values.", "", " From the Demo/Parser/example.py file", " \"\"\"", " if vars is None:", " vars = {}", " if type(pattern) is ListType: # 'variables' are ['varname']", " vars[pattern[0]] = data", " return 1, vars", " if type(pattern) is not TupleType:", " return (pattern == data), vars", " if len(data) != len(pattern):", " return 0, vars", " for pattern, data in map(None, pattern, data):", " same, vars = match(pattern, data, vars)", " if not same:", " break", " return same, vars", "", "", "def tuples_to_lists(ast_tuple):", " \"\"\" Convert an ast object tree in tuple form to list form.", " \"\"\"", " if type(ast_tuple) not in [ListType,TupleType]:", " return ast_tuple", "", " new_list = []", " for item in ast_tuple:", " new_list.append(tuples_to_lists(item))", " return new_list", "", "def test():", " from scipy_test import module_test", " module_test(__name__,__file__)", "", "def test_suite():", " from scipy_test import module_test_suite", " return module_test_suite(__name__,__file__)", "", "\"\"\"", "A little tree I built to help me understand the parse trees.", " -----------303------------------------------", " | |", " 304 -------------------------307-------------------------", " | | | | | |", " 1 'result' 9 '[' 308 12 ',' 308 10 ']'", " | |", " ---------309-------- -----309--------", " | | | |", " 291|304 291|304 291|304 |", " | | | |", " 1 'a1' 11 ':' 1 'a2' 2 '10' 11 ':'", "\"\"\"" ] } } ] }, { "hash": "3f0a7c931f04d6f8866235bec1bdbab16bbc84cd", "msg": "screwed up last check in. Returning to previous version", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-06T02:49:21+00:00", "author_timezone": 0, "committer_date": "2002-01-06T02:49:21+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "6d46146f04ab8ef404eefb093b2147b1d64a5d22" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 0, "insertions": 221, "lines": 221, "files": 1, "dmm_unit_size": 1.0, "dmm_unit_complexity": 0.7087378640776699, "dmm_unit_interfacing": 0.8543689320388349, "modified_files": [ { "old_path": "weave/ast_tools.py", "new_path": "weave/ast_tools.py", "filename": "ast_tools.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -0,0 +1,221 @@\n+import token\n+import symbol\n+import parser\n+\n+from types import ListType, TupleType, StringType, IntType\n+\n+def int_to_symbol(i):\n+ \"\"\" Convert numeric symbol or token to a desriptive name.\n+ \"\"\"\n+ try: \n+ return symbol.sym_name[i]\n+ except KeyError:\n+ return token.tok_name[i]\n+ \n+def translate_symbols(ast_tuple):\n+ \"\"\" Translate numeric grammar symbols in an ast_tuple descriptive names.\n+ \n+ This simply traverses the tree converting any integer value to values\n+ found in symbol.sym_name or token.tok_name.\n+ \"\"\" \n+ new_list = []\n+ for item in ast_tuple:\n+ if type(item) == IntType:\n+ new_list.append(int_to_symbol(item))\n+ elif type(item) in [TupleType,ListType]:\n+ new_list.append(translate_symbols(item))\n+ else: \n+ new_list.append(item)\n+ if type(ast_tuple) == TupleType:\n+ return tuple(new_list)\n+ else:\n+ return new_list\n+\n+def ast_to_string(ast_seq):\n+ \"\"\"* Traverse an ast tree sequence, printing out all leaf nodes.\n+ \n+ This effectively rebuilds the expression the tree was built\n+ from. I guess its probably missing whitespace. How bout\n+ indent stuff and new lines? Haven't checked this since we're\n+ currently only dealing with simple expressions.\n+ *\"\"\"\n+ output = ''\n+ for item in ast_seq:\n+ if type(item) is StringType:\n+ output = output + item\n+ elif type(item) in [ListType,TupleType]:\n+ output = output + ast_to_string(item)\n+ return output \n+\n+def build_atom(expr_string):\n+ \"\"\" Build an ast for an atom from the given expr string.\n+ \n+ If expr_string is not a string, it is converted to a string\n+ before parsing to an ast_tuple.\n+ \"\"\"\n+ # the [1][1] indexing below starts atoms at the third level\n+ # deep in the resulting parse tree. parser.expr will return\n+ # a tree rooted with eval_input -> test_list -> test ...\n+ # I'm considering test to be the root of atom symbols.\n+ # It might be a better idea to move down a little in the\n+ # parse tree. Any benefits? Right now, this works fine. \n+ if type(expr_string) == StringType:\n+ ast = parser.expr(expr_string).totuple()[1][1]\n+ else:\n+ ast = parser.expr(`expr_string`).totuple()[1][1]\n+ return ast\n+\n+def atom_tuple(expr_string):\n+ return build_atom(expr_string)\n+\n+def atom_list(expr_string):\n+ return tuples_to_lists(build_atom(expr_string))\n+ \n+def find_first_pattern(ast_tuple,pattern_list):\n+ \"\"\"* Find the first occurence of a pattern one of a list of patterns \n+ in ast_tuple.\n+ \n+ Used for testing at the moment.\n+ \n+ ast_tuple -- tuple or list created by ast.totuple() or ast.tolist().\n+ pattern_list -- A single pattern or list of patterns to search\n+ for in the ast_tuple. If a single pattern is \n+ used, it MUST BE A IN A TUPLE format.\n+ Returns:\n+ found -- true/false indicating whether pattern was found\n+ data -- dictionary of data from first matching pattern in tree.\n+ (see match function by Jeremy Hylton). \n+ *\"\"\"\n+ found,data = 0,{}\n+ \n+ # convert to a list if input wasn't a list\n+ if type(pattern_list) != ListType:\n+ pattern_list = [pattern_list]\n+\n+ # look for any of the patterns in a list of patterns \n+ for pattern in pattern_list:\n+ found,data = match(pattern,ast_tuple)\n+ if found: \n+ break \n+ \n+ # if we didn't find the pattern, search sub-trees of the parse tree\n+ if not found: \n+ for item in ast_tuple: \n+ if type(item) in [TupleType,ListType]:\n+ # only search sub items if they are a list or tuple.\n+ found, data = find_first_pattern(item,pattern_list)\n+ if found: \n+ break \n+ return found,data\n+\n+name_pattern = (token.NAME, ['var'])\n+\n+def remove_duplicates(lst):\n+ output = []\n+ for item in lst:\n+ if item not in output:\n+ output.append(item)\n+ return output\n+\n+reserved_names = ['sin']\n+\n+def remove_reserved_names(lst):\n+ \"\"\" These are functions names -- don't create variables for them\n+ There is a more reobust approach, but this ought to work pretty\n+ well.\n+ \"\"\"\n+ output = []\n+ for item in lst:\n+ if item not in reserved_names:\n+ output.append(item)\n+ return output\n+\n+def harvest_variables(ast_list): \n+ \"\"\" Retreive all the variables that need to be defined.\n+ \"\"\" \n+ variables = []\n+ if type(ast_list) in (ListType,TupleType):\n+ found,data = match(name_pattern,ast_list)\n+ if found:\n+ variables.append(data['var'])\n+ for item in ast_list:\n+ if type(item) in (ListType,TupleType):\n+ variables.extend(harvest_variables(item))\n+ variables = remove_duplicates(variables) \n+ variables = remove_reserved_names(variables) \n+ return variables\n+\n+def match(pattern, data, vars=None):\n+ \"\"\"Match `data' to `pattern', with variable extraction.\n+\n+ pattern\n+ Pattern to match against, possibly containing variables.\n+\n+ data\n+ Data to be checked and against which variables are extracted.\n+\n+ vars\n+ Dictionary of variables which have already been found. If not\n+ provided, an empty dictionary is created.\n+\n+ The `pattern' value may contain variables of the form ['varname'] which\n+ are allowed to match anything. The value that is matched is returned as\n+ part of a dictionary which maps 'varname' to the matched value. 'varname'\n+ is not required to be a string object, but using strings makes patterns\n+ and the code which uses them more readable.\n+\n+ This function returns two values: a boolean indicating whether a match\n+ was found and a dictionary mapping variable names to their associated\n+ values.\n+ \n+ From the Demo/Parser/example.py file\n+ \"\"\"\n+ if vars is None:\n+ vars = {}\n+ if type(pattern) is ListType: # 'variables' are ['varname']\n+ vars[pattern[0]] = data\n+ return 1, vars\n+ if type(pattern) is not TupleType:\n+ return (pattern == data), vars\n+ if len(data) != len(pattern):\n+ return 0, vars\n+ for pattern, data in map(None, pattern, data):\n+ same, vars = match(pattern, data, vars)\n+ if not same:\n+ break\n+ return same, vars\n+\n+\n+def tuples_to_lists(ast_tuple):\n+ \"\"\" Convert an ast object tree in tuple form to list form.\n+ \"\"\"\n+ if type(ast_tuple) not in [ListType,TupleType]:\n+ return ast_tuple\n+ \n+ new_list = []\n+ for item in ast_tuple:\n+ new_list.append(tuples_to_lists(item))\n+ return new_list\n+\n+def test():\n+ from scipy_test import module_test\n+ module_test(__name__,__file__)\n+\n+def test_suite():\n+ from scipy_test import module_test_suite\n+ return module_test_suite(__name__,__file__) \n+ \n+\"\"\"\n+A little tree I built to help me understand the parse trees.\n+ -----------303------------------------------\n+ | | \n+ 304 -------------------------307-------------------------\n+ | | | | | |\n+ 1 'result' 9 '[' 308 12 ',' 308 10 ']'\n+ | |\n+ ---------309-------- -----309-------- \n+ | | | | \n+ 291|304 291|304 291|304 |\n+ | | | |\n+ 1 'a1' 11 ':' 1 'a2' 2 '10' 11 ':' \n+\"\"\"\n", "added_lines": 221, "deleted_lines": 0, "source_code": "import token\nimport symbol\nimport parser\n\nfrom types import ListType, TupleType, StringType, IntType\n\ndef int_to_symbol(i):\n \"\"\" Convert numeric symbol or token to a desriptive name.\n \"\"\"\n try: \n return symbol.sym_name[i]\n except KeyError:\n return token.tok_name[i]\n \ndef translate_symbols(ast_tuple):\n \"\"\" Translate numeric grammar symbols in an ast_tuple descriptive names.\n \n This simply traverses the tree converting any integer value to values\n found in symbol.sym_name or token.tok_name.\n \"\"\" \n new_list = []\n for item in ast_tuple:\n if type(item) == IntType:\n new_list.append(int_to_symbol(item))\n elif type(item) in [TupleType,ListType]:\n new_list.append(translate_symbols(item))\n else: \n new_list.append(item)\n if type(ast_tuple) == TupleType:\n return tuple(new_list)\n else:\n return new_list\n\ndef ast_to_string(ast_seq):\n \"\"\"* Traverse an ast tree sequence, printing out all leaf nodes.\n \n This effectively rebuilds the expression the tree was built\n from. I guess its probably missing whitespace. How bout\n indent stuff and new lines? Haven't checked this since we're\n currently only dealing with simple expressions.\n *\"\"\"\n output = ''\n for item in ast_seq:\n if type(item) is StringType:\n output = output + item\n elif type(item) in [ListType,TupleType]:\n output = output + ast_to_string(item)\n return output \n\ndef build_atom(expr_string):\n \"\"\" Build an ast for an atom from the given expr string.\n \n If expr_string is not a string, it is converted to a string\n before parsing to an ast_tuple.\n \"\"\"\n # the [1][1] indexing below starts atoms at the third level\n # deep in the resulting parse tree. parser.expr will return\n # a tree rooted with eval_input -> test_list -> test ...\n # I'm considering test to be the root of atom symbols.\n # It might be a better idea to move down a little in the\n # parse tree. Any benefits? Right now, this works fine. \n if type(expr_string) == StringType:\n ast = parser.expr(expr_string).totuple()[1][1]\n else:\n ast = parser.expr(`expr_string`).totuple()[1][1]\n return ast\n\ndef atom_tuple(expr_string):\n return build_atom(expr_string)\n\ndef atom_list(expr_string):\n return tuples_to_lists(build_atom(expr_string))\n \ndef find_first_pattern(ast_tuple,pattern_list):\n \"\"\"* Find the first occurence of a pattern one of a list of patterns \n in ast_tuple.\n \n Used for testing at the moment.\n \n ast_tuple -- tuple or list created by ast.totuple() or ast.tolist().\n pattern_list -- A single pattern or list of patterns to search\n for in the ast_tuple. If a single pattern is \n used, it MUST BE A IN A TUPLE format.\n Returns:\n found -- true/false indicating whether pattern was found\n data -- dictionary of data from first matching pattern in tree.\n (see match function by Jeremy Hylton). \n *\"\"\"\n found,data = 0,{}\n \n # convert to a list if input wasn't a list\n if type(pattern_list) != ListType:\n pattern_list = [pattern_list]\n\n # look for any of the patterns in a list of patterns \n for pattern in pattern_list:\n found,data = match(pattern,ast_tuple)\n if found: \n break \n \n # if we didn't find the pattern, search sub-trees of the parse tree\n if not found: \n for item in ast_tuple: \n if type(item) in [TupleType,ListType]:\n # only search sub items if they are a list or tuple.\n found, data = find_first_pattern(item,pattern_list)\n if found: \n break \n return found,data\n\nname_pattern = (token.NAME, ['var'])\n\ndef remove_duplicates(lst):\n output = []\n for item in lst:\n if item not in output:\n output.append(item)\n return output\n\nreserved_names = ['sin']\n\ndef remove_reserved_names(lst):\n \"\"\" These are functions names -- don't create variables for them\n There is a more reobust approach, but this ought to work pretty\n well.\n \"\"\"\n output = []\n for item in lst:\n if item not in reserved_names:\n output.append(item)\n return output\n\ndef harvest_variables(ast_list): \n \"\"\" Retreive all the variables that need to be defined.\n \"\"\" \n variables = []\n if type(ast_list) in (ListType,TupleType):\n found,data = match(name_pattern,ast_list)\n if found:\n variables.append(data['var'])\n for item in ast_list:\n if type(item) in (ListType,TupleType):\n variables.extend(harvest_variables(item))\n variables = remove_duplicates(variables) \n variables = remove_reserved_names(variables) \n return variables\n\ndef match(pattern, data, vars=None):\n \"\"\"Match `data' to `pattern', with variable extraction.\n\n pattern\n Pattern to match against, possibly containing variables.\n\n data\n Data to be checked and against which variables are extracted.\n\n vars\n Dictionary of variables which have already been found. If not\n provided, an empty dictionary is created.\n\n The `pattern' value may contain variables of the form ['varname'] which\n are allowed to match anything. The value that is matched is returned as\n part of a dictionary which maps 'varname' to the matched value. 'varname'\n is not required to be a string object, but using strings makes patterns\n and the code which uses them more readable.\n\n This function returns two values: a boolean indicating whether a match\n was found and a dictionary mapping variable names to their associated\n values.\n \n From the Demo/Parser/example.py file\n \"\"\"\n if vars is None:\n vars = {}\n if type(pattern) is ListType: # 'variables' are ['varname']\n vars[pattern[0]] = data\n return 1, vars\n if type(pattern) is not TupleType:\n return (pattern == data), vars\n if len(data) != len(pattern):\n return 0, vars\n for pattern, data in map(None, pattern, data):\n same, vars = match(pattern, data, vars)\n if not same:\n break\n return same, vars\n\n\ndef tuples_to_lists(ast_tuple):\n \"\"\" Convert an ast object tree in tuple form to list form.\n \"\"\"\n if type(ast_tuple) not in [ListType,TupleType]:\n return ast_tuple\n \n new_list = []\n for item in ast_tuple:\n new_list.append(tuples_to_lists(item))\n return new_list\n\ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n \n\"\"\"\nA little tree I built to help me understand the parse trees.\n -----------303------------------------------\n | | \n 304 -------------------------307-------------------------\n | | | | | |\n 1 'result' 9 '[' 308 12 ',' 308 10 ']'\n | |\n ---------309-------- -----309-------- \n | | | | \n 291|304 291|304 291|304 |\n | | | |\n 1 'a1' 11 ':' 1 'a2' 2 '10' 11 ':' \n\"\"\"\n", "source_code_before": null, "methods": [ { "name": "int_to_symbol", "long_name": "int_to_symbol( i )", "filename": "ast_tools.py", "nloc": 5, "complexity": 2, "token_count": 25, "parameters": [ "i" ], "start_line": 7, "end_line": 13, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "translate_symbols", "long_name": "translate_symbols( ast_tuple )", "filename": "ast_tools.py", "nloc": 13, "complexity": 5, "token_count": 78, "parameters": [ "ast_tuple" ], "start_line": 15, "end_line": 32, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 0 }, { "name": "ast_to_string", "long_name": "ast_to_string( ast_seq )", "filename": "ast_tools.py", "nloc": 8, "complexity": 4, "token_count": 49, "parameters": [ "ast_seq" ], "start_line": 34, "end_line": 48, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "build_atom", "long_name": "build_atom( expr_string )", "filename": "ast_tools.py", "nloc": 6, "complexity": 2, "token_count": 56, "parameters": [ "expr_string" ], "start_line": 50, "end_line": 66, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 0 }, { "name": "atom_tuple", "long_name": "atom_tuple( expr_string )", "filename": "ast_tools.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "expr_string" ], "start_line": 68, "end_line": 69, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "atom_list", "long_name": "atom_list( expr_string )", "filename": "ast_tools.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "expr_string" ], "start_line": 71, "end_line": 72, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "find_first_pattern", "long_name": "find_first_pattern( ast_tuple , pattern_list )", "filename": "ast_tools.py", "nloc": 15, "complexity": 8, "token_count": 87, "parameters": [ "ast_tuple", "pattern_list" ], "start_line": 74, "end_line": 109, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 36, "top_nesting_level": 0 }, { "name": "remove_duplicates", "long_name": "remove_duplicates( lst )", "filename": "ast_tools.py", "nloc": 6, "complexity": 3, "token_count": 28, "parameters": [ "lst" ], "start_line": 113, "end_line": 118, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 }, { "name": "remove_reserved_names", "long_name": "remove_reserved_names( lst )", "filename": "ast_tools.py", "nloc": 6, "complexity": 3, "token_count": 29, "parameters": [ "lst" ], "start_line": 122, "end_line": 131, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "harvest_variables", "long_name": "harvest_variables( ast_list )", "filename": "ast_tools.py", "nloc": 12, "complexity": 5, "token_count": 84, "parameters": [ "ast_list" ], "start_line": 133, "end_line": 146, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 0 }, { "name": "match", "long_name": "match( pattern , data , vars = None )", "filename": "ast_tools.py", "nloc": 15, "complexity": 7, "token_count": 109, "parameters": [ "pattern", "data", "vars" ], "start_line": 148, "end_line": 186, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 39, "top_nesting_level": 0 }, { "name": "tuples_to_lists", "long_name": "tuples_to_lists( ast_tuple )", "filename": "ast_tools.py", "nloc": 7, "complexity": 3, "token_count": 41, "parameters": [ "ast_tuple" ], "start_line": 189, "end_line": 198, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "ast_tools.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 200, "end_line": 202, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "ast_tools.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 204, "end_line": 206, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "methods_before": [], "changed_methods": [ { "name": "translate_symbols", "long_name": "translate_symbols( ast_tuple )", "filename": "ast_tools.py", "nloc": 13, "complexity": 5, "token_count": 78, "parameters": [ "ast_tuple" ], "start_line": 15, "end_line": 32, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 0 }, { "name": "harvest_variables", "long_name": "harvest_variables( ast_list )", "filename": "ast_tools.py", "nloc": 12, "complexity": 5, "token_count": 84, "parameters": [ "ast_list" ], "start_line": 133, "end_line": 146, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 0 }, { "name": "atom_tuple", "long_name": "atom_tuple( expr_string )", "filename": "ast_tools.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "expr_string" ], "start_line": 68, "end_line": 69, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "int_to_symbol", "long_name": "int_to_symbol( i )", "filename": "ast_tools.py", "nloc": 5, "complexity": 2, "token_count": 25, "parameters": [ "i" ], "start_line": 7, "end_line": 13, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 0 }, { "name": "tuples_to_lists", "long_name": "tuples_to_lists( ast_tuple )", "filename": "ast_tools.py", "nloc": 7, "complexity": 3, "token_count": 41, "parameters": [ "ast_tuple" ], "start_line": 189, "end_line": 198, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "atom_list", "long_name": "atom_list( expr_string )", "filename": "ast_tools.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "expr_string" ], "start_line": 71, "end_line": 72, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 0 }, { "name": "match", "long_name": "match( pattern , data , vars = None )", "filename": "ast_tools.py", "nloc": 15, "complexity": 7, "token_count": 109, "parameters": [ "pattern", "data", "vars" ], "start_line": 148, "end_line": 186, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 39, "top_nesting_level": 0 }, { "name": "test", "long_name": "test( )", "filename": "ast_tools.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 200, "end_line": 202, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "build_atom", "long_name": "build_atom( expr_string )", "filename": "ast_tools.py", "nloc": 6, "complexity": 2, "token_count": 56, "parameters": [ "expr_string" ], "start_line": 50, "end_line": 66, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 17, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "ast_tools.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 204, "end_line": 206, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "ast_to_string", "long_name": "ast_to_string( ast_seq )", "filename": "ast_tools.py", "nloc": 8, "complexity": 4, "token_count": 49, "parameters": [ "ast_seq" ], "start_line": 34, "end_line": 48, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 0 }, { "name": "remove_reserved_names", "long_name": "remove_reserved_names( lst )", "filename": "ast_tools.py", "nloc": 6, "complexity": 3, "token_count": 29, "parameters": [ "lst" ], "start_line": 122, "end_line": 131, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "find_first_pattern", "long_name": "find_first_pattern( ast_tuple , pattern_list )", "filename": "ast_tools.py", "nloc": 15, "complexity": 8, "token_count": 87, "parameters": [ "ast_tuple", "pattern_list" ], "start_line": 74, "end_line": 109, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 36, "top_nesting_level": 0 }, { "name": "remove_duplicates", "long_name": "remove_duplicates( lst )", "filename": "ast_tools.py", "nloc": 6, "complexity": 3, "token_count": 28, "parameters": [ "lst" ], "start_line": 113, "end_line": 118, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 0 } ], "nloc": 123, "complexity": 46, "token_count": 685, "diff_parsed": { "added": [ "import token", "import symbol", "import parser", "", "from types import ListType, TupleType, StringType, IntType", "", "def int_to_symbol(i):", " \"\"\" Convert numeric symbol or token to a desriptive name.", " \"\"\"", " try:", " return symbol.sym_name[i]", " except KeyError:", " return token.tok_name[i]", "", "def translate_symbols(ast_tuple):", " \"\"\" Translate numeric grammar symbols in an ast_tuple descriptive names.", "", " This simply traverses the tree converting any integer value to values", " found in symbol.sym_name or token.tok_name.", " \"\"\"", " new_list = []", " for item in ast_tuple:", " if type(item) == IntType:", " new_list.append(int_to_symbol(item))", " elif type(item) in [TupleType,ListType]:", " new_list.append(translate_symbols(item))", " else:", " new_list.append(item)", " if type(ast_tuple) == TupleType:", " return tuple(new_list)", " else:", " return new_list", "", "def ast_to_string(ast_seq):", " \"\"\"* Traverse an ast tree sequence, printing out all leaf nodes.", "", " This effectively rebuilds the expression the tree was built", " from. I guess its probably missing whitespace. How bout", " indent stuff and new lines? Haven't checked this since we're", " currently only dealing with simple expressions.", " *\"\"\"", " output = ''", " for item in ast_seq:", " if type(item) is StringType:", " output = output + item", " elif type(item) in [ListType,TupleType]:", " output = output + ast_to_string(item)", " return output", "", "def build_atom(expr_string):", " \"\"\" Build an ast for an atom from the given expr string.", "", " If expr_string is not a string, it is converted to a string", " before parsing to an ast_tuple.", " \"\"\"", " # the [1][1] indexing below starts atoms at the third level", " # deep in the resulting parse tree. parser.expr will return", " # a tree rooted with eval_input -> test_list -> test ...", " # I'm considering test to be the root of atom symbols.", " # It might be a better idea to move down a little in the", " # parse tree. Any benefits? Right now, this works fine.", " if type(expr_string) == StringType:", " ast = parser.expr(expr_string).totuple()[1][1]", " else:", " ast = parser.expr(`expr_string`).totuple()[1][1]", " return ast", "", "def atom_tuple(expr_string):", " return build_atom(expr_string)", "", "def atom_list(expr_string):", " return tuples_to_lists(build_atom(expr_string))", "", "def find_first_pattern(ast_tuple,pattern_list):", " \"\"\"* Find the first occurence of a pattern one of a list of patterns", " in ast_tuple.", "", " Used for testing at the moment.", "", " ast_tuple -- tuple or list created by ast.totuple() or ast.tolist().", " pattern_list -- A single pattern or list of patterns to search", " for in the ast_tuple. If a single pattern is", " used, it MUST BE A IN A TUPLE format.", " Returns:", " found -- true/false indicating whether pattern was found", " data -- dictionary of data from first matching pattern in tree.", " (see match function by Jeremy Hylton).", " *\"\"\"", " found,data = 0,{}", "", " # convert to a list if input wasn't a list", " if type(pattern_list) != ListType:", " pattern_list = [pattern_list]", "", " # look for any of the patterns in a list of patterns", " for pattern in pattern_list:", " found,data = match(pattern,ast_tuple)", " if found:", " break", "", " # if we didn't find the pattern, search sub-trees of the parse tree", " if not found:", " for item in ast_tuple:", " if type(item) in [TupleType,ListType]:", " # only search sub items if they are a list or tuple.", " found, data = find_first_pattern(item,pattern_list)", " if found:", " break", " return found,data", "", "name_pattern = (token.NAME, ['var'])", "", "def remove_duplicates(lst):", " output = []", " for item in lst:", " if item not in output:", " output.append(item)", " return output", "", "reserved_names = ['sin']", "", "def remove_reserved_names(lst):", " \"\"\" These are functions names -- don't create variables for them", " There is a more reobust approach, but this ought to work pretty", " well.", " \"\"\"", " output = []", " for item in lst:", " if item not in reserved_names:", " output.append(item)", " return output", "", "def harvest_variables(ast_list):", " \"\"\" Retreive all the variables that need to be defined.", " \"\"\"", " variables = []", " if type(ast_list) in (ListType,TupleType):", " found,data = match(name_pattern,ast_list)", " if found:", " variables.append(data['var'])", " for item in ast_list:", " if type(item) in (ListType,TupleType):", " variables.extend(harvest_variables(item))", " variables = remove_duplicates(variables)", " variables = remove_reserved_names(variables)", " return variables", "", "def match(pattern, data, vars=None):", " \"\"\"Match `data' to `pattern', with variable extraction.", "", " pattern", " Pattern to match against, possibly containing variables.", "", " data", " Data to be checked and against which variables are extracted.", "", " vars", " Dictionary of variables which have already been found. If not", " provided, an empty dictionary is created.", "", " The `pattern' value may contain variables of the form ['varname'] which", " are allowed to match anything. The value that is matched is returned as", " part of a dictionary which maps 'varname' to the matched value. 'varname'", " is not required to be a string object, but using strings makes patterns", " and the code which uses them more readable.", "", " This function returns two values: a boolean indicating whether a match", " was found and a dictionary mapping variable names to their associated", " values.", "", " From the Demo/Parser/example.py file", " \"\"\"", " if vars is None:", " vars = {}", " if type(pattern) is ListType: # 'variables' are ['varname']", " vars[pattern[0]] = data", " return 1, vars", " if type(pattern) is not TupleType:", " return (pattern == data), vars", " if len(data) != len(pattern):", " return 0, vars", " for pattern, data in map(None, pattern, data):", " same, vars = match(pattern, data, vars)", " if not same:", " break", " return same, vars", "", "", "def tuples_to_lists(ast_tuple):", " \"\"\" Convert an ast object tree in tuple form to list form.", " \"\"\"", " if type(ast_tuple) not in [ListType,TupleType]:", " return ast_tuple", "", " new_list = []", " for item in ast_tuple:", " new_list.append(tuples_to_lists(item))", " return new_list", "", "def test():", " from scipy_test import module_test", " module_test(__name__,__file__)", "", "def test_suite():", " from scipy_test import module_test_suite", " return module_test_suite(__name__,__file__)", "", "\"\"\"", "A little tree I built to help me understand the parse trees.", " -----------303------------------------------", " | |", " 304 -------------------------307-------------------------", " | | | | | |", " 1 'result' 9 '[' 308 12 ',' 308 10 ']'", " | |", " ---------309-------- -----309--------", " | | | |", " 291|304 291|304 291|304 |", " | | | |", " 1 'a1' 11 ':' 1 'a2' 2 '10' 11 ':'", "\"\"\"" ], "deleted": [] } } ] }, { "hash": "b2e1b50ccd32c98a959f4d6c59fd84f714effd47", "msg": "converted DOS line endings to UNIX line endings", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-06T04:07:38+00:00", "author_timezone": 0, "committer_date": "2002-01-06T04:07:38+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "3f0a7c931f04d6f8866235bec1bdbab16bbc84cd" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 0, "insertions": 0, "lines": 0, "files": 0, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null }, { "hash": "fbeedee8e7a99b9628832898379f8da9e132c43d", "msg": "fixed a bug in declarations for ext modules. Types were not being cast correctly.", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-06T07:20:55+00:00", "author_timezone": 0, "committer_date": "2002-01-06T07:20:55+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "b2e1b50ccd32c98a959f4d6c59fd84f714effd47" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 2, "insertions": 2, "lines": 4, "files": 1, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": "weave/standard_array_spec.py", "new_path": "weave/standard_array_spec.py", "filename": "standard_array_spec.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -48,8 +48,8 @@ def standard_decl_code(self):\n 'PyArrayObject* %(name)s = py_to_numpy(py_%(name)s,\"%(name)s\");\\n' \\\n 'int* _N%(name)s = %(name)s->dimensions;\\n' \\\n 'int* _S%(name)s = %(name)s->strides;\\n' \\\n- 'int* _D%(name)s = %(name)s->nd;\\n' \\\n- '%(type)s* %(name)s_data = %(name)s->data;\\n' \n+ 'int _D%(name)s = %(name)s->nd;\\n' \\\n+ '%(type)s* %(name)s_data = (%(type)s*) %(name)s->data;\\n' \n code = templ % locals()\n return code\n #def c_function_declaration_code(self):\n", "added_lines": 2, "deleted_lines": 2, "source_code": "from base_spec import base_specification\nfrom scalar_spec import numeric_to_blitz_type_mapping\nfrom Numeric import *\nfrom types import *\nimport os\nimport standard_array_info\n\nclass array_specification(base_specification):\n _build_information = [standard_array_info.array_info()]\n \n def type_match(self,value):\n return type(value) is ArrayType\n\n def type_spec(self,name,value):\n # factory\n new_spec = array_specification()\n new_spec.name = name\n new_spec.numeric_type = value.typecode()\n # dims not used, but here for compatibility with blitz_spec\n new_spec.dims = len(shape(value))\n return new_spec\n\n def declaration_code(self,templatize = 0,inline=0):\n if inline:\n code = self.inline_decl_code()\n else:\n code = self.standard_decl_code()\n return code\n \n def inline_decl_code(self):\n type = numeric_to_blitz_type_mapping[self.numeric_type]\n name = self.name\n var_name = self.retrieve_py_variable(inline=1)\n templ = '// %(name)s array declaration\\n' \\\n 'py_%(name)s= %(var_name)s;\\n' \\\n 'PyArrayObject* %(name)s = py_to_numpy(py_%(name)s,\"%(name)s\");\\n' \\\n 'int* _N%(name)s = %(name)s->dimensions;\\n' \\\n 'int* _S%(name)s = %(name)s->strides;\\n' \\\n 'int _D%(name)s = %(name)s->nd;\\n' \\\n '%(type)s* %(name)s_data = (%(type)s*) %(name)s->data;\\n' \n code = templ % locals()\n return code\n\n def standard_decl_code(self): \n type = numeric_to_blitz_type_mapping[self.numeric_type]\n name = self.name\n templ = '// %(name)s array declaration\\n' \\\n 'PyArrayObject* %(name)s = py_to_numpy(py_%(name)s,\"%(name)s\");\\n' \\\n 'int* _N%(name)s = %(name)s->dimensions;\\n' \\\n 'int* _S%(name)s = %(name)s->strides;\\n' \\\n 'int _D%(name)s = %(name)s->nd;\\n' \\\n '%(type)s* %(name)s_data = (%(type)s*) %(name)s->data;\\n' \n code = templ % locals()\n return code\n #def c_function_declaration_code(self):\n # \"\"\"\n # This doesn't pass the size through. That info is gonna have to \n # be redone in the c function.\n # \"\"\"\n # templ_dict = {}\n # templ_dict['type'] = numeric_to_blitz_type_mapping[self.numeric_type]\n # templ_dict['dims'] = self.dims\n # templ_dict['name'] = self.name\n # code = 'blitz::Array<%(type)s,%(dims)d> &%(name)s' % templ_dict\n # return code\n \n def local_dict_code(self):\n code = '// for now, array \"%s\" is not returned as arryas are edited' \\\n ' in place (should this change?)\\n' % (self.name) \n return code\n\n def cleanup_code(self):\n # could use Py_DECREF here I think and save NULL test.\n code = \"Py_XDECREF(py_%s);\\n\" % self.name\n return code\n\n def __repr__(self):\n msg = \"(array:: name: %s, type: %s)\" % \\\n (self.name, self.numeric_type)\n return msg\n\n def __cmp__(self,other):\n #only works for equal\n return cmp(self.name,other.name) or \\\n cmp(self.numeric_type,other.numeric_type) or \\\n cmp(self.dims, other.dims) or \\\n cmp(self.__class__, other.__class__)\n\nimport ext_tools\nstandard_array_factories = [array_specification()] + ext_tools.default_type_factories\n\ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n", "source_code_before": "from base_spec import base_specification\nfrom scalar_spec import numeric_to_blitz_type_mapping\nfrom Numeric import *\nfrom types import *\nimport os\nimport standard_array_info\n\nclass array_specification(base_specification):\n _build_information = [standard_array_info.array_info()]\n \n def type_match(self,value):\n return type(value) is ArrayType\n\n def type_spec(self,name,value):\n # factory\n new_spec = array_specification()\n new_spec.name = name\n new_spec.numeric_type = value.typecode()\n # dims not used, but here for compatibility with blitz_spec\n new_spec.dims = len(shape(value))\n return new_spec\n\n def declaration_code(self,templatize = 0,inline=0):\n if inline:\n code = self.inline_decl_code()\n else:\n code = self.standard_decl_code()\n return code\n \n def inline_decl_code(self):\n type = numeric_to_blitz_type_mapping[self.numeric_type]\n name = self.name\n var_name = self.retrieve_py_variable(inline=1)\n templ = '// %(name)s array declaration\\n' \\\n 'py_%(name)s= %(var_name)s;\\n' \\\n 'PyArrayObject* %(name)s = py_to_numpy(py_%(name)s,\"%(name)s\");\\n' \\\n 'int* _N%(name)s = %(name)s->dimensions;\\n' \\\n 'int* _S%(name)s = %(name)s->strides;\\n' \\\n 'int _D%(name)s = %(name)s->nd;\\n' \\\n '%(type)s* %(name)s_data = (%(type)s*) %(name)s->data;\\n' \n code = templ % locals()\n return code\n\n def standard_decl_code(self): \n type = numeric_to_blitz_type_mapping[self.numeric_type]\n name = self.name\n templ = '// %(name)s array declaration\\n' \\\n 'PyArrayObject* %(name)s = py_to_numpy(py_%(name)s,\"%(name)s\");\\n' \\\n 'int* _N%(name)s = %(name)s->dimensions;\\n' \\\n 'int* _S%(name)s = %(name)s->strides;\\n' \\\n 'int* _D%(name)s = %(name)s->nd;\\n' \\\n '%(type)s* %(name)s_data = %(name)s->data;\\n' \n code = templ % locals()\n return code\n #def c_function_declaration_code(self):\n # \"\"\"\n # This doesn't pass the size through. That info is gonna have to \n # be redone in the c function.\n # \"\"\"\n # templ_dict = {}\n # templ_dict['type'] = numeric_to_blitz_type_mapping[self.numeric_type]\n # templ_dict['dims'] = self.dims\n # templ_dict['name'] = self.name\n # code = 'blitz::Array<%(type)s,%(dims)d> &%(name)s' % templ_dict\n # return code\n \n def local_dict_code(self):\n code = '// for now, array \"%s\" is not returned as arryas are edited' \\\n ' in place (should this change?)\\n' % (self.name) \n return code\n\n def cleanup_code(self):\n # could use Py_DECREF here I think and save NULL test.\n code = \"Py_XDECREF(py_%s);\\n\" % self.name\n return code\n\n def __repr__(self):\n msg = \"(array:: name: %s, type: %s)\" % \\\n (self.name, self.numeric_type)\n return msg\n\n def __cmp__(self,other):\n #only works for equal\n return cmp(self.name,other.name) or \\\n cmp(self.numeric_type,other.numeric_type) or \\\n cmp(self.dims, other.dims) or \\\n cmp(self.__class__, other.__class__)\n\nimport ext_tools\nstandard_array_factories = [array_specification()] + ext_tools.default_type_factories\n\ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n", "methods": [ { "name": "type_match", "long_name": "type_match( self , value )", "filename": "standard_array_spec.py", "nloc": 2, "complexity": 1, "token_count": 14, "parameters": [ "self", "value" ], "start_line": 11, "end_line": 12, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "type_spec", "long_name": "type_spec( self , name , value )", "filename": "standard_array_spec.py", "nloc": 6, "complexity": 1, "token_count": 41, "parameters": [ "self", "name", "value" ], "start_line": 14, "end_line": 21, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "declaration_code", "long_name": "declaration_code( self , templatize = 0 , inline = 0 )", "filename": "standard_array_spec.py", "nloc": 6, "complexity": 2, "token_count": 34, "parameters": [ "self", "templatize", "inline" ], "start_line": 23, "end_line": 28, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "inline_decl_code", "long_name": "inline_decl_code( self )", "filename": "standard_array_spec.py", "nloc": 13, "complexity": 1, "token_count": 52, "parameters": [ "self" ], "start_line": 30, "end_line": 42, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "standard_decl_code", "long_name": "standard_decl_code( self )", "filename": "standard_array_spec.py", "nloc": 11, "complexity": 1, "token_count": 40, "parameters": [ "self" ], "start_line": 44, "end_line": 54, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 1 }, { "name": "local_dict_code", "long_name": "local_dict_code( self )", "filename": "standard_array_spec.py", "nloc": 4, "complexity": 1, "token_count": 18, "parameters": [ "self" ], "start_line": 67, "end_line": 70, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "cleanup_code", "long_name": "cleanup_code( self )", "filename": "standard_array_spec.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [ "self" ], "start_line": 72, "end_line": 75, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "__repr__", "long_name": "__repr__( self )", "filename": "standard_array_spec.py", "nloc": 4, "complexity": 1, "token_count": 21, "parameters": [ "self" ], "start_line": 77, "end_line": 80, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "__cmp__", "long_name": "__cmp__( self , other )", "filename": "standard_array_spec.py", "nloc": 5, "complexity": 4, "token_count": 54, "parameters": [ "self", "other" ], "start_line": 82, "end_line": 87, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "test", "long_name": "test( )", "filename": "standard_array_spec.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 92, "end_line": 94, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "standard_array_spec.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 96, "end_line": 98, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "methods_before": [ { "name": "type_match", "long_name": "type_match( self , value )", "filename": "standard_array_spec.py", "nloc": 2, "complexity": 1, "token_count": 14, "parameters": [ "self", "value" ], "start_line": 11, "end_line": 12, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 2, "top_nesting_level": 1 }, { "name": "type_spec", "long_name": "type_spec( self , name , value )", "filename": "standard_array_spec.py", "nloc": 6, "complexity": 1, "token_count": 41, "parameters": [ "self", "name", "value" ], "start_line": 14, "end_line": 21, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 1 }, { "name": "declaration_code", "long_name": "declaration_code( self , templatize = 0 , inline = 0 )", "filename": "standard_array_spec.py", "nloc": 6, "complexity": 2, "token_count": 34, "parameters": [ "self", "templatize", "inline" ], "start_line": 23, "end_line": 28, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "inline_decl_code", "long_name": "inline_decl_code( self )", "filename": "standard_array_spec.py", "nloc": 13, "complexity": 1, "token_count": 52, "parameters": [ "self" ], "start_line": 30, "end_line": 42, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "standard_decl_code", "long_name": "standard_decl_code( self )", "filename": "standard_array_spec.py", "nloc": 11, "complexity": 1, "token_count": 40, "parameters": [ "self" ], "start_line": 44, "end_line": 54, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 1 }, { "name": "local_dict_code", "long_name": "local_dict_code( self )", "filename": "standard_array_spec.py", "nloc": 4, "complexity": 1, "token_count": 18, "parameters": [ "self" ], "start_line": 67, "end_line": 70, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "cleanup_code", "long_name": "cleanup_code( self )", "filename": "standard_array_spec.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [ "self" ], "start_line": 72, "end_line": 75, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "__repr__", "long_name": "__repr__( self )", "filename": "standard_array_spec.py", "nloc": 4, "complexity": 1, "token_count": 21, "parameters": [ "self" ], "start_line": 77, "end_line": 80, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "__cmp__", "long_name": "__cmp__( self , other )", "filename": "standard_array_spec.py", "nloc": 5, "complexity": 4, "token_count": 54, "parameters": [ "self", "other" ], "start_line": 82, "end_line": 87, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "test", "long_name": "test( )", "filename": "standard_array_spec.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 92, "end_line": 94, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "standard_array_spec.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 96, "end_line": 98, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "standard_decl_code", "long_name": "standard_decl_code( self )", "filename": "standard_array_spec.py", "nloc": 11, "complexity": 1, "token_count": 40, "parameters": [ "self" ], "start_line": 44, "end_line": 54, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 1 } ], "nloc": 70, "complexity": 15, "token_count": 376, "diff_parsed": { "added": [ " 'int _D%(name)s = %(name)s->nd;\\n' \\", " '%(type)s* %(name)s_data = (%(type)s*) %(name)s->data;\\n'" ], "deleted": [ " 'int* _D%(name)s = %(name)s->nd;\\n' \\", " '%(type)s* %(name)s_data = %(name)s->data;\\n'" ] } } ] }, { "hash": "a0515424696067f0b63dd295c5fb6df1bd31e444", "msg": "Added ramp example brought up by Brent Burley on comp.lang.python.", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-06T07:54:16+00:00", "author_timezone": 0, "committer_date": "2002-01-06T07:54:16+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "fbeedee8e7a99b9628832898379f8da9e132c43d" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 0, "insertions": 155, "lines": 155, "files": 3, "dmm_unit_size": 0.4297520661157025, "dmm_unit_complexity": 1.0, "dmm_unit_interfacing": 0.6859504132231405, "modified_files": [ { "old_path": null, "new_path": "weave/examples/ramp.c", "filename": "ramp.c", "extension": "c", "change_type": "ADD", "diff": "@@ -0,0 +1,29 @@\n+#include \n+#include \n+\n+void Ramp(double* result, int size, double start, double end)\n+{\n+ double step = (end-start)/(size-1);\n+ double val = start;\n+ int i;\n+ for (i = 0; i < size; i++)\n+ {\n+ *result++ = val;\n+ val += step; \n+ } \n+}\n+\n+void main()\n+{\n+ double array[10000];\n+ int i;\n+ clock_t t1, t2;\n+ float seconds;\n+ t1 = clock();\n+ for (i = 0; i < 10000; i++)\n+ Ramp(array, 10000, 0.0, 1.0);\n+ t2 = clock();\n+ seconds = (float)(t2-t1)/CLOCKS_PER_SEC; \n+ printf(\"c version (seconds): %f\\n\", seconds);\n+ printf(\"array[500]: %f\\n\", array[500]);\n+}\n\\ No newline at end of file\n", "added_lines": 29, "deleted_lines": 0, "source_code": "#include \n#include \n\nvoid Ramp(double* result, int size, double start, double end)\n{\n double step = (end-start)/(size-1);\n double val = start;\n int i;\n for (i = 0; i < size; i++)\n {\n *result++ = val;\n val += step; \n } \n}\n\nvoid main()\n{\n double array[10000];\n int i;\n clock_t t1, t2;\n float seconds;\n t1 = clock();\n for (i = 0; i < 10000; i++)\n Ramp(array, 10000, 0.0, 1.0);\n t2 = clock();\n seconds = (float)(t2-t1)/CLOCKS_PER_SEC; \n printf(\"c version (seconds): %f\\n\", seconds);\n printf(\"array[500]: %f\\n\", array[500]);\n}", "source_code_before": null, "methods": [ { "name": "Ramp", "long_name": "Ramp( double * result , int size , double start , double end)", "filename": "ramp.c", "nloc": 11, "complexity": 2, "token_count": 65, "parameters": [ "result", "size", "start", "end" ], "start_line": 4, "end_line": 14, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 }, { "name": "main", "long_name": "main()", "filename": "ramp.c", "nloc": 14, "complexity": 2, "token_count": 88, "parameters": [], "start_line": 16, "end_line": 29, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 0 } ], "methods_before": [], "changed_methods": [ { "name": "Ramp", "long_name": "Ramp( double * result , int size , double start , double end)", "filename": "ramp.c", "nloc": 11, "complexity": 2, "token_count": 65, "parameters": [ "result", "size", "start", "end" ], "start_line": 4, "end_line": 14, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 }, { "name": "main", "long_name": "main()", "filename": "ramp.c", "nloc": 14, "complexity": 2, "token_count": 88, "parameters": [], "start_line": 16, "end_line": 29, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 14, "top_nesting_level": 0 } ], "nloc": 27, "complexity": 4, "token_count": 159, "diff_parsed": { "added": [ "#include ", "#include ", "", "void Ramp(double* result, int size, double start, double end)", "{", " double step = (end-start)/(size-1);", " double val = start;", " int i;", " for (i = 0; i < size; i++)", " {", " *result++ = val;", " val += step;", " }", "}", "", "void main()", "{", " double array[10000];", " int i;", " clock_t t1, t2;", " float seconds;", " t1 = clock();", " for (i = 0; i < 10000; i++)", " Ramp(array, 10000, 0.0, 1.0);", " t2 = clock();", " seconds = (float)(t2-t1)/CLOCKS_PER_SEC;", " printf(\"c version (seconds): %f\\n\", seconds);", " printf(\"array[500]: %f\\n\", array[500]);", "}" ], "deleted": [] } }, { "old_path": null, "new_path": "weave/examples/ramp.py", "filename": "ramp.py", "extension": "py", "change_type": "ADD", "diff": "@@ -0,0 +1,72 @@\n+import time\n+import weave\n+from Numeric import *\n+\n+def Ramp(result, size, start, end):\n+ step = (end-start)/(size-1)\n+ for i in xrange(size):\n+ result[i] = start + step*i\n+\n+def Ramp_numeric1(result,size,start,end):\n+ code = \"\"\"\n+ double step = (end-start)/(size-1);\n+ double val = start;\n+ for (int i = 0; i < size; i++)\n+ *result_data++ = start + step*i;\n+ \"\"\"\n+ weave.inline(code,['result','size','start','end'],compiler='gcc')\n+\n+def Ramp_numeric2(result,size,start,end):\n+ code = \"\"\"\n+ double step = (end-start)/(size-1);\n+ double val = start;\n+ for (int i = 0; i < size; i++)\n+ {\n+ result_data[i] = val;\n+ val += step; \n+ }\n+ \"\"\"\n+ weave.inline(code,['result','size','start','end'],compiler='gcc')\n+ \n+def main():\n+ N_array = 10000\n+ N_py = 200\n+ N_c = 10000\n+ \n+ ratio = float(N_c) / N_py \n+ \n+ arr = [0]*N_array\n+ t1 = time.time()\n+ for i in xrange(N_py):\n+ Ramp(arr, N_array, 0.0, 1.0)\n+ t2 = time.time()\n+ py_time = (t2 - t1) * ratio\n+ print 'python (seconds*ratio):', py_time\n+ print 'arr[500]:', arr[500]\n+ \n+ arr = array([0]*N_array,Float64)\n+ # First call compiles function or loads from cache.\n+ # I'm not including this in the timing.\n+ Ramp_numeric1(arr, N_array, 0.0, 1.0)\n+ t1 = time.time()\n+ for i in xrange(N_c):\n+ Ramp_numeric1(arr, N_array, 0.0, 1.0)\n+ t2 = time.time()\n+ c_time = (t2 - t1)\n+ print 'compiled numeric1 (seconds, speed up):', c_time, py_time/ c_time\n+ print 'arr[500]:', arr[500]\n+\n+ arr2 = array([0]*N_array,Float64)\n+ # First call compiles function or loads from cache.\n+ # I'm not including this in the timing.\n+ Ramp_numeric2(arr, N_array, 0.0, 1.0)\n+ t1 = time.time()\n+ for i in xrange(N_c):\n+ Ramp_numeric2(arr, N_array, 0.0, 1.0)\n+ t2 = time.time()\n+ c_time = (t2 - t1) \n+ print 'compiled numeric2 (seconds, speed up):', c_time, py_time/ c_time\n+ print 'arr[500]:', arr[500]\n+ \n+if __name__ == '__main__':\n+ main()\n\\ No newline at end of file\n", "added_lines": 72, "deleted_lines": 0, "source_code": "import time\nimport weave\nfrom Numeric import *\n\ndef Ramp(result, size, start, end):\n step = (end-start)/(size-1)\n for i in xrange(size):\n result[i] = start + step*i\n\ndef Ramp_numeric1(result,size,start,end):\n code = \"\"\"\n double step = (end-start)/(size-1);\n double val = start;\n for (int i = 0; i < size; i++)\n *result_data++ = start + step*i;\n \"\"\"\n weave.inline(code,['result','size','start','end'],compiler='gcc')\n\ndef Ramp_numeric2(result,size,start,end):\n code = \"\"\"\n double step = (end-start)/(size-1);\n double val = start;\n for (int i = 0; i < size; i++)\n {\n result_data[i] = val;\n val += step; \n }\n \"\"\"\n weave.inline(code,['result','size','start','end'],compiler='gcc')\n \ndef main():\n N_array = 10000\n N_py = 200\n N_c = 10000\n \n ratio = float(N_c) / N_py \n \n arr = [0]*N_array\n t1 = time.time()\n for i in xrange(N_py):\n Ramp(arr, N_array, 0.0, 1.0)\n t2 = time.time()\n py_time = (t2 - t1) * ratio\n print 'python (seconds*ratio):', py_time\n print 'arr[500]:', arr[500]\n \n arr = array([0]*N_array,Float64)\n # First call compiles function or loads from cache.\n # I'm not including this in the timing.\n Ramp_numeric1(arr, N_array, 0.0, 1.0)\n t1 = time.time()\n for i in xrange(N_c):\n Ramp_numeric1(arr, N_array, 0.0, 1.0)\n t2 = time.time()\n c_time = (t2 - t1)\n print 'compiled numeric1 (seconds, speed up):', c_time, py_time/ c_time\n print 'arr[500]:', arr[500]\n\n arr2 = array([0]*N_array,Float64)\n # First call compiles function or loads from cache.\n # I'm not including this in the timing.\n Ramp_numeric2(arr, N_array, 0.0, 1.0)\n t1 = time.time()\n for i in xrange(N_c):\n Ramp_numeric2(arr, N_array, 0.0, 1.0)\n t2 = time.time()\n c_time = (t2 - t1) \n print 'compiled numeric2 (seconds, speed up):', c_time, py_time/ c_time\n print 'arr[500]:', arr[500]\n \nif __name__ == '__main__':\n main()", "source_code_before": null, "methods": [ { "name": "Ramp", "long_name": "Ramp( result , size , start , end )", "filename": "ramp.py", "nloc": 4, "complexity": 2, "token_count": 42, "parameters": [ "result", "size", "start", "end" ], "start_line": 5, "end_line": 8, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 0 }, { "name": "Ramp_numeric1", "long_name": "Ramp_numeric1( result , size , start , end )", "filename": "ramp.py", "nloc": 8, "complexity": 1, "token_count": 34, "parameters": [ "result", "size", "start", "end" ], "start_line": 10, "end_line": 17, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 0 }, { "name": "Ramp_numeric2", "long_name": "Ramp_numeric2( result , size , start , end )", "filename": "ramp.py", "nloc": 11, "complexity": 1, "token_count": 34, "parameters": [ "result", "size", "start", "end" ], "start_line": 19, "end_line": 29, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 }, { "name": "main", "long_name": "main( )", "filename": "ramp.py", "nloc": 31, "complexity": 4, "token_count": 252, "parameters": [], "start_line": 31, "end_line": 69, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 39, "top_nesting_level": 0 } ], "methods_before": [], "changed_methods": [ { "name": "Ramp", "long_name": "Ramp( result , size , start , end )", "filename": "ramp.py", "nloc": 4, "complexity": 2, "token_count": 42, "parameters": [ "result", "size", "start", "end" ], "start_line": 5, "end_line": 8, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 0 }, { "name": "main", "long_name": "main( )", "filename": "ramp.py", "nloc": 31, "complexity": 4, "token_count": 252, "parameters": [], "start_line": 31, "end_line": 69, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 39, "top_nesting_level": 0 }, { "name": "Ramp_numeric1", "long_name": "Ramp_numeric1( result , size , start , end )", "filename": "ramp.py", "nloc": 8, "complexity": 1, "token_count": 34, "parameters": [ "result", "size", "start", "end" ], "start_line": 10, "end_line": 17, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 8, "top_nesting_level": 0 }, { "name": "Ramp_numeric2", "long_name": "Ramp_numeric2( result , size , start , end )", "filename": "ramp.py", "nloc": 11, "complexity": 1, "token_count": 34, "parameters": [ "result", "size", "start", "end" ], "start_line": 19, "end_line": 29, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 11, "top_nesting_level": 0 } ], "nloc": 59, "complexity": 8, "token_count": 382, "diff_parsed": { "added": [ "import time", "import weave", "from Numeric import *", "", "def Ramp(result, size, start, end):", " step = (end-start)/(size-1)", " for i in xrange(size):", " result[i] = start + step*i", "", "def Ramp_numeric1(result,size,start,end):", " code = \"\"\"", " double step = (end-start)/(size-1);", " double val = start;", " for (int i = 0; i < size; i++)", " *result_data++ = start + step*i;", " \"\"\"", " weave.inline(code,['result','size','start','end'],compiler='gcc')", "", "def Ramp_numeric2(result,size,start,end):", " code = \"\"\"", " double step = (end-start)/(size-1);", " double val = start;", " for (int i = 0; i < size; i++)", " {", " result_data[i] = val;", " val += step;", " }", " \"\"\"", " weave.inline(code,['result','size','start','end'],compiler='gcc')", "", "def main():", " N_array = 10000", " N_py = 200", " N_c = 10000", "", " ratio = float(N_c) / N_py", "", " arr = [0]*N_array", " t1 = time.time()", " for i in xrange(N_py):", " Ramp(arr, N_array, 0.0, 1.0)", " t2 = time.time()", " py_time = (t2 - t1) * ratio", " print 'python (seconds*ratio):', py_time", " print 'arr[500]:', arr[500]", "", " arr = array([0]*N_array,Float64)", " # First call compiles function or loads from cache.", " # I'm not including this in the timing.", " Ramp_numeric1(arr, N_array, 0.0, 1.0)", " t1 = time.time()", " for i in xrange(N_c):", " Ramp_numeric1(arr, N_array, 0.0, 1.0)", " t2 = time.time()", " c_time = (t2 - t1)", " print 'compiled numeric1 (seconds, speed up):', c_time, py_time/ c_time", " print 'arr[500]:', arr[500]", "", " arr2 = array([0]*N_array,Float64)", " # First call compiles function or loads from cache.", " # I'm not including this in the timing.", " Ramp_numeric2(arr, N_array, 0.0, 1.0)", " t1 = time.time()", " for i in xrange(N_c):", " Ramp_numeric2(arr, N_array, 0.0, 1.0)", " t2 = time.time()", " c_time = (t2 - t1)", " print 'compiled numeric2 (seconds, speed up):', c_time, py_time/ c_time", " print 'arr[500]:', arr[500]", "", "if __name__ == '__main__':", " main()" ], "deleted": [] } }, { "old_path": null, "new_path": "weave/examples/ramp2.py", "filename": "ramp2.py", "extension": "py", "change_type": "ADD", "diff": "@@ -0,0 +1,54 @@\n+import time\n+from weave import ext_tools\n+from Numeric import *\n+\n+def Ramp(result, size, start, end):\n+ step = (end-start)/(size-1)\n+ for i in xrange(size):\n+ result[i] = start + step*i\n+\n+def build_ramp_ext():\n+ mod = ext_tools.ext_module('ramp_ext')\n+ \n+ # type declarations\n+ result = array([0],Float64)\n+ size,start,end = 0,0.,0.\n+ code = \"\"\"\n+ double step = (end-start)/(size-1);\n+ double val = start;\n+ for (int i = 0; i < size; i++)\n+ {\n+ result_data[i] = val;\n+ val += step; \n+ }\n+ \"\"\"\n+ func = ext_tools.ext_function('Ramp',code,['result','size','start','end'])\n+ mod.add_function(func)\n+ mod.compile(compiler='gcc')\n+ \n+def main(): \n+ arr = [0]*10000\n+ t1 = time.time()\n+ for i in xrange(200):\n+ Ramp(arr, 10000, 0.0, 1.0)\n+ t2 = time.time()\n+ py_time = t2 - t1\n+ print 'python (seconds):', py_time\n+ print 'arr[500]:', arr[500]\n+ print\n+ \n+ try:\n+ import ramp_ext\n+ except:\n+ build_ramp_ext()\n+ import ramp_ext\n+ arr = array([0]*10000,Float64)\n+ for i in xrange(10000):\n+ ramp_ext.Ramp(arr, 10000, 0.0, 1.0)\n+ t2 = time.time()\n+ c_time = (t2 - t1) \n+ print 'compiled numeric (seconds, speed up):', c_time, (py_time*10000/200.)/ c_time\n+ print 'arr[500]:', arr[500]\n+ \n+if __name__ == '__main__':\n+ main()\n\\ No newline at end of file\n", "added_lines": 54, "deleted_lines": 0, "source_code": "import time\nfrom weave import ext_tools\nfrom Numeric import *\n\ndef Ramp(result, size, start, end):\n step = (end-start)/(size-1)\n for i in xrange(size):\n result[i] = start + step*i\n\ndef build_ramp_ext():\n mod = ext_tools.ext_module('ramp_ext')\n \n # type declarations\n result = array([0],Float64)\n size,start,end = 0,0.,0.\n code = \"\"\"\n double step = (end-start)/(size-1);\n double val = start;\n for (int i = 0; i < size; i++)\n {\n result_data[i] = val;\n val += step; \n }\n \"\"\"\n func = ext_tools.ext_function('Ramp',code,['result','size','start','end'])\n mod.add_function(func)\n mod.compile(compiler='gcc')\n \ndef main(): \n arr = [0]*10000\n t1 = time.time()\n for i in xrange(200):\n Ramp(arr, 10000, 0.0, 1.0)\n t2 = time.time()\n py_time = t2 - t1\n print 'python (seconds):', py_time\n print 'arr[500]:', arr[500]\n print\n \n try:\n import ramp_ext\n except:\n build_ramp_ext()\n import ramp_ext\n arr = array([0]*10000,Float64)\n for i in xrange(10000):\n ramp_ext.Ramp(arr, 10000, 0.0, 1.0)\n t2 = time.time()\n c_time = (t2 - t1) \n print 'compiled numeric (seconds, speed up):', c_time, (py_time*10000/200.)/ c_time\n print 'arr[500]:', arr[500]\n \nif __name__ == '__main__':\n main()", "source_code_before": null, "methods": [ { "name": "Ramp", "long_name": "Ramp( result , size , start , end )", "filename": "ramp2.py", "nloc": 4, "complexity": 2, "token_count": 42, "parameters": [ "result", "size", "start", "end" ], "start_line": 5, "end_line": 8, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 0 }, { "name": "build_ramp_ext", "long_name": "build_ramp_ext( )", "filename": "ramp2.py", "nloc": 16, "complexity": 1, "token_count": 72, "parameters": [], "start_line": 10, "end_line": 27, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 0 }, { "name": "main", "long_name": "main( )", "filename": "ramp2.py", "nloc": 22, "complexity": 4, "token_count": 147, "parameters": [], "start_line": 29, "end_line": 51, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 0 } ], "methods_before": [], "changed_methods": [ { "name": "build_ramp_ext", "long_name": "build_ramp_ext( )", "filename": "ramp2.py", "nloc": 16, "complexity": 1, "token_count": 72, "parameters": [], "start_line": 10, "end_line": 27, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 18, "top_nesting_level": 0 }, { "name": "Ramp", "long_name": "Ramp( result , size , start , end )", "filename": "ramp2.py", "nloc": 4, "complexity": 2, "token_count": 42, "parameters": [ "result", "size", "start", "end" ], "start_line": 5, "end_line": 8, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 0 }, { "name": "main", "long_name": "main( )", "filename": "ramp2.py", "nloc": 22, "complexity": 4, "token_count": 147, "parameters": [], "start_line": 29, "end_line": 51, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 0 } ], "nloc": 47, "complexity": 7, "token_count": 282, "diff_parsed": { "added": [ "import time", "from weave import ext_tools", "from Numeric import *", "", "def Ramp(result, size, start, end):", " step = (end-start)/(size-1)", " for i in xrange(size):", " result[i] = start + step*i", "", "def build_ramp_ext():", " mod = ext_tools.ext_module('ramp_ext')", "", " # type declarations", " result = array([0],Float64)", " size,start,end = 0,0.,0.", " code = \"\"\"", " double step = (end-start)/(size-1);", " double val = start;", " for (int i = 0; i < size; i++)", " {", " result_data[i] = val;", " val += step;", " }", " \"\"\"", " func = ext_tools.ext_function('Ramp',code,['result','size','start','end'])", " mod.add_function(func)", " mod.compile(compiler='gcc')", "", "def main():", " arr = [0]*10000", " t1 = time.time()", " for i in xrange(200):", " Ramp(arr, 10000, 0.0, 1.0)", " t2 = time.time()", " py_time = t2 - t1", " print 'python (seconds):', py_time", " print 'arr[500]:', arr[500]", " print", "", " try:", " import ramp_ext", " except:", " build_ramp_ext()", " import ramp_ext", " arr = array([0]*10000,Float64)", " for i in xrange(10000):", " ramp_ext.Ramp(arr, 10000, 0.0, 1.0)", " t2 = time.time()", " c_time = (t2 - t1)", " print 'compiled numeric (seconds, speed up):', c_time, (py_time*10000/200.)/ c_time", " print 'arr[500]:', arr[500]", "", "if __name__ == '__main__':", " main()" ], "deleted": [] } } ] }, { "hash": "556e691b9b82db9053a73a5ee5158988cd8d65bf", "msg": "Prabhu found an issue in his test run where we try to delete a path_key that isn't available. THis can occur is a built-in function is added to catalog. built-ins do not have a path to their module (they are builtin after all). We now check to make sure that the catalog has the key before deleting it.", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-06T17:40:43+00:00", "author_timezone": 0, "committer_date": "2002-01-06T17:40:43+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "a0515424696067f0b63dd295c5fb6df1bd31e444" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 2, "insertions": 8, "lines": 10, "files": 1, "dmm_unit_size": 0.0, "dmm_unit_complexity": 1.0, "dmm_unit_interfacing": 0.0, "modified_files": [ { "old_path": "weave/catalog.py", "new_path": "weave/catalog.py", "filename": "catalog.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -450,8 +450,14 @@ def repair_catalog(self,catalog_path,code):\n return \n if writable_cat.has_key(code):\n print 'repairing catalog by removing key'\n- del writable_cat[code] \n- del writable_cat[self.path_key(code)] \n+ del writable_cat[code]\n+ \n+ # it is possible that the path key doesn't exist (if the function registered\n+ # was a built-in function), so we have to check if the path exists before\n+ # arbitrarily deleting it.\n+ path_key = self.path_key(code) \n+ if writable_cat.has_key(path_key)\n+ del writable_cat[path_key] \n \n def get_functions_fast(self,code):\n \"\"\" Return list of functions for code from the cache.\n", "added_lines": 8, "deleted_lines": 2, "source_code": "\"\"\" Track relationships between compiled extension functions & code fragments\n\n catalog keeps track of which compiled(or even standard) functions are \n related to which code fragments. It also stores these relationships\n to disk so they are remembered between Python sessions. When \n \n a = 1\n compiler.inline('printf(\"printed from C: %d\",a);',['a'] )\n \n is called, inline() first looks to see if it has seen the code \n 'printf(\"printed from C\");' before. If not, it calls \n \n catalog.get_functions('printf(\"printed from C: %d\", a);')\n \n which returns a list of all the function objects that have been compiled\n for the code fragment. Multiple functions can occur because the code\n could be compiled for different types for 'a' (although not likely in\n this case). The catalog first looks in its cache and quickly returns\n a list of the functions if possible. If the cache lookup fails, it then\n looks through possibly multiple catalog files on disk and fills its\n cache with all the functions that match the code fragment. \n \n In case where the code fragment hasn't been compiled, inline() compiles\n the code and then adds it to the catalog:\n \n function = \n catalog.add_function('printf(\"printed from C: %d\", a);',function)\n \n add_function() adds function to the front of the cache. function,\n along with the path information to its module, are also stored in a\n persistent catalog for future use by python sessions. \n\"\"\" \n\nimport os,sys,string\nimport shelve\n\ndef getmodule(object):\n \"\"\" Discover the name of the module where object was defined.\n \n This is an augmented version of inspect.getmodule that can discover \n the parent module for extension functions.\n \"\"\"\n import inspect\n value = inspect.getmodule(object)\n if value is None:\n #walk trough all modules looking for function\n for name,mod in sys.modules.items():\n # try except used because of some comparison failures\n # in wxPoint code. Need to review this\n try:\n if mod and object in mod.__dict__.values():\n value = mod\n # if it is a built-in module, keep looking to see\n # if a non-builtin also has it. Otherwise quit and\n # consider the module found. (ain't perfect, but will \n # have to do for now).\n if string.find('(built-in)',str(mod)) is -1:\n break\n \n except TypeError:\n pass \n return value\n\ndef expr_to_filename(expr):\n \"\"\" Convert an arbitrary expr string to a valid file name.\n \n The name is based on the md5 check sum for the string and\n Something that was a little more human readable would be \n nice, but the computer doesn't seem to care.\n \"\"\"\n import md5\n base = 'sc_'\n return base + md5.new(expr).hexdigest()\n\ndef unique_file(d,expr):\n \"\"\" Generate a unqiue file name based on expr in directory d\n \n This is meant for use with building extension modules, so\n a file name is considered unique if none of the following\n extension '.cpp','.o','.so','module.so','.py', or '.pyd'\n exists in directory d. The fully qualified path to the\n new name is returned. You'll need to append your own\n extension to it before creating files.\n \"\"\"\n files = os.listdir(d)\n #base = 'scipy_compile'\n base = expr_to_filename(expr)\n for i in range(1000000):\n fname = base + `i`\n if not (fname+'.cpp' in files or\n fname+'.o' in files or\n fname+'.so' in files or\n fname+'module.so' in files or\n fname+'.py' in files or\n fname+'.pyd' in files):\n break\n return os.path.join(d,fname)\n \ndef default_dir():\n \"\"\" Return a default location to store compiled files and catalogs.\n \n XX is the Python version number in all paths listed below\n On windows, the default location is the temporary directory\n returned by gettempdir()/pythonXX.\n \n On Unix, ~/.pythonXX_compiled is the default location. If it doesn't\n exist, it is created. The directory is marked rwx------.\n \n If for some reason it isn't possible to build a default directory\n in the user's home, /tmp/_pythonXX_compiled is used. If it \n doesn't exist, it is created. The directory is marked rwx------\n to try and keep people from being able to sneak a bad module\n in on you. \n \"\"\"\n import tempfile \n python_name = \"python%d%d_compiled\" % tuple(sys.version_info[:2]) \n if sys.platform != 'win32':\n try:\n path = os.path.join(os.environ['HOME'],'.' + python_name)\n except KeyError:\n temp_dir = `os.getuid()` + '_' + python_name\n path = os.path.join(tempfile.gettempdir(),temp_dir) \n else:\n path = os.path.join(tempfile.gettempdir(),python_name)\n \n if not os.path.exists(path):\n os.mkdir(path)\n os.chmod(path,0700) # make it only accessible by this user.\n if not os.access(path,os.W_OK):\n print 'warning: default directory is not write accessible.'\n print 'defualt:', path\n return path\n\ndef default_temp_dir():\n path = os.path.join(default_dir(),'temp')\n if not os.path.exists(path):\n os.mkdir(path)\n os.chmod(path,0700) # make it only accessible by this user.\n if not os.access(path,os.W_OK):\n print 'warning: default directory is not write accessible.'\n print 'defualt:', path\n return path\n\n \ndef os_dependent_catalog_name():\n \"\"\" Generate catalog name dependent on OS and Python version being used.\n \n This allows multiple platforms to have catalog files in the\n same directory without stepping on each other. For now, it \n bases the name of the value returned by sys.platform and the\n version of python being run. If this isn't enough to descriminate\n on some platforms, we can try to add other info. It has \n occured to me that if we get fancy enough to optimize for different\n architectures, then chip type might be added to the catalog name also.\n \"\"\"\n version = '%d%d' % sys.version_info[:2]\n return sys.platform+version+'compiled_catalog'\n \ndef catalog_path(module_path):\n \"\"\" Return the full path name for the catalog file in the given directory.\n \n module_path can either be a file name or a path name. If it is a \n file name, the catalog file name in its parent directory is returned.\n If it is a directory, the catalog file in that directory is returned.\n\n If module_path doesn't exist, None is returned. Note though, that the\n catalog file does *not* have to exist, only its parent. '~', shell\n variables, and relative ('.' and '..') paths are all acceptable.\n \n catalog file names are os dependent (based on sys.platform), so this \n should support multiple platforms sharing the same disk space \n (NFS mounts). See os_dependent_catalog_name() for more info.\n \"\"\"\n module_path = os.path.expanduser(module_path)\n module_path = os.path.expandvars(module_path)\n module_path = os.path.abspath(module_path)\n if not os.path.exists(module_path):\n catalog_file = None\n elif not os.path.isdir(module_path):\n module_path,dummy = os.path.split(module_path)\n catalog_file = os.path.join(module_path,os_dependent_catalog_name())\n else: \n catalog_file = os.path.join(module_path,os_dependent_catalog_name())\n return catalog_file\n\ndef get_catalog(module_path,mode='r'):\n \"\"\" Return a function catalog (shelve object) from the path module_path\n\n If module_path is a directory, the function catalog returned is\n from that directory. If module_path is an actual module_name,\n then the function catalog returned is from its parent directory.\n mode uses the standard 'c' = create, 'r' = read, 'w' = write\n file open modes.\n \n See catalog_path() for more information on module_path.\n \"\"\"\n catalog_file = catalog_path(module_path)\n #print catalog_file\n #sh = shelve.open(catalog_file,mode)\n try:\n sh = shelve.open(catalog_file,mode)\n except: # not sure how to pin down which error to catch yet\n sh = None\n return sh\n\nclass catalog:\n \"\"\" Stores information about compiled functions both in cache and on disk.\n \n catalog stores (code, list_of_function) pairs so that all the functions\n that have been compiled for code are available for calling (usually in\n inline or blitz).\n \n catalog keeps a dictionary of previously accessed code values cached \n for quick access. It also handles the looking up of functions compiled \n in previously called Python sessions on disk in function catalogs. \n catalog searches the directories in the PYTHONCOMPILED environment \n variable in order loading functions that correspond to the given code \n fragment. A default directory is also searched for catalog functions. \n On unix, the default directory is usually '~/.pythonxx_compiled' where \n xx is the version of Python used. On windows, it is the directory \n returned by temfile.gettempdir(). Functions closer to the front are of \n the variable list are guaranteed to be closer to the front of the \n function list so that they will be called first. See \n get_cataloged_functions() for more info on how the search order is \n traversed.\n \n Catalog also handles storing information about compiled functions to\n a catalog. When writing this information, the first writable catalog\n file in PYTHONCOMPILED path is used. If a writable catalog is not\n found, it is written to the catalog in the default directory. This\n directory should always be writable.\n \"\"\"\n def __init__(self,user_path_list=None):\n \"\"\" Create a catalog for storing/searching for compiled functions. \n \n user_path_list contains directories that should be searched \n first for function catalogs. They will come before the path\n entries in the PYTHONCOMPILED environment varilable.\n \"\"\"\n if type(user_path_list) == type('string'):\n self.user_path_list = [user_path_list]\n elif user_path_list:\n self.user_path_list = user_path_list\n else:\n self.user_path_list = []\n self.cache = {}\n self.module_dir = None\n self.paths_added = 0\n \n def set_module_directory(self,module_dir):\n \"\"\" Set the path that will replace 'MODULE' in catalog searches.\n \n You should call clear_module_directory() when your finished\n working with it.\n \"\"\"\n self.module_dir = module_dir\n def get_module_directory(self):\n \"\"\" Return the path used to replace the 'MODULE' in searches.\n \"\"\"\n return self.module_dir\n def clear_module_directory(self):\n \"\"\" Reset 'MODULE' path to None so that it is ignored in searches. \n \"\"\"\n self.module_dir = None\n \n def get_environ_path(self):\n \"\"\" Return list of paths from 'PYTHONCOMPILED' environment variable.\n \n On Unix the path in PYTHONCOMPILED is a ':' separated list of\n directories. On Windows, a ';' separated list is used. \n \"\"\"\n paths = []\n if os.environ.has_key('PYTHONCOMPILED'):\n path_string = os.environ['PYTHONCOMPILED'] \n if sys.platform == 'win32':\n #probably should also look in registry\n paths = path_string.split(';')\n else: \n paths = path_string.split(':')\n return paths \n\n def build_search_order(self):\n \"\"\" Returns a list of paths that are searched for catalogs. \n \n Values specified in the catalog constructor are searched first,\n then values found in the PYTHONCOMPILED environment variable.\n The directory returned by default_dir() is always returned at\n the end of the list.\n \n There is a 'magic' path name called 'MODULE' that is replaced\n by the directory defined by set_module_directory(). If the\n module directory hasn't been set, 'MODULE' is ignored.\n \"\"\"\n \n paths = self.user_path_list + self.get_environ_path()\n search_order = []\n for path in paths:\n if path == 'MODULE':\n if self.module_dir:\n search_order.append(self.module_dir)\n else:\n search_order.append(path)\n search_order.append(default_dir())\n return search_order\n\n def get_catalog_files(self):\n \"\"\" Returns catalog file list in correct search order.\n \n Some of the catalog files may not currently exists.\n However, all will be valid locations for a catalog\n to be created (if you have write permission).\n \"\"\"\n files = map(catalog_path,self.build_search_order())\n files = filter(lambda x: x is not None,files)\n return files\n\n def get_existing_files(self):\n \"\"\" Returns all existing catalog file list in correct search order.\n \"\"\"\n files = self.get_catalog_files()\n existing_files = filter(os.path.exists,files)\n return existing_files\n\n def get_writable_file(self,existing_only=0):\n \"\"\" Return the name of the first writable catalog file.\n \n Its parent directory must also be writable. This is so that\n compiled modules can be written to the same directory.\n \"\"\"\n # note: both file and its parent directory must be writeable\n if existing_only:\n files = self.get_existing_files()\n else:\n files = self.get_catalog_files()\n # filter for (file exists and is writable) OR directory is writable\n def file_test(x):\n from os import access, F_OK, W_OK\n return (access(x,F_OK) and access(x,W_OK) or\n access(os.path.dirname(x),W_OK))\n writable = filter(file_test,files)\n if writable:\n file = writable[0]\n else:\n file = None\n return file\n \n def get_writable_dir(self):\n \"\"\" Return the parent directory of first writable catalog file.\n \n The returned directory has write access.\n \"\"\"\n return os.path.dirname(self.get_writable_file())\n \n def unique_module_name(self,code,module_dir=None):\n \"\"\" Return full path to unique file name that in writable location.\n \n The directory for the file is the first writable directory in \n the catalog search path. The unique file name is derived from\n the code fragment. If, module_dir is specified, it is used\n to replace 'MODULE' in the search path.\n \"\"\"\n if module_dir is not None:\n self.set_module_directory(module_dir)\n try:\n d = self.get_writable_dir()\n finally:\n if module_dir is not None:\n self.clear_module_directory()\n return unique_file(d,code)\n\n def path_key(self,code):\n \"\"\" Return key for path information for functions associated with code.\n \"\"\"\n return '__path__' + code\n \n def configure_path(self,cat,code):\n \"\"\" Add the python path for the given code to the sys.path\n \n unconfigure_path() should be called as soon as possible after\n imports associated with code are finished so that sys.path \n is restored to normal.\n \"\"\"\n try:\n paths = cat[self.path_key(code)]\n self.paths_added = len(paths)\n sys.path = paths + sys.path\n except:\n self.paths_added = 0 \n \n def unconfigure_path(self):\n \"\"\" Restores sys.path to normal after calls to configure_path()\n \n Remove the previously added paths from sys.path\n \"\"\"\n sys.path = sys.path[self.paths_added:]\n self.paths_added = 0\n\n def get_cataloged_functions(self,code):\n \"\"\" Load all functions associated with code from catalog search path.\n \n Sometimes there can be trouble loading a function listed in a\n catalog file because the actual module that holds the function \n has been moved or deleted. When this happens, that catalog file\n is \"repaired\", meaning the entire entry for this function is \n removed from the file. This only affects the catalog file that\n has problems -- not the others in the search path.\n \n The \"repair\" behavior may not be needed, but I'll keep it for now.\n \"\"\"\n mode = 'r'\n cat = None\n function_list = []\n for path in self.build_search_order():\n cat = get_catalog(path,mode)\n if cat is not None and cat.has_key(code):\n # set up the python path so that modules for this\n # function can be loaded.\n self.configure_path(cat,code)\n try: \n function_list += cat[code]\n except: #SystemError and ImportError so far seen \n # problems loading a function from the catalog. Try to\n # repair the cause.\n cat.close()\n self.repair_catalog(path,code)\n self.unconfigure_path() \n return function_list\n\n\n def repair_catalog(self,catalog_path,code):\n \"\"\" Remove entry for code from catalog_path\n \n Occasionally catalog entries could get corrupted. An example\n would be when a module that had functions in the catalog was\n deleted or moved on the disk. The best current repair method is \n just to trash the entire catalog entry for this piece of code. \n This may loose function entries that are valid, but thats life.\n \n catalog_path must be writable for repair. If it isn't, the\n function exists with a warning. \n \"\"\"\n writable_cat = None\n if not os.path.exists(catalog_path):\n return\n try:\n writable_cat = get_catalog(catalog_path,'w')\n except:\n print 'warning: unable to repair catalog entry\\n %s\\n in\\n %s' % \\\n (code,catalog_path)\n return \n if writable_cat.has_key(code):\n print 'repairing catalog by removing key'\n del writable_cat[code]\n \n # it is possible that the path key doesn't exist (if the function registered\n # was a built-in function), so we have to check if the path exists before\n # arbitrarily deleting it.\n path_key = self.path_key(code) \n if writable_cat.has_key(path_key)\n del writable_cat[path_key] \n \n def get_functions_fast(self,code):\n \"\"\" Return list of functions for code from the cache.\n \n Return an empty list if the code entry is not found.\n \"\"\"\n return self.cache.get(code,[])\n \n def get_functions(self,code,module_dir=None):\n \"\"\" Return the list of functions associated with this code fragment.\n \n The cache is first searched for the function. If an entry\n in the cache is not found, then catalog files on disk are \n searched for the entry. This is slooooow, but only happens\n once per code object. All the functions found in catalog files\n on a cache miss are loaded into the cache to speed up future calls.\n The search order is as follows:\n \n 1. user specified path (from catalog initialization)\n 2. directories from the PYTHONCOMPILED environment variable\n 3. The temporary directory on your platform.\n\n The path specified by module_dir will replace the 'MODULE' \n place holder in the catalog search path. See build_search_order()\n for more info on the search path. \n \"\"\" \n # Fast!! try cache first.\n if self.cache.has_key(code):\n return self.cache[code]\n \n # 2. Slow!! read previously compiled functions from disk.\n try:\n self.set_module_directory(module_dir)\n function_list = self.get_cataloged_functions(code)\n if code:\n function_list\n # put function_list in cache to save future lookups.\n if function_list:\n self.cache[code] = function_list\n # return function_list, empty or otherwise.\n finally:\n self.clear_module_directory()\n return function_list\n\n def add_function(self,code,function,module_dir=None):\n \"\"\" Adds a function to the catalog.\n \n The function is added to the cache as well as the first\n writable file catalog found in the search path. If no\n code entry exists in the cache, the on disk catalogs\n are loaded into the cache and function is added to the\n beginning of the function list.\n \n The path specified by module_dir will replace the 'MODULE' \n place holder in the catalog search path. See build_search_order()\n for more info on the search path. \n \"\"\" \n\n # 1. put it in the cache.\n if self.cache.has_key(code):\n if function not in self.cache[code]:\n self.cache[code].insert(0,function)\n else: \n # Load functions and put this one up front\n self.cache[code] = self.get_functions(code) \n self.fast_cache(code,function)\n \n # 2. Store the function entry to disk. \n try:\n self.set_module_directory(module_dir)\n self.add_function_persistent(code,function)\n finally:\n self.clear_module_directory()\n \n def add_function_persistent(self,code,function):\n \"\"\" Store the code->function relationship to disk.\n \n Two pieces of information are needed for loading functions\n from disk -- the function pickle (which conveniently stores\n the module name, etc.) and the path to its module's directory.\n The latter is needed so that the function can be loaded no\n matter what the user's Python path is.\n \"\"\" \n # add function to data in first writable catalog\n mode = 'cw' # create, write\n cat_file = self.get_writable_dir()\n cat = get_catalog(cat_file,mode)\n if cat is None:\n cat_dir = default_dir()\n cat = get_catalog(cat_file,mode)\n if cat is None:\n cat_dir = default_dir() \n cat_file = catalog_path(cat_dir)\n print 'problems with default catalog -- removing'\n os.remove(cat_file)\n cat = get_catalog(cat_dir,mode)\n if cat is None:\n raise ValueError, 'Failed to access a catalog for storing functions' \n function_list = [function] + cat.get(code,[])\n cat[code] = function_list\n \n # now add needed path information for loading function\n module = getmodule(function)\n try:\n # built in modules don't have the __file__ extension, so this\n # will fail. Just pass in this case since path additions aren't\n # needed for built-in modules.\n mod_path,f=os.path.split(os.path.abspath(module.__file__))\n pkey = self.path_key(code)\n cat[pkey] = [mod_path] + cat.get(pkey,[])\n except:\n pass\n\n def fast_cache(self,code,function):\n \"\"\" Move function to the front of the cache entry for code\n \n If future calls to the function have the same type signature,\n this will speed up access significantly because the first\n function call is correct.\n \n Note: The cache added to the inline_tools module is significantly\n faster than always calling get_functions, so this isn't\n as necessary as it used to be. Still, it's probably worth\n doing. \n \"\"\"\n try:\n if self.cache[code][0] == function:\n return\n except: # KeyError, IndexError \n pass\n try:\n self.cache[code].remove(function)\n except ValueError:\n pass\n # put new function at the beginning of the list to search.\n self.cache[code].insert(0,function)\n \ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n", "source_code_before": "\"\"\" Track relationships between compiled extension functions & code fragments\n\n catalog keeps track of which compiled(or even standard) functions are \n related to which code fragments. It also stores these relationships\n to disk so they are remembered between Python sessions. When \n \n a = 1\n compiler.inline('printf(\"printed from C: %d\",a);',['a'] )\n \n is called, inline() first looks to see if it has seen the code \n 'printf(\"printed from C\");' before. If not, it calls \n \n catalog.get_functions('printf(\"printed from C: %d\", a);')\n \n which returns a list of all the function objects that have been compiled\n for the code fragment. Multiple functions can occur because the code\n could be compiled for different types for 'a' (although not likely in\n this case). The catalog first looks in its cache and quickly returns\n a list of the functions if possible. If the cache lookup fails, it then\n looks through possibly multiple catalog files on disk and fills its\n cache with all the functions that match the code fragment. \n \n In case where the code fragment hasn't been compiled, inline() compiles\n the code and then adds it to the catalog:\n \n function = \n catalog.add_function('printf(\"printed from C: %d\", a);',function)\n \n add_function() adds function to the front of the cache. function,\n along with the path information to its module, are also stored in a\n persistent catalog for future use by python sessions. \n\"\"\" \n\nimport os,sys,string\nimport shelve\n\ndef getmodule(object):\n \"\"\" Discover the name of the module where object was defined.\n \n This is an augmented version of inspect.getmodule that can discover \n the parent module for extension functions.\n \"\"\"\n import inspect\n value = inspect.getmodule(object)\n if value is None:\n #walk trough all modules looking for function\n for name,mod in sys.modules.items():\n # try except used because of some comparison failures\n # in wxPoint code. Need to review this\n try:\n if mod and object in mod.__dict__.values():\n value = mod\n # if it is a built-in module, keep looking to see\n # if a non-builtin also has it. Otherwise quit and\n # consider the module found. (ain't perfect, but will \n # have to do for now).\n if string.find('(built-in)',str(mod)) is -1:\n break\n \n except TypeError:\n pass \n return value\n\ndef expr_to_filename(expr):\n \"\"\" Convert an arbitrary expr string to a valid file name.\n \n The name is based on the md5 check sum for the string and\n Something that was a little more human readable would be \n nice, but the computer doesn't seem to care.\n \"\"\"\n import md5\n base = 'sc_'\n return base + md5.new(expr).hexdigest()\n\ndef unique_file(d,expr):\n \"\"\" Generate a unqiue file name based on expr in directory d\n \n This is meant for use with building extension modules, so\n a file name is considered unique if none of the following\n extension '.cpp','.o','.so','module.so','.py', or '.pyd'\n exists in directory d. The fully qualified path to the\n new name is returned. You'll need to append your own\n extension to it before creating files.\n \"\"\"\n files = os.listdir(d)\n #base = 'scipy_compile'\n base = expr_to_filename(expr)\n for i in range(1000000):\n fname = base + `i`\n if not (fname+'.cpp' in files or\n fname+'.o' in files or\n fname+'.so' in files or\n fname+'module.so' in files or\n fname+'.py' in files or\n fname+'.pyd' in files):\n break\n return os.path.join(d,fname)\n \ndef default_dir():\n \"\"\" Return a default location to store compiled files and catalogs.\n \n XX is the Python version number in all paths listed below\n On windows, the default location is the temporary directory\n returned by gettempdir()/pythonXX.\n \n On Unix, ~/.pythonXX_compiled is the default location. If it doesn't\n exist, it is created. The directory is marked rwx------.\n \n If for some reason it isn't possible to build a default directory\n in the user's home, /tmp/_pythonXX_compiled is used. If it \n doesn't exist, it is created. The directory is marked rwx------\n to try and keep people from being able to sneak a bad module\n in on you. \n \"\"\"\n import tempfile \n python_name = \"python%d%d_compiled\" % tuple(sys.version_info[:2]) \n if sys.platform != 'win32':\n try:\n path = os.path.join(os.environ['HOME'],'.' + python_name)\n except KeyError:\n temp_dir = `os.getuid()` + '_' + python_name\n path = os.path.join(tempfile.gettempdir(),temp_dir) \n else:\n path = os.path.join(tempfile.gettempdir(),python_name)\n \n if not os.path.exists(path):\n os.mkdir(path)\n os.chmod(path,0700) # make it only accessible by this user.\n if not os.access(path,os.W_OK):\n print 'warning: default directory is not write accessible.'\n print 'defualt:', path\n return path\n\ndef default_temp_dir():\n path = os.path.join(default_dir(),'temp')\n if not os.path.exists(path):\n os.mkdir(path)\n os.chmod(path,0700) # make it only accessible by this user.\n if not os.access(path,os.W_OK):\n print 'warning: default directory is not write accessible.'\n print 'defualt:', path\n return path\n\n \ndef os_dependent_catalog_name():\n \"\"\" Generate catalog name dependent on OS and Python version being used.\n \n This allows multiple platforms to have catalog files in the\n same directory without stepping on each other. For now, it \n bases the name of the value returned by sys.platform and the\n version of python being run. If this isn't enough to descriminate\n on some platforms, we can try to add other info. It has \n occured to me that if we get fancy enough to optimize for different\n architectures, then chip type might be added to the catalog name also.\n \"\"\"\n version = '%d%d' % sys.version_info[:2]\n return sys.platform+version+'compiled_catalog'\n \ndef catalog_path(module_path):\n \"\"\" Return the full path name for the catalog file in the given directory.\n \n module_path can either be a file name or a path name. If it is a \n file name, the catalog file name in its parent directory is returned.\n If it is a directory, the catalog file in that directory is returned.\n\n If module_path doesn't exist, None is returned. Note though, that the\n catalog file does *not* have to exist, only its parent. '~', shell\n variables, and relative ('.' and '..') paths are all acceptable.\n \n catalog file names are os dependent (based on sys.platform), so this \n should support multiple platforms sharing the same disk space \n (NFS mounts). See os_dependent_catalog_name() for more info.\n \"\"\"\n module_path = os.path.expanduser(module_path)\n module_path = os.path.expandvars(module_path)\n module_path = os.path.abspath(module_path)\n if not os.path.exists(module_path):\n catalog_file = None\n elif not os.path.isdir(module_path):\n module_path,dummy = os.path.split(module_path)\n catalog_file = os.path.join(module_path,os_dependent_catalog_name())\n else: \n catalog_file = os.path.join(module_path,os_dependent_catalog_name())\n return catalog_file\n\ndef get_catalog(module_path,mode='r'):\n \"\"\" Return a function catalog (shelve object) from the path module_path\n\n If module_path is a directory, the function catalog returned is\n from that directory. If module_path is an actual module_name,\n then the function catalog returned is from its parent directory.\n mode uses the standard 'c' = create, 'r' = read, 'w' = write\n file open modes.\n \n See catalog_path() for more information on module_path.\n \"\"\"\n catalog_file = catalog_path(module_path)\n #print catalog_file\n #sh = shelve.open(catalog_file,mode)\n try:\n sh = shelve.open(catalog_file,mode)\n except: # not sure how to pin down which error to catch yet\n sh = None\n return sh\n\nclass catalog:\n \"\"\" Stores information about compiled functions both in cache and on disk.\n \n catalog stores (code, list_of_function) pairs so that all the functions\n that have been compiled for code are available for calling (usually in\n inline or blitz).\n \n catalog keeps a dictionary of previously accessed code values cached \n for quick access. It also handles the looking up of functions compiled \n in previously called Python sessions on disk in function catalogs. \n catalog searches the directories in the PYTHONCOMPILED environment \n variable in order loading functions that correspond to the given code \n fragment. A default directory is also searched for catalog functions. \n On unix, the default directory is usually '~/.pythonxx_compiled' where \n xx is the version of Python used. On windows, it is the directory \n returned by temfile.gettempdir(). Functions closer to the front are of \n the variable list are guaranteed to be closer to the front of the \n function list so that they will be called first. See \n get_cataloged_functions() for more info on how the search order is \n traversed.\n \n Catalog also handles storing information about compiled functions to\n a catalog. When writing this information, the first writable catalog\n file in PYTHONCOMPILED path is used. If a writable catalog is not\n found, it is written to the catalog in the default directory. This\n directory should always be writable.\n \"\"\"\n def __init__(self,user_path_list=None):\n \"\"\" Create a catalog for storing/searching for compiled functions. \n \n user_path_list contains directories that should be searched \n first for function catalogs. They will come before the path\n entries in the PYTHONCOMPILED environment varilable.\n \"\"\"\n if type(user_path_list) == type('string'):\n self.user_path_list = [user_path_list]\n elif user_path_list:\n self.user_path_list = user_path_list\n else:\n self.user_path_list = []\n self.cache = {}\n self.module_dir = None\n self.paths_added = 0\n \n def set_module_directory(self,module_dir):\n \"\"\" Set the path that will replace 'MODULE' in catalog searches.\n \n You should call clear_module_directory() when your finished\n working with it.\n \"\"\"\n self.module_dir = module_dir\n def get_module_directory(self):\n \"\"\" Return the path used to replace the 'MODULE' in searches.\n \"\"\"\n return self.module_dir\n def clear_module_directory(self):\n \"\"\" Reset 'MODULE' path to None so that it is ignored in searches. \n \"\"\"\n self.module_dir = None\n \n def get_environ_path(self):\n \"\"\" Return list of paths from 'PYTHONCOMPILED' environment variable.\n \n On Unix the path in PYTHONCOMPILED is a ':' separated list of\n directories. On Windows, a ';' separated list is used. \n \"\"\"\n paths = []\n if os.environ.has_key('PYTHONCOMPILED'):\n path_string = os.environ['PYTHONCOMPILED'] \n if sys.platform == 'win32':\n #probably should also look in registry\n paths = path_string.split(';')\n else: \n paths = path_string.split(':')\n return paths \n\n def build_search_order(self):\n \"\"\" Returns a list of paths that are searched for catalogs. \n \n Values specified in the catalog constructor are searched first,\n then values found in the PYTHONCOMPILED environment variable.\n The directory returned by default_dir() is always returned at\n the end of the list.\n \n There is a 'magic' path name called 'MODULE' that is replaced\n by the directory defined by set_module_directory(). If the\n module directory hasn't been set, 'MODULE' is ignored.\n \"\"\"\n \n paths = self.user_path_list + self.get_environ_path()\n search_order = []\n for path in paths:\n if path == 'MODULE':\n if self.module_dir:\n search_order.append(self.module_dir)\n else:\n search_order.append(path)\n search_order.append(default_dir())\n return search_order\n\n def get_catalog_files(self):\n \"\"\" Returns catalog file list in correct search order.\n \n Some of the catalog files may not currently exists.\n However, all will be valid locations for a catalog\n to be created (if you have write permission).\n \"\"\"\n files = map(catalog_path,self.build_search_order())\n files = filter(lambda x: x is not None,files)\n return files\n\n def get_existing_files(self):\n \"\"\" Returns all existing catalog file list in correct search order.\n \"\"\"\n files = self.get_catalog_files()\n existing_files = filter(os.path.exists,files)\n return existing_files\n\n def get_writable_file(self,existing_only=0):\n \"\"\" Return the name of the first writable catalog file.\n \n Its parent directory must also be writable. This is so that\n compiled modules can be written to the same directory.\n \"\"\"\n # note: both file and its parent directory must be writeable\n if existing_only:\n files = self.get_existing_files()\n else:\n files = self.get_catalog_files()\n # filter for (file exists and is writable) OR directory is writable\n def file_test(x):\n from os import access, F_OK, W_OK\n return (access(x,F_OK) and access(x,W_OK) or\n access(os.path.dirname(x),W_OK))\n writable = filter(file_test,files)\n if writable:\n file = writable[0]\n else:\n file = None\n return file\n \n def get_writable_dir(self):\n \"\"\" Return the parent directory of first writable catalog file.\n \n The returned directory has write access.\n \"\"\"\n return os.path.dirname(self.get_writable_file())\n \n def unique_module_name(self,code,module_dir=None):\n \"\"\" Return full path to unique file name that in writable location.\n \n The directory for the file is the first writable directory in \n the catalog search path. The unique file name is derived from\n the code fragment. If, module_dir is specified, it is used\n to replace 'MODULE' in the search path.\n \"\"\"\n if module_dir is not None:\n self.set_module_directory(module_dir)\n try:\n d = self.get_writable_dir()\n finally:\n if module_dir is not None:\n self.clear_module_directory()\n return unique_file(d,code)\n\n def path_key(self,code):\n \"\"\" Return key for path information for functions associated with code.\n \"\"\"\n return '__path__' + code\n \n def configure_path(self,cat,code):\n \"\"\" Add the python path for the given code to the sys.path\n \n unconfigure_path() should be called as soon as possible after\n imports associated with code are finished so that sys.path \n is restored to normal.\n \"\"\"\n try:\n paths = cat[self.path_key(code)]\n self.paths_added = len(paths)\n sys.path = paths + sys.path\n except:\n self.paths_added = 0 \n \n def unconfigure_path(self):\n \"\"\" Restores sys.path to normal after calls to configure_path()\n \n Remove the previously added paths from sys.path\n \"\"\"\n sys.path = sys.path[self.paths_added:]\n self.paths_added = 0\n\n def get_cataloged_functions(self,code):\n \"\"\" Load all functions associated with code from catalog search path.\n \n Sometimes there can be trouble loading a function listed in a\n catalog file because the actual module that holds the function \n has been moved or deleted. When this happens, that catalog file\n is \"repaired\", meaning the entire entry for this function is \n removed from the file. This only affects the catalog file that\n has problems -- not the others in the search path.\n \n The \"repair\" behavior may not be needed, but I'll keep it for now.\n \"\"\"\n mode = 'r'\n cat = None\n function_list = []\n for path in self.build_search_order():\n cat = get_catalog(path,mode)\n if cat is not None and cat.has_key(code):\n # set up the python path so that modules for this\n # function can be loaded.\n self.configure_path(cat,code)\n try: \n function_list += cat[code]\n except: #SystemError and ImportError so far seen \n # problems loading a function from the catalog. Try to\n # repair the cause.\n cat.close()\n self.repair_catalog(path,code)\n self.unconfigure_path() \n return function_list\n\n\n def repair_catalog(self,catalog_path,code):\n \"\"\" Remove entry for code from catalog_path\n \n Occasionally catalog entries could get corrupted. An example\n would be when a module that had functions in the catalog was\n deleted or moved on the disk. The best current repair method is \n just to trash the entire catalog entry for this piece of code. \n This may loose function entries that are valid, but thats life.\n \n catalog_path must be writable for repair. If it isn't, the\n function exists with a warning. \n \"\"\"\n writable_cat = None\n if not os.path.exists(catalog_path):\n return\n try:\n writable_cat = get_catalog(catalog_path,'w')\n except:\n print 'warning: unable to repair catalog entry\\n %s\\n in\\n %s' % \\\n (code,catalog_path)\n return \n if writable_cat.has_key(code):\n print 'repairing catalog by removing key'\n del writable_cat[code] \n del writable_cat[self.path_key(code)] \n \n def get_functions_fast(self,code):\n \"\"\" Return list of functions for code from the cache.\n \n Return an empty list if the code entry is not found.\n \"\"\"\n return self.cache.get(code,[])\n \n def get_functions(self,code,module_dir=None):\n \"\"\" Return the list of functions associated with this code fragment.\n \n The cache is first searched for the function. If an entry\n in the cache is not found, then catalog files on disk are \n searched for the entry. This is slooooow, but only happens\n once per code object. All the functions found in catalog files\n on a cache miss are loaded into the cache to speed up future calls.\n The search order is as follows:\n \n 1. user specified path (from catalog initialization)\n 2. directories from the PYTHONCOMPILED environment variable\n 3. The temporary directory on your platform.\n\n The path specified by module_dir will replace the 'MODULE' \n place holder in the catalog search path. See build_search_order()\n for more info on the search path. \n \"\"\" \n # Fast!! try cache first.\n if self.cache.has_key(code):\n return self.cache[code]\n \n # 2. Slow!! read previously compiled functions from disk.\n try:\n self.set_module_directory(module_dir)\n function_list = self.get_cataloged_functions(code)\n if code:\n function_list\n # put function_list in cache to save future lookups.\n if function_list:\n self.cache[code] = function_list\n # return function_list, empty or otherwise.\n finally:\n self.clear_module_directory()\n return function_list\n\n def add_function(self,code,function,module_dir=None):\n \"\"\" Adds a function to the catalog.\n \n The function is added to the cache as well as the first\n writable file catalog found in the search path. If no\n code entry exists in the cache, the on disk catalogs\n are loaded into the cache and function is added to the\n beginning of the function list.\n \n The path specified by module_dir will replace the 'MODULE' \n place holder in the catalog search path. See build_search_order()\n for more info on the search path. \n \"\"\" \n\n # 1. put it in the cache.\n if self.cache.has_key(code):\n if function not in self.cache[code]:\n self.cache[code].insert(0,function)\n else: \n # Load functions and put this one up front\n self.cache[code] = self.get_functions(code) \n self.fast_cache(code,function)\n \n # 2. Store the function entry to disk. \n try:\n self.set_module_directory(module_dir)\n self.add_function_persistent(code,function)\n finally:\n self.clear_module_directory()\n \n def add_function_persistent(self,code,function):\n \"\"\" Store the code->function relationship to disk.\n \n Two pieces of information are needed for loading functions\n from disk -- the function pickle (which conveniently stores\n the module name, etc.) and the path to its module's directory.\n The latter is needed so that the function can be loaded no\n matter what the user's Python path is.\n \"\"\" \n # add function to data in first writable catalog\n mode = 'cw' # create, write\n cat_file = self.get_writable_dir()\n cat = get_catalog(cat_file,mode)\n if cat is None:\n cat_dir = default_dir()\n cat = get_catalog(cat_file,mode)\n if cat is None:\n cat_dir = default_dir() \n cat_file = catalog_path(cat_dir)\n print 'problems with default catalog -- removing'\n os.remove(cat_file)\n cat = get_catalog(cat_dir,mode)\n if cat is None:\n raise ValueError, 'Failed to access a catalog for storing functions' \n function_list = [function] + cat.get(code,[])\n cat[code] = function_list\n \n # now add needed path information for loading function\n module = getmodule(function)\n try:\n # built in modules don't have the __file__ extension, so this\n # will fail. Just pass in this case since path additions aren't\n # needed for built-in modules.\n mod_path,f=os.path.split(os.path.abspath(module.__file__))\n pkey = self.path_key(code)\n cat[pkey] = [mod_path] + cat.get(pkey,[])\n except:\n pass\n\n def fast_cache(self,code,function):\n \"\"\" Move function to the front of the cache entry for code\n \n If future calls to the function have the same type signature,\n this will speed up access significantly because the first\n function call is correct.\n \n Note: The cache added to the inline_tools module is significantly\n faster than always calling get_functions, so this isn't\n as necessary as it used to be. Still, it's probably worth\n doing. \n \"\"\"\n try:\n if self.cache[code][0] == function:\n return\n except: # KeyError, IndexError \n pass\n try:\n self.cache[code].remove(function)\n except ValueError:\n pass\n # put new function at the beginning of the list to search.\n self.cache[code].insert(0,function)\n \ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n", "methods": [ { "name": "getmodule", "long_name": "getmodule( object )", "filename": "catalog.py", "nloc": 13, "complexity": 7, "token_count": 75, "parameters": [ "object" ], "start_line": 37, "end_line": 62, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "expr_to_filename", "long_name": "expr_to_filename( expr )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 24, "parameters": [ "expr" ], "start_line": 64, "end_line": 73, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "unique_file", "long_name": "unique_file( d , expr )", "filename": "catalog.py", "nloc": 13, "complexity": 8, "token_count": 89, "parameters": [ "d", "expr" ], "start_line": 75, "end_line": 97, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 0 }, { "name": "default_dir", "long_name": "default_dir( )", "filename": "catalog.py", "nloc": 18, "complexity": 5, "token_count": 145, "parameters": [], "start_line": 99, "end_line": 132, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 34, "top_nesting_level": 0 }, { "name": "default_temp_dir", "long_name": "default_temp_dir( )", "filename": "catalog.py", "nloc": 9, "complexity": 3, "token_count": 64, "parameters": [], "start_line": 134, "end_line": 142, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 0 }, { "name": "os_dependent_catalog_name", "long_name": "os_dependent_catalog_name( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 145, "end_line": 157, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 0 }, { "name": "catalog_path", "long_name": "catalog_path( module_path )", "filename": "catalog.py", "nloc": 12, "complexity": 3, "token_count": 105, "parameters": [ "module_path" ], "start_line": 159, "end_line": 184, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "get_catalog", "long_name": "get_catalog( module_path , mode = 'r' )", "filename": "catalog.py", "nloc": 7, "complexity": 2, "token_count": 35, "parameters": [ "module_path", "mode" ], "start_line": 186, "end_line": 204, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 0 }, { "name": "__init__", "long_name": "__init__( self , user_path_list = None )", "filename": "catalog.py", "nloc": 10, "complexity": 3, "token_count": 60, "parameters": [ "self", "user_path_list" ], "start_line": 233, "end_line": 248, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "set_module_directory", "long_name": "set_module_directory( self , module_dir )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self", "module_dir" ], "start_line": 250, "end_line": 256, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "get_module_directory", "long_name": "get_module_directory( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 257, "end_line": 260, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "clear_module_directory", "long_name": "clear_module_directory( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 261, "end_line": 264, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "get_environ_path", "long_name": "get_environ_path( self )", "filename": "catalog.py", "nloc": 9, "complexity": 3, "token_count": 55, "parameters": [ "self" ], "start_line": 266, "end_line": 280, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "build_search_order", "long_name": "build_search_order( self )", "filename": "catalog.py", "nloc": 11, "complexity": 4, "token_count": 62, "parameters": [ "self" ], "start_line": 282, "end_line": 304, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "get_catalog_files", "long_name": "get_catalog_files( self )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 34, "parameters": [ "self" ], "start_line": 306, "end_line": 315, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_existing_files", "long_name": "get_existing_files( self )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 27, "parameters": [ "self" ], "start_line": 317, "end_line": 322, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_writable_file.file_test", "long_name": "get_writable_file.file_test( x )", "filename": "catalog.py", "nloc": 4, "complexity": 3, "token_count": 43, "parameters": [ "x" ], "start_line": 336, "end_line": 339, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 2 }, { "name": "get_writable_file", "long_name": "get_writable_file( self , existing_only = 0 )", "filename": "catalog.py", "nloc": 12, "complexity": 3, "token_count": 55, "parameters": [ "self", "existing_only" ], "start_line": 324, "end_line": 345, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "get_writable_dir", "long_name": "get_writable_dir( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self" ], "start_line": 347, "end_line": 352, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "unique_module_name", "long_name": "unique_module_name( self , code , module_dir = None )", "filename": "catalog.py", "nloc": 9, "complexity": 4, "token_count": 53, "parameters": [ "self", "code", "module_dir" ], "start_line": 354, "end_line": 369, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "path_key", "long_name": "path_key( self , code )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "self", "code" ], "start_line": 371, "end_line": 374, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "configure_path", "long_name": "configure_path( self , cat , code )", "filename": "catalog.py", "nloc": 7, "complexity": 2, "token_count": 47, "parameters": [ "self", "cat", "code" ], "start_line": 376, "end_line": 388, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "unconfigure_path", "long_name": "unconfigure_path( self )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 390, "end_line": 396, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "get_cataloged_functions", "long_name": "get_cataloged_functions( self , code )", "filename": "catalog.py", "nloc": 15, "complexity": 5, "token_count": 86, "parameters": [ "self", "code" ], "start_line": 398, "end_line": 427, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 30, "top_nesting_level": 1 }, { "name": "repair_catalog", "long_name": "repair_catalog( self , catalog_path , code )", "filename": "catalog.py", "nloc": 16, "complexity": 5, "token_count": 82, "parameters": [ "self", "catalog_path", "code" ], "start_line": 430, "end_line": 460, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 31, "top_nesting_level": 1 }, { "name": "get_functions_fast", "long_name": "get_functions_fast( self , code )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 20, "parameters": [ "self", "code" ], "start_line": 462, "end_line": 467, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_functions", "long_name": "get_functions( self , code , module_dir = None )", "filename": "catalog.py", "nloc": 13, "complexity": 5, "token_count": 69, "parameters": [ "self", "code", "module_dir" ], "start_line": 469, "end_line": 503, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 35, "top_nesting_level": 1 }, { "name": "add_function", "long_name": "add_function( self , code , function , module_dir = None )", "filename": "catalog.py", "nloc": 12, "complexity": 4, "token_count": 94, "parameters": [ "self", "code", "function", "module_dir" ], "start_line": 505, "end_line": 533, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 29, "top_nesting_level": 1 }, { "name": "add_function_persistent", "long_name": "add_function_persistent( self , code , function )", "filename": "catalog.py", "nloc": 24, "complexity": 5, "token_count": 166, "parameters": [ "self", "code", "function" ], "start_line": 535, "end_line": 572, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 38, "top_nesting_level": 1 }, { "name": "fast_cache", "long_name": "fast_cache( self , code , function )", "filename": "catalog.py", "nloc": 11, "complexity": 4, "token_count": 59, "parameters": [ "self", "code", "function" ], "start_line": 574, "end_line": 596, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "test", "long_name": "test( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 598, "end_line": 600, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 602, "end_line": 604, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "methods_before": [ { "name": "getmodule", "long_name": "getmodule( object )", "filename": "catalog.py", "nloc": 13, "complexity": 7, "token_count": 75, "parameters": [ "object" ], "start_line": 37, "end_line": 62, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "expr_to_filename", "long_name": "expr_to_filename( expr )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 24, "parameters": [ "expr" ], "start_line": 64, "end_line": 73, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "unique_file", "long_name": "unique_file( d , expr )", "filename": "catalog.py", "nloc": 13, "complexity": 8, "token_count": 89, "parameters": [ "d", "expr" ], "start_line": 75, "end_line": 97, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 0 }, { "name": "default_dir", "long_name": "default_dir( )", "filename": "catalog.py", "nloc": 18, "complexity": 5, "token_count": 145, "parameters": [], "start_line": 99, "end_line": 132, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 34, "top_nesting_level": 0 }, { "name": "default_temp_dir", "long_name": "default_temp_dir( )", "filename": "catalog.py", "nloc": 9, "complexity": 3, "token_count": 64, "parameters": [], "start_line": 134, "end_line": 142, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 0 }, { "name": "os_dependent_catalog_name", "long_name": "os_dependent_catalog_name( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 145, "end_line": 157, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 0 }, { "name": "catalog_path", "long_name": "catalog_path( module_path )", "filename": "catalog.py", "nloc": 12, "complexity": 3, "token_count": 105, "parameters": [ "module_path" ], "start_line": 159, "end_line": 184, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "get_catalog", "long_name": "get_catalog( module_path , mode = 'r' )", "filename": "catalog.py", "nloc": 7, "complexity": 2, "token_count": 35, "parameters": [ "module_path", "mode" ], "start_line": 186, "end_line": 204, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 0 }, { "name": "__init__", "long_name": "__init__( self , user_path_list = None )", "filename": "catalog.py", "nloc": 10, "complexity": 3, "token_count": 60, "parameters": [ "self", "user_path_list" ], "start_line": 233, "end_line": 248, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "set_module_directory", "long_name": "set_module_directory( self , module_dir )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self", "module_dir" ], "start_line": 250, "end_line": 256, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "get_module_directory", "long_name": "get_module_directory( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 257, "end_line": 260, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "clear_module_directory", "long_name": "clear_module_directory( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 261, "end_line": 264, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "get_environ_path", "long_name": "get_environ_path( self )", "filename": "catalog.py", "nloc": 9, "complexity": 3, "token_count": 55, "parameters": [ "self" ], "start_line": 266, "end_line": 280, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "build_search_order", "long_name": "build_search_order( self )", "filename": "catalog.py", "nloc": 11, "complexity": 4, "token_count": 62, "parameters": [ "self" ], "start_line": 282, "end_line": 304, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "get_catalog_files", "long_name": "get_catalog_files( self )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 34, "parameters": [ "self" ], "start_line": 306, "end_line": 315, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_existing_files", "long_name": "get_existing_files( self )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 27, "parameters": [ "self" ], "start_line": 317, "end_line": 322, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_writable_file.file_test", "long_name": "get_writable_file.file_test( x )", "filename": "catalog.py", "nloc": 4, "complexity": 3, "token_count": 43, "parameters": [ "x" ], "start_line": 336, "end_line": 339, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 2 }, { "name": "get_writable_file", "long_name": "get_writable_file( self , existing_only = 0 )", "filename": "catalog.py", "nloc": 12, "complexity": 3, "token_count": 55, "parameters": [ "self", "existing_only" ], "start_line": 324, "end_line": 345, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "get_writable_dir", "long_name": "get_writable_dir( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self" ], "start_line": 347, "end_line": 352, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "unique_module_name", "long_name": "unique_module_name( self , code , module_dir = None )", "filename": "catalog.py", "nloc": 9, "complexity": 4, "token_count": 53, "parameters": [ "self", "code", "module_dir" ], "start_line": 354, "end_line": 369, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "path_key", "long_name": "path_key( self , code )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "self", "code" ], "start_line": 371, "end_line": 374, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "configure_path", "long_name": "configure_path( self , cat , code )", "filename": "catalog.py", "nloc": 7, "complexity": 2, "token_count": 47, "parameters": [ "self", "cat", "code" ], "start_line": 376, "end_line": 388, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "unconfigure_path", "long_name": "unconfigure_path( self )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 390, "end_line": 396, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "get_cataloged_functions", "long_name": "get_cataloged_functions( self , code )", "filename": "catalog.py", "nloc": 15, "complexity": 5, "token_count": 86, "parameters": [ "self", "code" ], "start_line": 398, "end_line": 427, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 30, "top_nesting_level": 1 }, { "name": "repair_catalog", "long_name": "repair_catalog( self , catalog_path , code )", "filename": "catalog.py", "nloc": 14, "complexity": 4, "token_count": 72, "parameters": [ "self", "catalog_path", "code" ], "start_line": 430, "end_line": 454, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 25, "top_nesting_level": 1 }, { "name": "get_functions_fast", "long_name": "get_functions_fast( self , code )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 20, "parameters": [ "self", "code" ], "start_line": 456, "end_line": 461, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_functions", "long_name": "get_functions( self , code , module_dir = None )", "filename": "catalog.py", "nloc": 13, "complexity": 5, "token_count": 69, "parameters": [ "self", "code", "module_dir" ], "start_line": 463, "end_line": 497, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 35, "top_nesting_level": 1 }, { "name": "add_function", "long_name": "add_function( self , code , function , module_dir = None )", "filename": "catalog.py", "nloc": 12, "complexity": 4, "token_count": 94, "parameters": [ "self", "code", "function", "module_dir" ], "start_line": 499, "end_line": 527, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 29, "top_nesting_level": 1 }, { "name": "add_function_persistent", "long_name": "add_function_persistent( self , code , function )", "filename": "catalog.py", "nloc": 24, "complexity": 5, "token_count": 166, "parameters": [ "self", "code", "function" ], "start_line": 529, "end_line": 566, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 38, "top_nesting_level": 1 }, { "name": "fast_cache", "long_name": "fast_cache( self , code , function )", "filename": "catalog.py", "nloc": 11, "complexity": 4, "token_count": 59, "parameters": [ "self", "code", "function" ], "start_line": 568, "end_line": 590, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "test", "long_name": "test( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 592, "end_line": 594, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 596, "end_line": 598, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "repair_catalog", "long_name": "repair_catalog( self , catalog_path , code )", "filename": "catalog.py", "nloc": 16, "complexity": 5, "token_count": 82, "parameters": [ "self", "catalog_path", "code" ], "start_line": 430, "end_line": 460, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 31, "top_nesting_level": 1 } ], "nloc": 321, "complexity": 91, "token_count": 1734, "diff_parsed": { "added": [ " del writable_cat[code]", "", " # it is possible that the path key doesn't exist (if the function registered", " # was a built-in function), so we have to check if the path exists before", " # arbitrarily deleting it.", " path_key = self.path_key(code)", " if writable_cat.has_key(path_key)", " del writable_cat[path_key]" ], "deleted": [ " del writable_cat[code]", " del writable_cat[self.path_key(code)]" ] } } ] }, { "hash": "0074d56dca0d99f7bed07ea9d7bf61dbde828209", "msg": "forgot : at end of if statement", "author": { "name": "Eric Jones", "email": "eric@enthought.com" }, "committer": { "name": "Eric Jones", "email": "eric@enthought.com" }, "author_date": "2002-01-06T20:21:31+00:00", "author_timezone": 0, "committer_date": "2002-01-06T20:21:31+00:00", "committer_timezone": 0, "branches": [ "main" ], "in_main_branch": true, "merge": false, "parents": [ "556e691b9b82db9053a73a5ee5158988cd8d65bf" ], "project_name": "repo_copy", "project_path": "/tmp/tmplzfwcosk/repo_copy", "deletions": 1, "insertions": 1, "lines": 2, "files": 1, "dmm_unit_size": null, "dmm_unit_complexity": null, "dmm_unit_interfacing": null, "modified_files": [ { "old_path": "weave/catalog.py", "new_path": "weave/catalog.py", "filename": "catalog.py", "extension": "py", "change_type": "MODIFY", "diff": "@@ -456,7 +456,7 @@ def repair_catalog(self,catalog_path,code):\n # was a built-in function), so we have to check if the path exists before\n # arbitrarily deleting it.\n path_key = self.path_key(code) \n- if writable_cat.has_key(path_key)\n+ if writable_cat.has_key(path_key):\n del writable_cat[path_key] \n \n def get_functions_fast(self,code):\n", "added_lines": 1, "deleted_lines": 1, "source_code": "\"\"\" Track relationships between compiled extension functions & code fragments\n\n catalog keeps track of which compiled(or even standard) functions are \n related to which code fragments. It also stores these relationships\n to disk so they are remembered between Python sessions. When \n \n a = 1\n compiler.inline('printf(\"printed from C: %d\",a);',['a'] )\n \n is called, inline() first looks to see if it has seen the code \n 'printf(\"printed from C\");' before. If not, it calls \n \n catalog.get_functions('printf(\"printed from C: %d\", a);')\n \n which returns a list of all the function objects that have been compiled\n for the code fragment. Multiple functions can occur because the code\n could be compiled for different types for 'a' (although not likely in\n this case). The catalog first looks in its cache and quickly returns\n a list of the functions if possible. If the cache lookup fails, it then\n looks through possibly multiple catalog files on disk and fills its\n cache with all the functions that match the code fragment. \n \n In case where the code fragment hasn't been compiled, inline() compiles\n the code and then adds it to the catalog:\n \n function = \n catalog.add_function('printf(\"printed from C: %d\", a);',function)\n \n add_function() adds function to the front of the cache. function,\n along with the path information to its module, are also stored in a\n persistent catalog for future use by python sessions. \n\"\"\" \n\nimport os,sys,string\nimport shelve\n\ndef getmodule(object):\n \"\"\" Discover the name of the module where object was defined.\n \n This is an augmented version of inspect.getmodule that can discover \n the parent module for extension functions.\n \"\"\"\n import inspect\n value = inspect.getmodule(object)\n if value is None:\n #walk trough all modules looking for function\n for name,mod in sys.modules.items():\n # try except used because of some comparison failures\n # in wxPoint code. Need to review this\n try:\n if mod and object in mod.__dict__.values():\n value = mod\n # if it is a built-in module, keep looking to see\n # if a non-builtin also has it. Otherwise quit and\n # consider the module found. (ain't perfect, but will \n # have to do for now).\n if string.find('(built-in)',str(mod)) is -1:\n break\n \n except TypeError:\n pass \n return value\n\ndef expr_to_filename(expr):\n \"\"\" Convert an arbitrary expr string to a valid file name.\n \n The name is based on the md5 check sum for the string and\n Something that was a little more human readable would be \n nice, but the computer doesn't seem to care.\n \"\"\"\n import md5\n base = 'sc_'\n return base + md5.new(expr).hexdigest()\n\ndef unique_file(d,expr):\n \"\"\" Generate a unqiue file name based on expr in directory d\n \n This is meant for use with building extension modules, so\n a file name is considered unique if none of the following\n extension '.cpp','.o','.so','module.so','.py', or '.pyd'\n exists in directory d. The fully qualified path to the\n new name is returned. You'll need to append your own\n extension to it before creating files.\n \"\"\"\n files = os.listdir(d)\n #base = 'scipy_compile'\n base = expr_to_filename(expr)\n for i in range(1000000):\n fname = base + `i`\n if not (fname+'.cpp' in files or\n fname+'.o' in files or\n fname+'.so' in files or\n fname+'module.so' in files or\n fname+'.py' in files or\n fname+'.pyd' in files):\n break\n return os.path.join(d,fname)\n \ndef default_dir():\n \"\"\" Return a default location to store compiled files and catalogs.\n \n XX is the Python version number in all paths listed below\n On windows, the default location is the temporary directory\n returned by gettempdir()/pythonXX.\n \n On Unix, ~/.pythonXX_compiled is the default location. If it doesn't\n exist, it is created. The directory is marked rwx------.\n \n If for some reason it isn't possible to build a default directory\n in the user's home, /tmp/_pythonXX_compiled is used. If it \n doesn't exist, it is created. The directory is marked rwx------\n to try and keep people from being able to sneak a bad module\n in on you. \n \"\"\"\n import tempfile \n python_name = \"python%d%d_compiled\" % tuple(sys.version_info[:2]) \n if sys.platform != 'win32':\n try:\n path = os.path.join(os.environ['HOME'],'.' + python_name)\n except KeyError:\n temp_dir = `os.getuid()` + '_' + python_name\n path = os.path.join(tempfile.gettempdir(),temp_dir) \n else:\n path = os.path.join(tempfile.gettempdir(),python_name)\n \n if not os.path.exists(path):\n os.mkdir(path)\n os.chmod(path,0700) # make it only accessible by this user.\n if not os.access(path,os.W_OK):\n print 'warning: default directory is not write accessible.'\n print 'defualt:', path\n return path\n\ndef default_temp_dir():\n path = os.path.join(default_dir(),'temp')\n if not os.path.exists(path):\n os.mkdir(path)\n os.chmod(path,0700) # make it only accessible by this user.\n if not os.access(path,os.W_OK):\n print 'warning: default directory is not write accessible.'\n print 'defualt:', path\n return path\n\n \ndef os_dependent_catalog_name():\n \"\"\" Generate catalog name dependent on OS and Python version being used.\n \n This allows multiple platforms to have catalog files in the\n same directory without stepping on each other. For now, it \n bases the name of the value returned by sys.platform and the\n version of python being run. If this isn't enough to descriminate\n on some platforms, we can try to add other info. It has \n occured to me that if we get fancy enough to optimize for different\n architectures, then chip type might be added to the catalog name also.\n \"\"\"\n version = '%d%d' % sys.version_info[:2]\n return sys.platform+version+'compiled_catalog'\n \ndef catalog_path(module_path):\n \"\"\" Return the full path name for the catalog file in the given directory.\n \n module_path can either be a file name or a path name. If it is a \n file name, the catalog file name in its parent directory is returned.\n If it is a directory, the catalog file in that directory is returned.\n\n If module_path doesn't exist, None is returned. Note though, that the\n catalog file does *not* have to exist, only its parent. '~', shell\n variables, and relative ('.' and '..') paths are all acceptable.\n \n catalog file names are os dependent (based on sys.platform), so this \n should support multiple platforms sharing the same disk space \n (NFS mounts). See os_dependent_catalog_name() for more info.\n \"\"\"\n module_path = os.path.expanduser(module_path)\n module_path = os.path.expandvars(module_path)\n module_path = os.path.abspath(module_path)\n if not os.path.exists(module_path):\n catalog_file = None\n elif not os.path.isdir(module_path):\n module_path,dummy = os.path.split(module_path)\n catalog_file = os.path.join(module_path,os_dependent_catalog_name())\n else: \n catalog_file = os.path.join(module_path,os_dependent_catalog_name())\n return catalog_file\n\ndef get_catalog(module_path,mode='r'):\n \"\"\" Return a function catalog (shelve object) from the path module_path\n\n If module_path is a directory, the function catalog returned is\n from that directory. If module_path is an actual module_name,\n then the function catalog returned is from its parent directory.\n mode uses the standard 'c' = create, 'r' = read, 'w' = write\n file open modes.\n \n See catalog_path() for more information on module_path.\n \"\"\"\n catalog_file = catalog_path(module_path)\n #print catalog_file\n #sh = shelve.open(catalog_file,mode)\n try:\n sh = shelve.open(catalog_file,mode)\n except: # not sure how to pin down which error to catch yet\n sh = None\n return sh\n\nclass catalog:\n \"\"\" Stores information about compiled functions both in cache and on disk.\n \n catalog stores (code, list_of_function) pairs so that all the functions\n that have been compiled for code are available for calling (usually in\n inline or blitz).\n \n catalog keeps a dictionary of previously accessed code values cached \n for quick access. It also handles the looking up of functions compiled \n in previously called Python sessions on disk in function catalogs. \n catalog searches the directories in the PYTHONCOMPILED environment \n variable in order loading functions that correspond to the given code \n fragment. A default directory is also searched for catalog functions. \n On unix, the default directory is usually '~/.pythonxx_compiled' where \n xx is the version of Python used. On windows, it is the directory \n returned by temfile.gettempdir(). Functions closer to the front are of \n the variable list are guaranteed to be closer to the front of the \n function list so that they will be called first. See \n get_cataloged_functions() for more info on how the search order is \n traversed.\n \n Catalog also handles storing information about compiled functions to\n a catalog. When writing this information, the first writable catalog\n file in PYTHONCOMPILED path is used. If a writable catalog is not\n found, it is written to the catalog in the default directory. This\n directory should always be writable.\n \"\"\"\n def __init__(self,user_path_list=None):\n \"\"\" Create a catalog for storing/searching for compiled functions. \n \n user_path_list contains directories that should be searched \n first for function catalogs. They will come before the path\n entries in the PYTHONCOMPILED environment varilable.\n \"\"\"\n if type(user_path_list) == type('string'):\n self.user_path_list = [user_path_list]\n elif user_path_list:\n self.user_path_list = user_path_list\n else:\n self.user_path_list = []\n self.cache = {}\n self.module_dir = None\n self.paths_added = 0\n \n def set_module_directory(self,module_dir):\n \"\"\" Set the path that will replace 'MODULE' in catalog searches.\n \n You should call clear_module_directory() when your finished\n working with it.\n \"\"\"\n self.module_dir = module_dir\n def get_module_directory(self):\n \"\"\" Return the path used to replace the 'MODULE' in searches.\n \"\"\"\n return self.module_dir\n def clear_module_directory(self):\n \"\"\" Reset 'MODULE' path to None so that it is ignored in searches. \n \"\"\"\n self.module_dir = None\n \n def get_environ_path(self):\n \"\"\" Return list of paths from 'PYTHONCOMPILED' environment variable.\n \n On Unix the path in PYTHONCOMPILED is a ':' separated list of\n directories. On Windows, a ';' separated list is used. \n \"\"\"\n paths = []\n if os.environ.has_key('PYTHONCOMPILED'):\n path_string = os.environ['PYTHONCOMPILED'] \n if sys.platform == 'win32':\n #probably should also look in registry\n paths = path_string.split(';')\n else: \n paths = path_string.split(':')\n return paths \n\n def build_search_order(self):\n \"\"\" Returns a list of paths that are searched for catalogs. \n \n Values specified in the catalog constructor are searched first,\n then values found in the PYTHONCOMPILED environment variable.\n The directory returned by default_dir() is always returned at\n the end of the list.\n \n There is a 'magic' path name called 'MODULE' that is replaced\n by the directory defined by set_module_directory(). If the\n module directory hasn't been set, 'MODULE' is ignored.\n \"\"\"\n \n paths = self.user_path_list + self.get_environ_path()\n search_order = []\n for path in paths:\n if path == 'MODULE':\n if self.module_dir:\n search_order.append(self.module_dir)\n else:\n search_order.append(path)\n search_order.append(default_dir())\n return search_order\n\n def get_catalog_files(self):\n \"\"\" Returns catalog file list in correct search order.\n \n Some of the catalog files may not currently exists.\n However, all will be valid locations for a catalog\n to be created (if you have write permission).\n \"\"\"\n files = map(catalog_path,self.build_search_order())\n files = filter(lambda x: x is not None,files)\n return files\n\n def get_existing_files(self):\n \"\"\" Returns all existing catalog file list in correct search order.\n \"\"\"\n files = self.get_catalog_files()\n existing_files = filter(os.path.exists,files)\n return existing_files\n\n def get_writable_file(self,existing_only=0):\n \"\"\" Return the name of the first writable catalog file.\n \n Its parent directory must also be writable. This is so that\n compiled modules can be written to the same directory.\n \"\"\"\n # note: both file and its parent directory must be writeable\n if existing_only:\n files = self.get_existing_files()\n else:\n files = self.get_catalog_files()\n # filter for (file exists and is writable) OR directory is writable\n def file_test(x):\n from os import access, F_OK, W_OK\n return (access(x,F_OK) and access(x,W_OK) or\n access(os.path.dirname(x),W_OK))\n writable = filter(file_test,files)\n if writable:\n file = writable[0]\n else:\n file = None\n return file\n \n def get_writable_dir(self):\n \"\"\" Return the parent directory of first writable catalog file.\n \n The returned directory has write access.\n \"\"\"\n return os.path.dirname(self.get_writable_file())\n \n def unique_module_name(self,code,module_dir=None):\n \"\"\" Return full path to unique file name that in writable location.\n \n The directory for the file is the first writable directory in \n the catalog search path. The unique file name is derived from\n the code fragment. If, module_dir is specified, it is used\n to replace 'MODULE' in the search path.\n \"\"\"\n if module_dir is not None:\n self.set_module_directory(module_dir)\n try:\n d = self.get_writable_dir()\n finally:\n if module_dir is not None:\n self.clear_module_directory()\n return unique_file(d,code)\n\n def path_key(self,code):\n \"\"\" Return key for path information for functions associated with code.\n \"\"\"\n return '__path__' + code\n \n def configure_path(self,cat,code):\n \"\"\" Add the python path for the given code to the sys.path\n \n unconfigure_path() should be called as soon as possible after\n imports associated with code are finished so that sys.path \n is restored to normal.\n \"\"\"\n try:\n paths = cat[self.path_key(code)]\n self.paths_added = len(paths)\n sys.path = paths + sys.path\n except:\n self.paths_added = 0 \n \n def unconfigure_path(self):\n \"\"\" Restores sys.path to normal after calls to configure_path()\n \n Remove the previously added paths from sys.path\n \"\"\"\n sys.path = sys.path[self.paths_added:]\n self.paths_added = 0\n\n def get_cataloged_functions(self,code):\n \"\"\" Load all functions associated with code from catalog search path.\n \n Sometimes there can be trouble loading a function listed in a\n catalog file because the actual module that holds the function \n has been moved or deleted. When this happens, that catalog file\n is \"repaired\", meaning the entire entry for this function is \n removed from the file. This only affects the catalog file that\n has problems -- not the others in the search path.\n \n The \"repair\" behavior may not be needed, but I'll keep it for now.\n \"\"\"\n mode = 'r'\n cat = None\n function_list = []\n for path in self.build_search_order():\n cat = get_catalog(path,mode)\n if cat is not None and cat.has_key(code):\n # set up the python path so that modules for this\n # function can be loaded.\n self.configure_path(cat,code)\n try: \n function_list += cat[code]\n except: #SystemError and ImportError so far seen \n # problems loading a function from the catalog. Try to\n # repair the cause.\n cat.close()\n self.repair_catalog(path,code)\n self.unconfigure_path() \n return function_list\n\n\n def repair_catalog(self,catalog_path,code):\n \"\"\" Remove entry for code from catalog_path\n \n Occasionally catalog entries could get corrupted. An example\n would be when a module that had functions in the catalog was\n deleted or moved on the disk. The best current repair method is \n just to trash the entire catalog entry for this piece of code. \n This may loose function entries that are valid, but thats life.\n \n catalog_path must be writable for repair. If it isn't, the\n function exists with a warning. \n \"\"\"\n writable_cat = None\n if not os.path.exists(catalog_path):\n return\n try:\n writable_cat = get_catalog(catalog_path,'w')\n except:\n print 'warning: unable to repair catalog entry\\n %s\\n in\\n %s' % \\\n (code,catalog_path)\n return \n if writable_cat.has_key(code):\n print 'repairing catalog by removing key'\n del writable_cat[code]\n \n # it is possible that the path key doesn't exist (if the function registered\n # was a built-in function), so we have to check if the path exists before\n # arbitrarily deleting it.\n path_key = self.path_key(code) \n if writable_cat.has_key(path_key):\n del writable_cat[path_key] \n \n def get_functions_fast(self,code):\n \"\"\" Return list of functions for code from the cache.\n \n Return an empty list if the code entry is not found.\n \"\"\"\n return self.cache.get(code,[])\n \n def get_functions(self,code,module_dir=None):\n \"\"\" Return the list of functions associated with this code fragment.\n \n The cache is first searched for the function. If an entry\n in the cache is not found, then catalog files on disk are \n searched for the entry. This is slooooow, but only happens\n once per code object. All the functions found in catalog files\n on a cache miss are loaded into the cache to speed up future calls.\n The search order is as follows:\n \n 1. user specified path (from catalog initialization)\n 2. directories from the PYTHONCOMPILED environment variable\n 3. The temporary directory on your platform.\n\n The path specified by module_dir will replace the 'MODULE' \n place holder in the catalog search path. See build_search_order()\n for more info on the search path. \n \"\"\" \n # Fast!! try cache first.\n if self.cache.has_key(code):\n return self.cache[code]\n \n # 2. Slow!! read previously compiled functions from disk.\n try:\n self.set_module_directory(module_dir)\n function_list = self.get_cataloged_functions(code)\n if code:\n function_list\n # put function_list in cache to save future lookups.\n if function_list:\n self.cache[code] = function_list\n # return function_list, empty or otherwise.\n finally:\n self.clear_module_directory()\n return function_list\n\n def add_function(self,code,function,module_dir=None):\n \"\"\" Adds a function to the catalog.\n \n The function is added to the cache as well as the first\n writable file catalog found in the search path. If no\n code entry exists in the cache, the on disk catalogs\n are loaded into the cache and function is added to the\n beginning of the function list.\n \n The path specified by module_dir will replace the 'MODULE' \n place holder in the catalog search path. See build_search_order()\n for more info on the search path. \n \"\"\" \n\n # 1. put it in the cache.\n if self.cache.has_key(code):\n if function not in self.cache[code]:\n self.cache[code].insert(0,function)\n else: \n # Load functions and put this one up front\n self.cache[code] = self.get_functions(code) \n self.fast_cache(code,function)\n \n # 2. Store the function entry to disk. \n try:\n self.set_module_directory(module_dir)\n self.add_function_persistent(code,function)\n finally:\n self.clear_module_directory()\n \n def add_function_persistent(self,code,function):\n \"\"\" Store the code->function relationship to disk.\n \n Two pieces of information are needed for loading functions\n from disk -- the function pickle (which conveniently stores\n the module name, etc.) and the path to its module's directory.\n The latter is needed so that the function can be loaded no\n matter what the user's Python path is.\n \"\"\" \n # add function to data in first writable catalog\n mode = 'cw' # create, write\n cat_file = self.get_writable_dir()\n cat = get_catalog(cat_file,mode)\n if cat is None:\n cat_dir = default_dir()\n cat = get_catalog(cat_file,mode)\n if cat is None:\n cat_dir = default_dir() \n cat_file = catalog_path(cat_dir)\n print 'problems with default catalog -- removing'\n os.remove(cat_file)\n cat = get_catalog(cat_dir,mode)\n if cat is None:\n raise ValueError, 'Failed to access a catalog for storing functions' \n function_list = [function] + cat.get(code,[])\n cat[code] = function_list\n \n # now add needed path information for loading function\n module = getmodule(function)\n try:\n # built in modules don't have the __file__ extension, so this\n # will fail. Just pass in this case since path additions aren't\n # needed for built-in modules.\n mod_path,f=os.path.split(os.path.abspath(module.__file__))\n pkey = self.path_key(code)\n cat[pkey] = [mod_path] + cat.get(pkey,[])\n except:\n pass\n\n def fast_cache(self,code,function):\n \"\"\" Move function to the front of the cache entry for code\n \n If future calls to the function have the same type signature,\n this will speed up access significantly because the first\n function call is correct.\n \n Note: The cache added to the inline_tools module is significantly\n faster than always calling get_functions, so this isn't\n as necessary as it used to be. Still, it's probably worth\n doing. \n \"\"\"\n try:\n if self.cache[code][0] == function:\n return\n except: # KeyError, IndexError \n pass\n try:\n self.cache[code].remove(function)\n except ValueError:\n pass\n # put new function at the beginning of the list to search.\n self.cache[code].insert(0,function)\n \ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n", "source_code_before": "\"\"\" Track relationships between compiled extension functions & code fragments\n\n catalog keeps track of which compiled(or even standard) functions are \n related to which code fragments. It also stores these relationships\n to disk so they are remembered between Python sessions. When \n \n a = 1\n compiler.inline('printf(\"printed from C: %d\",a);',['a'] )\n \n is called, inline() first looks to see if it has seen the code \n 'printf(\"printed from C\");' before. If not, it calls \n \n catalog.get_functions('printf(\"printed from C: %d\", a);')\n \n which returns a list of all the function objects that have been compiled\n for the code fragment. Multiple functions can occur because the code\n could be compiled for different types for 'a' (although not likely in\n this case). The catalog first looks in its cache and quickly returns\n a list of the functions if possible. If the cache lookup fails, it then\n looks through possibly multiple catalog files on disk and fills its\n cache with all the functions that match the code fragment. \n \n In case where the code fragment hasn't been compiled, inline() compiles\n the code and then adds it to the catalog:\n \n function = \n catalog.add_function('printf(\"printed from C: %d\", a);',function)\n \n add_function() adds function to the front of the cache. function,\n along with the path information to its module, are also stored in a\n persistent catalog for future use by python sessions. \n\"\"\" \n\nimport os,sys,string\nimport shelve\n\ndef getmodule(object):\n \"\"\" Discover the name of the module where object was defined.\n \n This is an augmented version of inspect.getmodule that can discover \n the parent module for extension functions.\n \"\"\"\n import inspect\n value = inspect.getmodule(object)\n if value is None:\n #walk trough all modules looking for function\n for name,mod in sys.modules.items():\n # try except used because of some comparison failures\n # in wxPoint code. Need to review this\n try:\n if mod and object in mod.__dict__.values():\n value = mod\n # if it is a built-in module, keep looking to see\n # if a non-builtin also has it. Otherwise quit and\n # consider the module found. (ain't perfect, but will \n # have to do for now).\n if string.find('(built-in)',str(mod)) is -1:\n break\n \n except TypeError:\n pass \n return value\n\ndef expr_to_filename(expr):\n \"\"\" Convert an arbitrary expr string to a valid file name.\n \n The name is based on the md5 check sum for the string and\n Something that was a little more human readable would be \n nice, but the computer doesn't seem to care.\n \"\"\"\n import md5\n base = 'sc_'\n return base + md5.new(expr).hexdigest()\n\ndef unique_file(d,expr):\n \"\"\" Generate a unqiue file name based on expr in directory d\n \n This is meant for use with building extension modules, so\n a file name is considered unique if none of the following\n extension '.cpp','.o','.so','module.so','.py', or '.pyd'\n exists in directory d. The fully qualified path to the\n new name is returned. You'll need to append your own\n extension to it before creating files.\n \"\"\"\n files = os.listdir(d)\n #base = 'scipy_compile'\n base = expr_to_filename(expr)\n for i in range(1000000):\n fname = base + `i`\n if not (fname+'.cpp' in files or\n fname+'.o' in files or\n fname+'.so' in files or\n fname+'module.so' in files or\n fname+'.py' in files or\n fname+'.pyd' in files):\n break\n return os.path.join(d,fname)\n \ndef default_dir():\n \"\"\" Return a default location to store compiled files and catalogs.\n \n XX is the Python version number in all paths listed below\n On windows, the default location is the temporary directory\n returned by gettempdir()/pythonXX.\n \n On Unix, ~/.pythonXX_compiled is the default location. If it doesn't\n exist, it is created. The directory is marked rwx------.\n \n If for some reason it isn't possible to build a default directory\n in the user's home, /tmp/_pythonXX_compiled is used. If it \n doesn't exist, it is created. The directory is marked rwx------\n to try and keep people from being able to sneak a bad module\n in on you. \n \"\"\"\n import tempfile \n python_name = \"python%d%d_compiled\" % tuple(sys.version_info[:2]) \n if sys.platform != 'win32':\n try:\n path = os.path.join(os.environ['HOME'],'.' + python_name)\n except KeyError:\n temp_dir = `os.getuid()` + '_' + python_name\n path = os.path.join(tempfile.gettempdir(),temp_dir) \n else:\n path = os.path.join(tempfile.gettempdir(),python_name)\n \n if not os.path.exists(path):\n os.mkdir(path)\n os.chmod(path,0700) # make it only accessible by this user.\n if not os.access(path,os.W_OK):\n print 'warning: default directory is not write accessible.'\n print 'defualt:', path\n return path\n\ndef default_temp_dir():\n path = os.path.join(default_dir(),'temp')\n if not os.path.exists(path):\n os.mkdir(path)\n os.chmod(path,0700) # make it only accessible by this user.\n if not os.access(path,os.W_OK):\n print 'warning: default directory is not write accessible.'\n print 'defualt:', path\n return path\n\n \ndef os_dependent_catalog_name():\n \"\"\" Generate catalog name dependent on OS and Python version being used.\n \n This allows multiple platforms to have catalog files in the\n same directory without stepping on each other. For now, it \n bases the name of the value returned by sys.platform and the\n version of python being run. If this isn't enough to descriminate\n on some platforms, we can try to add other info. It has \n occured to me that if we get fancy enough to optimize for different\n architectures, then chip type might be added to the catalog name also.\n \"\"\"\n version = '%d%d' % sys.version_info[:2]\n return sys.platform+version+'compiled_catalog'\n \ndef catalog_path(module_path):\n \"\"\" Return the full path name for the catalog file in the given directory.\n \n module_path can either be a file name or a path name. If it is a \n file name, the catalog file name in its parent directory is returned.\n If it is a directory, the catalog file in that directory is returned.\n\n If module_path doesn't exist, None is returned. Note though, that the\n catalog file does *not* have to exist, only its parent. '~', shell\n variables, and relative ('.' and '..') paths are all acceptable.\n \n catalog file names are os dependent (based on sys.platform), so this \n should support multiple platforms sharing the same disk space \n (NFS mounts). See os_dependent_catalog_name() for more info.\n \"\"\"\n module_path = os.path.expanduser(module_path)\n module_path = os.path.expandvars(module_path)\n module_path = os.path.abspath(module_path)\n if not os.path.exists(module_path):\n catalog_file = None\n elif not os.path.isdir(module_path):\n module_path,dummy = os.path.split(module_path)\n catalog_file = os.path.join(module_path,os_dependent_catalog_name())\n else: \n catalog_file = os.path.join(module_path,os_dependent_catalog_name())\n return catalog_file\n\ndef get_catalog(module_path,mode='r'):\n \"\"\" Return a function catalog (shelve object) from the path module_path\n\n If module_path is a directory, the function catalog returned is\n from that directory. If module_path is an actual module_name,\n then the function catalog returned is from its parent directory.\n mode uses the standard 'c' = create, 'r' = read, 'w' = write\n file open modes.\n \n See catalog_path() for more information on module_path.\n \"\"\"\n catalog_file = catalog_path(module_path)\n #print catalog_file\n #sh = shelve.open(catalog_file,mode)\n try:\n sh = shelve.open(catalog_file,mode)\n except: # not sure how to pin down which error to catch yet\n sh = None\n return sh\n\nclass catalog:\n \"\"\" Stores information about compiled functions both in cache and on disk.\n \n catalog stores (code, list_of_function) pairs so that all the functions\n that have been compiled for code are available for calling (usually in\n inline or blitz).\n \n catalog keeps a dictionary of previously accessed code values cached \n for quick access. It also handles the looking up of functions compiled \n in previously called Python sessions on disk in function catalogs. \n catalog searches the directories in the PYTHONCOMPILED environment \n variable in order loading functions that correspond to the given code \n fragment. A default directory is also searched for catalog functions. \n On unix, the default directory is usually '~/.pythonxx_compiled' where \n xx is the version of Python used. On windows, it is the directory \n returned by temfile.gettempdir(). Functions closer to the front are of \n the variable list are guaranteed to be closer to the front of the \n function list so that they will be called first. See \n get_cataloged_functions() for more info on how the search order is \n traversed.\n \n Catalog also handles storing information about compiled functions to\n a catalog. When writing this information, the first writable catalog\n file in PYTHONCOMPILED path is used. If a writable catalog is not\n found, it is written to the catalog in the default directory. This\n directory should always be writable.\n \"\"\"\n def __init__(self,user_path_list=None):\n \"\"\" Create a catalog for storing/searching for compiled functions. \n \n user_path_list contains directories that should be searched \n first for function catalogs. They will come before the path\n entries in the PYTHONCOMPILED environment varilable.\n \"\"\"\n if type(user_path_list) == type('string'):\n self.user_path_list = [user_path_list]\n elif user_path_list:\n self.user_path_list = user_path_list\n else:\n self.user_path_list = []\n self.cache = {}\n self.module_dir = None\n self.paths_added = 0\n \n def set_module_directory(self,module_dir):\n \"\"\" Set the path that will replace 'MODULE' in catalog searches.\n \n You should call clear_module_directory() when your finished\n working with it.\n \"\"\"\n self.module_dir = module_dir\n def get_module_directory(self):\n \"\"\" Return the path used to replace the 'MODULE' in searches.\n \"\"\"\n return self.module_dir\n def clear_module_directory(self):\n \"\"\" Reset 'MODULE' path to None so that it is ignored in searches. \n \"\"\"\n self.module_dir = None\n \n def get_environ_path(self):\n \"\"\" Return list of paths from 'PYTHONCOMPILED' environment variable.\n \n On Unix the path in PYTHONCOMPILED is a ':' separated list of\n directories. On Windows, a ';' separated list is used. \n \"\"\"\n paths = []\n if os.environ.has_key('PYTHONCOMPILED'):\n path_string = os.environ['PYTHONCOMPILED'] \n if sys.platform == 'win32':\n #probably should also look in registry\n paths = path_string.split(';')\n else: \n paths = path_string.split(':')\n return paths \n\n def build_search_order(self):\n \"\"\" Returns a list of paths that are searched for catalogs. \n \n Values specified in the catalog constructor are searched first,\n then values found in the PYTHONCOMPILED environment variable.\n The directory returned by default_dir() is always returned at\n the end of the list.\n \n There is a 'magic' path name called 'MODULE' that is replaced\n by the directory defined by set_module_directory(). If the\n module directory hasn't been set, 'MODULE' is ignored.\n \"\"\"\n \n paths = self.user_path_list + self.get_environ_path()\n search_order = []\n for path in paths:\n if path == 'MODULE':\n if self.module_dir:\n search_order.append(self.module_dir)\n else:\n search_order.append(path)\n search_order.append(default_dir())\n return search_order\n\n def get_catalog_files(self):\n \"\"\" Returns catalog file list in correct search order.\n \n Some of the catalog files may not currently exists.\n However, all will be valid locations for a catalog\n to be created (if you have write permission).\n \"\"\"\n files = map(catalog_path,self.build_search_order())\n files = filter(lambda x: x is not None,files)\n return files\n\n def get_existing_files(self):\n \"\"\" Returns all existing catalog file list in correct search order.\n \"\"\"\n files = self.get_catalog_files()\n existing_files = filter(os.path.exists,files)\n return existing_files\n\n def get_writable_file(self,existing_only=0):\n \"\"\" Return the name of the first writable catalog file.\n \n Its parent directory must also be writable. This is so that\n compiled modules can be written to the same directory.\n \"\"\"\n # note: both file and its parent directory must be writeable\n if existing_only:\n files = self.get_existing_files()\n else:\n files = self.get_catalog_files()\n # filter for (file exists and is writable) OR directory is writable\n def file_test(x):\n from os import access, F_OK, W_OK\n return (access(x,F_OK) and access(x,W_OK) or\n access(os.path.dirname(x),W_OK))\n writable = filter(file_test,files)\n if writable:\n file = writable[0]\n else:\n file = None\n return file\n \n def get_writable_dir(self):\n \"\"\" Return the parent directory of first writable catalog file.\n \n The returned directory has write access.\n \"\"\"\n return os.path.dirname(self.get_writable_file())\n \n def unique_module_name(self,code,module_dir=None):\n \"\"\" Return full path to unique file name that in writable location.\n \n The directory for the file is the first writable directory in \n the catalog search path. The unique file name is derived from\n the code fragment. If, module_dir is specified, it is used\n to replace 'MODULE' in the search path.\n \"\"\"\n if module_dir is not None:\n self.set_module_directory(module_dir)\n try:\n d = self.get_writable_dir()\n finally:\n if module_dir is not None:\n self.clear_module_directory()\n return unique_file(d,code)\n\n def path_key(self,code):\n \"\"\" Return key for path information for functions associated with code.\n \"\"\"\n return '__path__' + code\n \n def configure_path(self,cat,code):\n \"\"\" Add the python path for the given code to the sys.path\n \n unconfigure_path() should be called as soon as possible after\n imports associated with code are finished so that sys.path \n is restored to normal.\n \"\"\"\n try:\n paths = cat[self.path_key(code)]\n self.paths_added = len(paths)\n sys.path = paths + sys.path\n except:\n self.paths_added = 0 \n \n def unconfigure_path(self):\n \"\"\" Restores sys.path to normal after calls to configure_path()\n \n Remove the previously added paths from sys.path\n \"\"\"\n sys.path = sys.path[self.paths_added:]\n self.paths_added = 0\n\n def get_cataloged_functions(self,code):\n \"\"\" Load all functions associated with code from catalog search path.\n \n Sometimes there can be trouble loading a function listed in a\n catalog file because the actual module that holds the function \n has been moved or deleted. When this happens, that catalog file\n is \"repaired\", meaning the entire entry for this function is \n removed from the file. This only affects the catalog file that\n has problems -- not the others in the search path.\n \n The \"repair\" behavior may not be needed, but I'll keep it for now.\n \"\"\"\n mode = 'r'\n cat = None\n function_list = []\n for path in self.build_search_order():\n cat = get_catalog(path,mode)\n if cat is not None and cat.has_key(code):\n # set up the python path so that modules for this\n # function can be loaded.\n self.configure_path(cat,code)\n try: \n function_list += cat[code]\n except: #SystemError and ImportError so far seen \n # problems loading a function from the catalog. Try to\n # repair the cause.\n cat.close()\n self.repair_catalog(path,code)\n self.unconfigure_path() \n return function_list\n\n\n def repair_catalog(self,catalog_path,code):\n \"\"\" Remove entry for code from catalog_path\n \n Occasionally catalog entries could get corrupted. An example\n would be when a module that had functions in the catalog was\n deleted or moved on the disk. The best current repair method is \n just to trash the entire catalog entry for this piece of code. \n This may loose function entries that are valid, but thats life.\n \n catalog_path must be writable for repair. If it isn't, the\n function exists with a warning. \n \"\"\"\n writable_cat = None\n if not os.path.exists(catalog_path):\n return\n try:\n writable_cat = get_catalog(catalog_path,'w')\n except:\n print 'warning: unable to repair catalog entry\\n %s\\n in\\n %s' % \\\n (code,catalog_path)\n return \n if writable_cat.has_key(code):\n print 'repairing catalog by removing key'\n del writable_cat[code]\n \n # it is possible that the path key doesn't exist (if the function registered\n # was a built-in function), so we have to check if the path exists before\n # arbitrarily deleting it.\n path_key = self.path_key(code) \n if writable_cat.has_key(path_key)\n del writable_cat[path_key] \n \n def get_functions_fast(self,code):\n \"\"\" Return list of functions for code from the cache.\n \n Return an empty list if the code entry is not found.\n \"\"\"\n return self.cache.get(code,[])\n \n def get_functions(self,code,module_dir=None):\n \"\"\" Return the list of functions associated with this code fragment.\n \n The cache is first searched for the function. If an entry\n in the cache is not found, then catalog files on disk are \n searched for the entry. This is slooooow, but only happens\n once per code object. All the functions found in catalog files\n on a cache miss are loaded into the cache to speed up future calls.\n The search order is as follows:\n \n 1. user specified path (from catalog initialization)\n 2. directories from the PYTHONCOMPILED environment variable\n 3. The temporary directory on your platform.\n\n The path specified by module_dir will replace the 'MODULE' \n place holder in the catalog search path. See build_search_order()\n for more info on the search path. \n \"\"\" \n # Fast!! try cache first.\n if self.cache.has_key(code):\n return self.cache[code]\n \n # 2. Slow!! read previously compiled functions from disk.\n try:\n self.set_module_directory(module_dir)\n function_list = self.get_cataloged_functions(code)\n if code:\n function_list\n # put function_list in cache to save future lookups.\n if function_list:\n self.cache[code] = function_list\n # return function_list, empty or otherwise.\n finally:\n self.clear_module_directory()\n return function_list\n\n def add_function(self,code,function,module_dir=None):\n \"\"\" Adds a function to the catalog.\n \n The function is added to the cache as well as the first\n writable file catalog found in the search path. If no\n code entry exists in the cache, the on disk catalogs\n are loaded into the cache and function is added to the\n beginning of the function list.\n \n The path specified by module_dir will replace the 'MODULE' \n place holder in the catalog search path. See build_search_order()\n for more info on the search path. \n \"\"\" \n\n # 1. put it in the cache.\n if self.cache.has_key(code):\n if function not in self.cache[code]:\n self.cache[code].insert(0,function)\n else: \n # Load functions and put this one up front\n self.cache[code] = self.get_functions(code) \n self.fast_cache(code,function)\n \n # 2. Store the function entry to disk. \n try:\n self.set_module_directory(module_dir)\n self.add_function_persistent(code,function)\n finally:\n self.clear_module_directory()\n \n def add_function_persistent(self,code,function):\n \"\"\" Store the code->function relationship to disk.\n \n Two pieces of information are needed for loading functions\n from disk -- the function pickle (which conveniently stores\n the module name, etc.) and the path to its module's directory.\n The latter is needed so that the function can be loaded no\n matter what the user's Python path is.\n \"\"\" \n # add function to data in first writable catalog\n mode = 'cw' # create, write\n cat_file = self.get_writable_dir()\n cat = get_catalog(cat_file,mode)\n if cat is None:\n cat_dir = default_dir()\n cat = get_catalog(cat_file,mode)\n if cat is None:\n cat_dir = default_dir() \n cat_file = catalog_path(cat_dir)\n print 'problems with default catalog -- removing'\n os.remove(cat_file)\n cat = get_catalog(cat_dir,mode)\n if cat is None:\n raise ValueError, 'Failed to access a catalog for storing functions' \n function_list = [function] + cat.get(code,[])\n cat[code] = function_list\n \n # now add needed path information for loading function\n module = getmodule(function)\n try:\n # built in modules don't have the __file__ extension, so this\n # will fail. Just pass in this case since path additions aren't\n # needed for built-in modules.\n mod_path,f=os.path.split(os.path.abspath(module.__file__))\n pkey = self.path_key(code)\n cat[pkey] = [mod_path] + cat.get(pkey,[])\n except:\n pass\n\n def fast_cache(self,code,function):\n \"\"\" Move function to the front of the cache entry for code\n \n If future calls to the function have the same type signature,\n this will speed up access significantly because the first\n function call is correct.\n \n Note: The cache added to the inline_tools module is significantly\n faster than always calling get_functions, so this isn't\n as necessary as it used to be. Still, it's probably worth\n doing. \n \"\"\"\n try:\n if self.cache[code][0] == function:\n return\n except: # KeyError, IndexError \n pass\n try:\n self.cache[code].remove(function)\n except ValueError:\n pass\n # put new function at the beginning of the list to search.\n self.cache[code].insert(0,function)\n \ndef test():\n from scipy_test import module_test\n module_test(__name__,__file__)\n\ndef test_suite():\n from scipy_test import module_test_suite\n return module_test_suite(__name__,__file__) \n", "methods": [ { "name": "getmodule", "long_name": "getmodule( object )", "filename": "catalog.py", "nloc": 13, "complexity": 7, "token_count": 75, "parameters": [ "object" ], "start_line": 37, "end_line": 62, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "expr_to_filename", "long_name": "expr_to_filename( expr )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 24, "parameters": [ "expr" ], "start_line": 64, "end_line": 73, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "unique_file", "long_name": "unique_file( d , expr )", "filename": "catalog.py", "nloc": 13, "complexity": 8, "token_count": 89, "parameters": [ "d", "expr" ], "start_line": 75, "end_line": 97, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 0 }, { "name": "default_dir", "long_name": "default_dir( )", "filename": "catalog.py", "nloc": 18, "complexity": 5, "token_count": 145, "parameters": [], "start_line": 99, "end_line": 132, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 34, "top_nesting_level": 0 }, { "name": "default_temp_dir", "long_name": "default_temp_dir( )", "filename": "catalog.py", "nloc": 9, "complexity": 3, "token_count": 64, "parameters": [], "start_line": 134, "end_line": 142, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 0 }, { "name": "os_dependent_catalog_name", "long_name": "os_dependent_catalog_name( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 145, "end_line": 157, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 0 }, { "name": "catalog_path", "long_name": "catalog_path( module_path )", "filename": "catalog.py", "nloc": 12, "complexity": 3, "token_count": 105, "parameters": [ "module_path" ], "start_line": 159, "end_line": 184, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "get_catalog", "long_name": "get_catalog( module_path , mode = 'r' )", "filename": "catalog.py", "nloc": 7, "complexity": 2, "token_count": 35, "parameters": [ "module_path", "mode" ], "start_line": 186, "end_line": 204, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 0 }, { "name": "__init__", "long_name": "__init__( self , user_path_list = None )", "filename": "catalog.py", "nloc": 10, "complexity": 3, "token_count": 60, "parameters": [ "self", "user_path_list" ], "start_line": 233, "end_line": 248, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "set_module_directory", "long_name": "set_module_directory( self , module_dir )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self", "module_dir" ], "start_line": 250, "end_line": 256, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "get_module_directory", "long_name": "get_module_directory( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 257, "end_line": 260, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "clear_module_directory", "long_name": "clear_module_directory( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 261, "end_line": 264, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "get_environ_path", "long_name": "get_environ_path( self )", "filename": "catalog.py", "nloc": 9, "complexity": 3, "token_count": 55, "parameters": [ "self" ], "start_line": 266, "end_line": 280, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "build_search_order", "long_name": "build_search_order( self )", "filename": "catalog.py", "nloc": 11, "complexity": 4, "token_count": 62, "parameters": [ "self" ], "start_line": 282, "end_line": 304, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "get_catalog_files", "long_name": "get_catalog_files( self )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 34, "parameters": [ "self" ], "start_line": 306, "end_line": 315, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_existing_files", "long_name": "get_existing_files( self )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 27, "parameters": [ "self" ], "start_line": 317, "end_line": 322, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_writable_file.file_test", "long_name": "get_writable_file.file_test( x )", "filename": "catalog.py", "nloc": 4, "complexity": 3, "token_count": 43, "parameters": [ "x" ], "start_line": 336, "end_line": 339, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 2 }, { "name": "get_writable_file", "long_name": "get_writable_file( self , existing_only = 0 )", "filename": "catalog.py", "nloc": 12, "complexity": 3, "token_count": 55, "parameters": [ "self", "existing_only" ], "start_line": 324, "end_line": 345, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "get_writable_dir", "long_name": "get_writable_dir( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self" ], "start_line": 347, "end_line": 352, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "unique_module_name", "long_name": "unique_module_name( self , code , module_dir = None )", "filename": "catalog.py", "nloc": 9, "complexity": 4, "token_count": 53, "parameters": [ "self", "code", "module_dir" ], "start_line": 354, "end_line": 369, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "path_key", "long_name": "path_key( self , code )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "self", "code" ], "start_line": 371, "end_line": 374, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "configure_path", "long_name": "configure_path( self , cat , code )", "filename": "catalog.py", "nloc": 7, "complexity": 2, "token_count": 47, "parameters": [ "self", "cat", "code" ], "start_line": 376, "end_line": 388, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "unconfigure_path", "long_name": "unconfigure_path( self )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 390, "end_line": 396, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "get_cataloged_functions", "long_name": "get_cataloged_functions( self , code )", "filename": "catalog.py", "nloc": 15, "complexity": 5, "token_count": 86, "parameters": [ "self", "code" ], "start_line": 398, "end_line": 427, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 30, "top_nesting_level": 1 }, { "name": "repair_catalog", "long_name": "repair_catalog( self , catalog_path , code )", "filename": "catalog.py", "nloc": 16, "complexity": 5, "token_count": 83, "parameters": [ "self", "catalog_path", "code" ], "start_line": 430, "end_line": 460, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 31, "top_nesting_level": 1 }, { "name": "get_functions_fast", "long_name": "get_functions_fast( self , code )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 20, "parameters": [ "self", "code" ], "start_line": 462, "end_line": 467, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_functions", "long_name": "get_functions( self , code , module_dir = None )", "filename": "catalog.py", "nloc": 13, "complexity": 5, "token_count": 69, "parameters": [ "self", "code", "module_dir" ], "start_line": 469, "end_line": 503, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 35, "top_nesting_level": 1 }, { "name": "add_function", "long_name": "add_function( self , code , function , module_dir = None )", "filename": "catalog.py", "nloc": 12, "complexity": 4, "token_count": 94, "parameters": [ "self", "code", "function", "module_dir" ], "start_line": 505, "end_line": 533, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 29, "top_nesting_level": 1 }, { "name": "add_function_persistent", "long_name": "add_function_persistent( self , code , function )", "filename": "catalog.py", "nloc": 24, "complexity": 5, "token_count": 166, "parameters": [ "self", "code", "function" ], "start_line": 535, "end_line": 572, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 38, "top_nesting_level": 1 }, { "name": "fast_cache", "long_name": "fast_cache( self , code , function )", "filename": "catalog.py", "nloc": 11, "complexity": 4, "token_count": 59, "parameters": [ "self", "code", "function" ], "start_line": 574, "end_line": 596, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "test", "long_name": "test( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 598, "end_line": 600, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 602, "end_line": 604, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "methods_before": [ { "name": "getmodule", "long_name": "getmodule( object )", "filename": "catalog.py", "nloc": 13, "complexity": 7, "token_count": 75, "parameters": [ "object" ], "start_line": 37, "end_line": 62, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "expr_to_filename", "long_name": "expr_to_filename( expr )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 24, "parameters": [ "expr" ], "start_line": 64, "end_line": 73, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 0 }, { "name": "unique_file", "long_name": "unique_file( d , expr )", "filename": "catalog.py", "nloc": 13, "complexity": 8, "token_count": 89, "parameters": [ "d", "expr" ], "start_line": 75, "end_line": 97, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 0 }, { "name": "default_dir", "long_name": "default_dir( )", "filename": "catalog.py", "nloc": 18, "complexity": 5, "token_count": 145, "parameters": [], "start_line": 99, "end_line": 132, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 34, "top_nesting_level": 0 }, { "name": "default_temp_dir", "long_name": "default_temp_dir( )", "filename": "catalog.py", "nloc": 9, "complexity": 3, "token_count": 64, "parameters": [], "start_line": 134, "end_line": 142, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 9, "top_nesting_level": 0 }, { "name": "os_dependent_catalog_name", "long_name": "os_dependent_catalog_name( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [], "start_line": 145, "end_line": 157, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 0 }, { "name": "catalog_path", "long_name": "catalog_path( module_path )", "filename": "catalog.py", "nloc": 12, "complexity": 3, "token_count": 105, "parameters": [ "module_path" ], "start_line": 159, "end_line": 184, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 26, "top_nesting_level": 0 }, { "name": "get_catalog", "long_name": "get_catalog( module_path , mode = 'r' )", "filename": "catalog.py", "nloc": 7, "complexity": 2, "token_count": 35, "parameters": [ "module_path", "mode" ], "start_line": 186, "end_line": 204, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 19, "top_nesting_level": 0 }, { "name": "__init__", "long_name": "__init__( self , user_path_list = None )", "filename": "catalog.py", "nloc": 10, "complexity": 3, "token_count": 60, "parameters": [ "self", "user_path_list" ], "start_line": 233, "end_line": 248, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "set_module_directory", "long_name": "set_module_directory( self , module_dir )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 13, "parameters": [ "self", "module_dir" ], "start_line": 250, "end_line": 256, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "get_module_directory", "long_name": "get_module_directory( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 10, "parameters": [ "self" ], "start_line": 257, "end_line": 260, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "clear_module_directory", "long_name": "clear_module_directory( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 11, "parameters": [ "self" ], "start_line": 261, "end_line": 264, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "get_environ_path", "long_name": "get_environ_path( self )", "filename": "catalog.py", "nloc": 9, "complexity": 3, "token_count": 55, "parameters": [ "self" ], "start_line": 266, "end_line": 280, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 15, "top_nesting_level": 1 }, { "name": "build_search_order", "long_name": "build_search_order( self )", "filename": "catalog.py", "nloc": 11, "complexity": 4, "token_count": 62, "parameters": [ "self" ], "start_line": 282, "end_line": 304, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "get_catalog_files", "long_name": "get_catalog_files( self )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 34, "parameters": [ "self" ], "start_line": 306, "end_line": 315, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 10, "top_nesting_level": 1 }, { "name": "get_existing_files", "long_name": "get_existing_files( self )", "filename": "catalog.py", "nloc": 4, "complexity": 1, "token_count": 27, "parameters": [ "self" ], "start_line": 317, "end_line": 322, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_writable_file.file_test", "long_name": "get_writable_file.file_test( x )", "filename": "catalog.py", "nloc": 4, "complexity": 3, "token_count": 43, "parameters": [ "x" ], "start_line": 336, "end_line": 339, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 2 }, { "name": "get_writable_file", "long_name": "get_writable_file( self , existing_only = 0 )", "filename": "catalog.py", "nloc": 12, "complexity": 3, "token_count": 55, "parameters": [ "self", "existing_only" ], "start_line": 324, "end_line": 345, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 22, "top_nesting_level": 1 }, { "name": "get_writable_dir", "long_name": "get_writable_dir( self )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 19, "parameters": [ "self" ], "start_line": 347, "end_line": 352, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "unique_module_name", "long_name": "unique_module_name( self , code , module_dir = None )", "filename": "catalog.py", "nloc": 9, "complexity": 4, "token_count": 53, "parameters": [ "self", "code", "module_dir" ], "start_line": 354, "end_line": 369, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 16, "top_nesting_level": 1 }, { "name": "path_key", "long_name": "path_key( self , code )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 12, "parameters": [ "self", "code" ], "start_line": 371, "end_line": 374, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 4, "top_nesting_level": 1 }, { "name": "configure_path", "long_name": "configure_path( self , cat , code )", "filename": "catalog.py", "nloc": 7, "complexity": 2, "token_count": 47, "parameters": [ "self", "cat", "code" ], "start_line": 376, "end_line": 388, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 13, "top_nesting_level": 1 }, { "name": "unconfigure_path", "long_name": "unconfigure_path( self )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 24, "parameters": [ "self" ], "start_line": 390, "end_line": 396, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 7, "top_nesting_level": 1 }, { "name": "get_cataloged_functions", "long_name": "get_cataloged_functions( self , code )", "filename": "catalog.py", "nloc": 15, "complexity": 5, "token_count": 86, "parameters": [ "self", "code" ], "start_line": 398, "end_line": 427, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 30, "top_nesting_level": 1 }, { "name": "repair_catalog", "long_name": "repair_catalog( self , catalog_path , code )", "filename": "catalog.py", "nloc": 16, "complexity": 5, "token_count": 82, "parameters": [ "self", "catalog_path", "code" ], "start_line": 430, "end_line": 460, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 31, "top_nesting_level": 1 }, { "name": "get_functions_fast", "long_name": "get_functions_fast( self , code )", "filename": "catalog.py", "nloc": 2, "complexity": 1, "token_count": 20, "parameters": [ "self", "code" ], "start_line": 462, "end_line": 467, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 6, "top_nesting_level": 1 }, { "name": "get_functions", "long_name": "get_functions( self , code , module_dir = None )", "filename": "catalog.py", "nloc": 13, "complexity": 5, "token_count": 69, "parameters": [ "self", "code", "module_dir" ], "start_line": 469, "end_line": 503, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 35, "top_nesting_level": 1 }, { "name": "add_function", "long_name": "add_function( self , code , function , module_dir = None )", "filename": "catalog.py", "nloc": 12, "complexity": 4, "token_count": 94, "parameters": [ "self", "code", "function", "module_dir" ], "start_line": 505, "end_line": 533, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 29, "top_nesting_level": 1 }, { "name": "add_function_persistent", "long_name": "add_function_persistent( self , code , function )", "filename": "catalog.py", "nloc": 24, "complexity": 5, "token_count": 166, "parameters": [ "self", "code", "function" ], "start_line": 535, "end_line": 572, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 38, "top_nesting_level": 1 }, { "name": "fast_cache", "long_name": "fast_cache( self , code , function )", "filename": "catalog.py", "nloc": 11, "complexity": 4, "token_count": 59, "parameters": [ "self", "code", "function" ], "start_line": 574, "end_line": 596, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 23, "top_nesting_level": 1 }, { "name": "test", "long_name": "test( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 14, "parameters": [], "start_line": 598, "end_line": 600, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 }, { "name": "test_suite", "long_name": "test_suite( )", "filename": "catalog.py", "nloc": 3, "complexity": 1, "token_count": 15, "parameters": [], "start_line": 602, "end_line": 604, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 3, "top_nesting_level": 0 } ], "changed_methods": [ { "name": "repair_catalog", "long_name": "repair_catalog( self , catalog_path , code )", "filename": "catalog.py", "nloc": 16, "complexity": 5, "token_count": 83, "parameters": [ "self", "catalog_path", "code" ], "start_line": 430, "end_line": 460, "fan_in": 0, "fan_out": 0, "general_fan_out": 0, "length": 31, "top_nesting_level": 1 } ], "nloc": 321, "complexity": 91, "token_count": 1735, "diff_parsed": { "added": [ " if writable_cat.has_key(path_key):" ], "deleted": [ " if writable_cat.has_key(path_key)" ] } } ] } ]