Sublime Forum

Package Control: A full-featured package manager

#75

@joaodrp, yes SublimeLinter uses a queue, which in theory should make it more responsive… particularly for larger files, but shorter files are also queued anyway. This is an option that might need some tweaking and perhaps we should have different linking timings for different file sizes (perhaps detecting the best automatically).

@aparajita, about the queue, if you navigate your file or change the cursor position that will prevent the queue from executing the linting of the code… this is because for large files being linted, if you change something and then you start moving around very quickly to change something else in the same file, the linting would kick in the middle, making the editor laggy for a bit while you move around (as I said, this is particularly noticeable in large or very large files being linted)

These and other things, like PEP 8, different configurable colors for different error levels, and more configuration flexibility are the differences between SublimeLint and SublimeLinter.

0 Likes

#76

What file type are you editing? How big is the file?

0 Likes

#77

I keep getting this message when I try to install Package Control (Mac OS X): urllib2.URLError: <urlopen error [Errno 64] Host is down>
the hostname seems fine (“http://sublime.wbond.net/Package%20Control.sublime-package”) and I can access the resource from my browser fine… just that urllib2 throws that exception. Any ideas?

EDIT: My mistake, it was the firewall blocking the ST2 app from accessing the internet… duh!

0 Likes

#78

Is there a way to give the auto_upgrade when ST2 start a delay between each run.
For something like: upgrade at most every 24 hours. I don’t need dozen upgrade check each days.
There is a cache_length settings but I don’t think it’s what I need.

Package Control is really an amazing piece of software, thanks wbond for it.

0 Likes

#79

[quote=“bizoo”]Is there a way to give the auto_upgrade when ST2 start a delay between each run.
For something like: upgrade at most every 24 hours. I don’t need dozen upgrade check each days.
There is a cache_length settings but I don’t think it’s what I need.

Package Control is really an amazing piece of software, thanks wbond for it.[/quote]

In version 1.2.0 it is now possible to set the minimum frequency between auto upgrades via the auto_upgrade_frequency setting, which defaults to 12 (hours).

0 Likes

#80

[quote=“wbond”]

[quote=“bizoo”]Is there a way to give the auto_upgrade when ST2 start a delay between each run.
For something like: upgrade at most every 24 hours. I don’t need dozen upgrade check each days.
There is a cache_length settings but I don’t think it’s what I need.

Package Control is really an amazing piece of software, thanks wbond for it.[/quote]

In version 1.2.0 it is now possible to set the minimum frequency between auto upgrades via the auto_upgrade_frequency setting, which defaults to 12 (hours).[/quote]

Nice, thanks for this update.

BTW, I experienced some issue with this update (with ST2 update in the same time):
-An infinite loop at the first launch (something with thread). There was 4 automatic upgrade when it happened (sublimelint, package control, …), so it could be another plugin.
-A crash with the update command.
Now it look that everything work fine.
Sorry not to be able to give you more information, if it happens again I will look closer at the issue.

0 Likes

#81

Small issue:

class PanelPrinter(): ... def __init__(self): ... self.window = sublime.active_window()
return None when ST2 start.

startup, version: 2112 windows x64 channel: dev ... Reloading plugin C:\Users\dwahli\AppData\Roaming\Sublime Text 2\Packages\ZenCoding\zenmeta.py Reloading plugin C:\Users\dwahli\AppData\Roaming\Sublime Text 2\Packages\ZenCoding\zentrackers.py Traceback (most recent call last): File ".\Package Control.py", line 1744, in <lambda> File ".\Package Control.py", line 1682, in __init__ File ".\Package Control.py", line 1229, in __init__ File ".\Package Control.py", line 661, in __init__ File ".\Package Control.py", line 30, in get File ".\Package Control.py", line 36, in __init__ AttributeError: 'NoneType' object has no attribute 'get_output_panel' loading bindings loading pointer bindings ...

0 Likes

#82

[quote=“bizoo”]Small issue:

class PanelPrinter(): ... def __init__(self): ... self.window = sublime.active_window()
return None when ST2 start.

startup, version: 2112 windows x64 channel: dev ... Reloading plugin C:\Users\dwahli\AppData\Roaming\Sublime Text 2\Packages\ZenCoding\zenmeta.py Reloading plugin C:\Users\dwahli\AppData\Roaming\Sublime Text 2\Packages\ZenCoding\zentrackers.py Traceback (most recent call last): File ".\Package Control.py", line 1744, in <lambda> File ".\Package Control.py", line 1682, in __init__ File ".\Package Control.py", line 1229, in __init__ File ".\Package Control.py", line 661, in __init__ File ".\Package Control.py", line 30, in get File ".\Package Control.py", line 36, in __init__ AttributeError: 'NoneType' object has no attribute 'get_output_panel' loading bindings loading pointer bindings ...[/quote]

Yes, it appears there is a startup issue that I did not catch. It seems to happen sometimes on Windows and pretty much every time on OS X. Version 1.2.2 should fix it.

0 Likes

#83

[quote=“sublimator”]I tried to upgrade PackageControl via itself but get Putty errors when it does the Loading Repositories = ]

http://blogdata.akalias.net/puttyerror.PNG

“version”: “1.2.1”

I clicked OK twice. Sublime went all white and crashed.

What’s it doing that needs putty out of curiosity?[/quote]

That would indicate that you cloned a git or hg repository into the Packages directory via TortoiseGit or TortoiseHg. That, or at least Package Control found a git or hg repository and also found TortoiseGit or TortoiseHg and was trying to use them to fetch the remote repository information.

I did just release version 1.2.2 of Package Control to fix a startup bug in 1.2.1 that was causing crashing on some machines.

0 Likes

#84

I have a crash with this scenario:

  • Execute the “Package Control: Install Package” command.

  • Switch to another windows before the end of the command.

  • Wait a few seconds.

  • Crash of ST2

It’s always reproducible.
If I minimize ST2 instead of put it’s windows on the background, it works fine.

startup, version: 2112 windows x64 channel: dev

0 Likes

#85

[quote=“bizoo”]I have a crash with this scenario:

  • Execute the “Package Control: Install Package” command.

  • Switch to another windows before the end of the command.

  • Wait a few seconds.

  • Crash of ST2

It’s always reproducible.
If I minimize ST2 instead of put it’s windows on the background, it works fine.

startup, version: 2112 windows x64 channel: dev[/quote]

I’ve tried a bunch of times to reproduce this, but I’ve been unable. What other plugins do you have installed?

What program are you switching too? I’ve tried switching to another Sublime window, Windows explorer and Chrome.

What package are you trying to install when this happens?

Do you have an antivirus program installed? Again, I’m just trying to figure out how your machine is different than mine.

And lastly, do you have any packages cloned via git or hg in your Packages directory?

0 Likes

#86

They should already be grouped by domain (github.com/wbond/sublime_packag … ol.py#L759), but you are saying you added a timeout between each download also? Could you throw a gist up of what you’ve changed?

0 Likes

#87

Yeah, that is on my list of things to do.

0 Likes

#88

Thanks for the code. I’ll run it through some testing on my various environments and then push it out to see if it alleviates issues for the windows users that have been having crashes.

0 Likes

#89

[quote=“sublimator”]I pushed some experimental alterations for your consideration: github.com/sublimator/sublime_p … ol.py#L797

100ms staggering between the requests seems to work for me.

I’ve loaded bitbucket pages firebug before and seem them use the api a lot, sometimes 4-5 ajax requests.[/quote]

I tried out the grouping you had but it is now taking around twice as long to bring up the package list and I am getting multiple retries every time. I think the extra time might be because you a joining on the first running downloader you hit.

I’m going to try and get my windows install in a situation where I have an error trying to get something from bitbucket or github and see if I can replicate the crashing. After that I an ensure there is a fix that works.

0 Likes

#90

[quote=“bizoo”]I have a crash with this scenario:

  • Execute the “Package Control: Install Package” command.

  • Switch to another windows before the end of the command.

  • Wait a few seconds.

  • Crash of ST2

It’s always reproducible.
If I minimize ST2 instead of put it’s windows on the background, it works fine.

startup, version: 2112 windows x64 channel: dev[/quote]

I was finally able to reproduce this. It appears that creating a hidden window subprocess for hg from within a thread in ST2 is causing the crash. I am guessing this is an issue with ST2, so I am going to see if I can provide Jon with enough information to look into it.

0 Likes

#91

Yes. I’m not sure why I had it in mind that joining one thread would stop the others. It will just stop the original spawning thread.

I’m going to try you solution again to see if I was just getting a fluke with the failures and timeouts. I suppose with a 5 second timeout that a couple of failures on github URL could easily make the process take a long time.

I’m not sure why I’ve experienced so many timeout issues when testing GitHub and BitBucket. I can browse the web no problem, and like you’ve mentioned, chrome has no trouble downloading 4+ assets from github at the same time, so I’m not sure why I have trouble with urllib2 and curl. I suppose maybe the fact that I need to spawn curl on Linux to download https URLs could be affecting performance, but that wouldn’t explain why I was getting similar timeout issues on my Win 7 vm.

Anyway, I’ve at least identified bizoo’s issue. I’ll try to work around that for now and then try your downloader solution and see if I can get that working any faster. Hopefully I’ll have a new, much more stable version out tonight or tomorrow.

0 Likes

#92

[quote=“sublimator”]Hrmmm, so I don’t think it is a subprocess/hg bug but rather some weird condition comprised of showing the quick_panel from a timeout inside a thread when the Sublime window doesn’t have focus. I guess only Jon would really know what the issue is there.

I got curious after going to bitbucket when in my notifications I saw a commit Guillermoo made to his Hg plugin. He was using windowless subprocess also. I then watched process explorer while alt - tabbing between it and Sublime and noticed Sublime crashing when git was the subprocess. Hrmm…

Anyway, so I found that it crashed fairly consistently at the same point, that being right at the end of PackageInstaller.make_package_list, after the very lastest package which in my group of plugins happens to be git controlled.

Hrmmm. So it seems to happen when switching windows. What if we make Sublime wait until it’s focused? Does it still crash?

[code] if os.name == ‘nt’:
from ctypes import windll
getwh = windll.user32.GetForegroundWindow

        while getwh() != self.window.hwnd():
            time.sleep(0.001)

[/code]

It doesn’t seem to in the 4-5 manual tests I’ve done. These crashes are only effecting us windows (lo|u)sers you say?[/quote]

Thanks for the tip about the quick panel. I found that this simple example shows the crash off.

# coding=utf-8
import sublime
import sublime_plugin
import threading
import time


class InstallPackageCommand(sublime_plugin.WindowCommand):
    def run(self):
        thread = InstallPackageThread(self.window)
        thread.start()


class InstallPackageThread(threading.Thread):
    def __init__(self, window):
        self.window = window
        threading.Thread.__init__(self)

    def run(self):
        time.sleep(3)
        def show_quick_panel():
            self.window.show_quick_panel('foo'], 'bar']], self.on_done)
        sublime.set_timeout(show_quick_panel, 0)
    
    def on_done(self, num):
        print num


sublime.active_window().run_command('install_package')

Basically if a set_timeout of 0 that shows a quick panel is called in a thread and Sublime isn’t the foremost window (on Windows) then it will crash. Changing the timeout to anything larger than 0 fixes the crash. Another interesting thing is that if the sublime window is not focused, the quick panel never shows, but instead fires the on_done callback with -1, like if the user had hit escape.

0 Likes

#93

[quote=“sublimator”]So the crash is NOT happening on linux/osx?

You are getting the -1 cancelling behaviour though?[/quote]

On Linux and OS X I do not get a crash and the quick panel does show even though another window has the focus. I can return focus to the ST2 window and interact with the quick panel.

[quote=“sublimator”]I kind of like having set_timeout not queue up/halt when Sublime is unactive.

It should show the quickpanel though eh and wait for input rather than cancel.[/quote]

Yeah, I would not expect set_timeout to queue up or halt when it is not active. I would expect the timers to run as normal. And I agree, I think the behavior on Linux and OS X seems correct with the quick panel showing and waiting for input.

0 Likes

#94

I just pushed version 1.2.5 out.

Thanks sublimator for all of the help. I ended up testing and getting the 150ms staggering to work well and I am seeing faster performance.

For a short term fix that isn’t too messy I updated all of the sublime.set_timeout() calls to 10ms instead of 0ms. This seems to prevent the crashing issue on Windows that bizoo was having and I think some other crashing issues that Windows users have mentioned when trying to install and upgrade packages.

0 Likes