Полный стек: Traceback (most recent call last):
File "C:\Titanium\SDK\sdk\win32\1.2.0.RC4\tibuild.py", line 112, in <module>
app = environment.create_app(appdir)
File "C:\Titanium\SDK\sdk\win32\1.2.0.RC4\env.py", line 70, in create_app
return win32_app.Win32App(self, path)
File "C:\Titanium\SDK\sdk\win32\1.2.0.RC4\app.py", line 30, in __init__
self.sdk_dir = fix_path((self.env.get_sdk_dir(self.runtime_version)))
File "C:\Titanium\SDK\sdk\win32\1.2.0.RC4\env.py", line 99, in get_sdk_dir
c = self.get_component('sdk', None, version)
File "C:\Titanium\SDK\sdk\win32\1.2.0.RC4\env.py", line 92, in get_component
target = p.join(target, version)
File "C:\Titanium\plugins\com.appcelerator.titanium.python.win32_1.0.0.1338515410\python\lib\ntpath.py", line 108, in join
path += "\\" + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 9: ordinal not in range(128)
Студия сама не могла найти desktop sdk, пришлось искать урл.
Сделал тестовый проектик — не собирается, пишет большой стек вызова, который заканчивается:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 9: ordinal not in range(128)
Если в имени пути есть русские символы, то в логе вижу квадраты, кривая работа с юникодом? Перенес из-за этого SDK (тоже не без танцев с бубном) в другую папку — не помогло.
Ошибаетесь, в CEF много полезных событий. Одно из которых, возникает когда браузер делает HTTP запрос. html берется прямо из zip, без распаковки на диск. Можно заменить ответ на любой url.
Честно говоря не смотрел даже какие события у CEF нужно перехватить и как это организовать. Думаю, должно быть не сложно. Мне в проекте пока это не нужно.
Если вы хорошо знаете как это сделать, может добавите в проект?
Марсоход интересный проект, наблюдаю за развитем. Но в данном случае вы на нее возложили какие-то совсем второстепенные задачи. Складывается впечатление, что на плате все таки не хватает процессора.
Очевидно, мне одному так кажеться, ну или мы сильно в меньшинстве.
В качестве реабилитации, немного конструктива, то что мне кажется не правильным, помима факта неверного решения.
FindNextTaskUsingPriorityRules — этого метода быть не должно, зачем такие сложности и при этом нет никакой гибкости. LINQ там лишнее, простой проход в цикле был более уместен, и находил бы задачу за один проход, и был более читабельным на мой взгляд. Так еще потом при удалении задачи из списка в методе DequeueTask, потребуется еще один проход.
Бегло просматривая, встретил еще пару мест, где происходит примерно тоже самое.
Можно было организовать три очереди, чтобы исключить поиск полностью.
Или например то, что задача запускает поток, да возможно что автор написал так из-за того что не разобрался что такое ThreadPool, но тем не менее: задача — ее выполняют, пул потоков — тут даже нечего добавить. Логично же, что потоки должны быть в пуле?!
И зачем здесь патерны, вообще и в частности?! Фабрика задач, упростит понимание кода — не думаю. Или пул нужно обязательно делать синглтоном — нет, статические методы решают задачу в данном случае.
Я считаю патерны полезны в основном как средство как средство коммуникации между разработчиками.
Наверное выход, правда это не хвостовая рекурсия, и это «тянет» стек.
А общей оптимизации для таких случаев нет? К примеру, список может быть двухсвязным, как с ним быть?
Traceback (most recent call last): File "C:\Titanium\SDK\sdk\win32\1.2.0.RC4\tibuild.py", line 112, in <module> app = environment.create_app(appdir) File "C:\Titanium\SDK\sdk\win32\1.2.0.RC4\env.py", line 70, in create_app return win32_app.Win32App(self, path) File "C:\Titanium\SDK\sdk\win32\1.2.0.RC4\app.py", line 30, in __init__ self.sdk_dir = fix_path((self.env.get_sdk_dir(self.runtime_version))) File "C:\Titanium\SDK\sdk\win32\1.2.0.RC4\env.py", line 99, in get_sdk_dir c = self.get_component('sdk', None, version) File "C:\Titanium\SDK\sdk\win32\1.2.0.RC4\env.py", line 92, in get_component target = p.join(target, version) File "C:\Titanium\plugins\com.appcelerator.titanium.python.win32_1.0.0.1338515410\python\lib\ntpath.py", line 108, in join path += "\\" + b UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 9: ordinal not in range(128)Сделал тестовый проектик — не собирается, пишет большой стек вызова, который заканчивается:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 9: ordinal not in range(128)
Если в имени пути есть русские символы, то в логе вижу квадраты, кривая работа с юникодом? Перенес из-за этого SDK (тоже не без танцев с бубном) в другую папку — не помогло.
Если вы хорошо знаете как это сделать, может добавите в проект?
В качестве реабилитации, немного конструктива, то что мне кажется не правильным, помима факта неверного решения.
FindNextTaskUsingPriorityRules — этого метода быть не должно, зачем такие сложности и при этом нет никакой гибкости. LINQ там лишнее, простой проход в цикле был более уместен, и находил бы задачу за один проход, и был более читабельным на мой взгляд. Так еще потом при удалении задачи из списка в методе DequeueTask, потребуется еще один проход.
Бегло просматривая, встретил еще пару мест, где происходит примерно тоже самое.
Можно было организовать три очереди, чтобы исключить поиск полностью.
Или например то, что задача запускает поток, да возможно что автор написал так из-за того что не разобрался что такое ThreadPool, но тем не менее: задача — ее выполняют, пул потоков — тут даже нечего добавить. Логично же, что потоки должны быть в пуле?!
И зачем здесь патерны, вообще и в частности?! Фабрика задач, упростит понимание кода — не думаю. Или пул нужно обязательно делать синглтоном — нет, статические методы решают задачу в данном случае.
Я считаю патерны полезны в основном как средство как средство коммуникации между разработчиками.
А общей оптимизации для таких случаев нет? К примеру, список может быть двухсвязным, как с ним быть?