search for: autohide

Hi all! I usually keep the panels on my Centos 6.6 (Gnome) so they auto-hide, but t'other day I wanted to keep the top panel visible for a while to make the clock visible for doing some rough timings. so I open the top panel, click properties, and UNcheck the "autohide" checkbox, close the properties menu, and to my surprise, the panel still autohides. Went thru that exercise several times ("come on guys, lets keep doing the same thing over and over til it works!", like congress does) So I open up the gnome configuration editor and browse around t...

...PM, Bill Maltby (C4B) wrote: > I'm still trying to find the > thing I used back in C5(?) that raised the panels when the mouse hovered > over it for X seconds. With C6 I can't find it anymore and it switches > way too fast. I presume you're talking about panels with "Autohide" set. If you have the GUI gconf-editor installed, it's under apps/panel/global/panel_show_delay. You can also set it from the command line: gconftool-2 --type int --set /apps/panel/global/panel_show_delay 500 (The default is 300, unit is milliseconds). -- Bob Nichols "NOS...

There should be no semantic difference between linkonce_odr and weak_odr, except that weak_odr is non-discardable. Why doesn't the autohide optimization work just as well on weak_odr + unnamed_addr as linkonce_odr + unnamed_addr? On Tue, Feb 6, 2018 at 5:35 PM, Steven Wu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I recently found that thinLTO doesn't deal with globals that has > linkonce_odr and...

That is a good question and I don't know. The optimization is defined include/llvm/Analysis/ObjectUtils.h. If I enable that for weak_odr + unnamed_addr, no tests are failing so I guess it is a safe optimization? :) It is probably because the autohide optimization is targeted at c++ templates and inline functions and we know they have linkonce_odr linkage, which suggests whoever uses this symbol should have their own copy. Because the linkonce_odr is safe to drop so it is safe to assume that nothing else should be relying on the symbol to be ava...

Hi, I recently found that thinLTO doesn't deal with globals that has linkonce_odr and unnamed_addr (for macho at least) because it prohibits the autohide optimization during link time. In LLVM, we tagged a global linkonce_odr and unnamed_addr to indicate to the linker can hide them from symbol table if they were picked (aka, linkonce_odr_auto_hide linkage). It is very commonly used for some type of Tables for c++ code in clang for example. However,...

...t apple.com> wrote: > That is a good question and I don't know. The optimization is > defined include/llvm/Analysis/ObjectUtils.h. If I enable that for > weak_odr + unnamed_addr, no tests are failing so I guess it is a safe > optimization? :) > > It is probably because the autohide optimization is targeted at c++ > templates and inline functions and we know they have linkonce_odr linkage, > which suggests whoever uses this symbol should have their own copy. Because > the linkonce_odr is safe to drop so it is safe to assume that nothing else > should be relying on...

...Hi all! > > I usually keep the panels on my Centos 6.6 (Gnome) so they auto-hide, > but t'other day I wanted to keep the top panel visible for a while to > make the clock visible for doing some rough timings. > > so I open the top panel, click properties, and UNcheck the "autohide" > checkbox, close the properties menu, and to my surprise, the panel > still autohides. Went thru that exercise several times ("come on guys, > lets keep doing the same thing over and over til it works!", like > congress does) > > So I open up the gnome configurati...

On 01/11/2015 04:19 PM, Bill Maltby (C4B) wrote: > On Fri, 2015-01-09 at 21:02 -0600, Robert Nichols wrote: >> I presume you're talking about panels with "Autohide" set. If you have >> the GUI gconf-editor installed, it's under apps/panel/global/panel_show_delay. >> You can also set it from the command line: >> >> gconftool-2 --type int --set /apps/panel/global/panel_show_delay 500 >> >> (The default is 300,...

Hello I have been trying a number of security/login generators recently. My favourite so far is the Acts_as_authenticated. I like the fact that it is only billed as a starting point and doesn''t try to do everything. I would like to add security roles to it, so that some of my controller actions can only be used by an admin role. Has anybody implemented this using

...> > I'm still trying to find the > > thing I used back in C5(?) that raised the panels when the mouse hovered > > over it for X seconds. With C6 I can't find it anymore and it switches > > way too fast. > > I presume you're talking about panels with "Autohide" set. If you have > the GUI gconf-editor installed, it's under apps/panel/global/panel_show_delay. > You can also set it from the command line: > > gconftool-2 --type int --set /apps/panel/global/panel_show_delay 500 > > (The default is 300, unit is milliseconds)....

...;t think weakodr_addr + unnamed_addr is safe to hide in all cases. I don't know if I interpreted local_unnamed_addr correctly but I think it is mostly the same in thinLTO for ld64. The code generator only looks at the individual module and ld64 will be in charge of merging all the symbols with autohide. It doesn't really help in this case. But it is interesting in general because according to the definition for local_unnamed_addr, the symbol has to be linkonce_odr to be auto hide as well. ThinLTO promotion can break that as well. Steven > On Feb 7, 2018, at 11:44 AM, Mehdi AMINI <jo...

...Tue, Feb 6, 2018 at 5:35 PM, Steven Wu <stevenwu at apple.com> wrote: >> >>> Hi, >>> >>> I recently found that thinLTO doesn't deal with globals that has >>> linkonce_odr and unnamed_addr (for macho at least) because it prohibits the >>> autohide optimization during link time. >>> >>> In LLVM, we tagged a global linkonce_odr and unnamed_addr to indicate to >>> the linker can hide them from symbol table if they were picked (aka, >>> linkonce_odr_auto_hide linkage). It is very commonly used for some type of...

...d_clip_url(@clips) ) -%>", ''type'' : ''video'', ''streching'' : ''uniform'' , ''smoothing'' : ''true'', ''controlbar.position'' : ''bottom'', ''controlbar.autohide'' : ''true'', ''image'' : ''/assets/splash_image.jpg'', ''modes'': [ {''type'' : ''html5''}, {''type'' : ''flash'', ''src'' : ''/assets/ jw...

...unnamed_addr is safe to hide in all cases. > > I don't know if I interpreted local_unnamed_addr correctly but I think it > is mostly the same in thinLTO for ld64. The code generator only looks at > the individual module and ld64 will be in charge of merging all the symbols > with autohide. It doesn't really help in this case. But it is interesting > in general because according to the definition for local_unnamed_addr, the > symbol has to be linkonce_odr to be auto hide as well. ThinLTO promotion > can break that as well. > > Steven > > > > On Feb 7, 2...

...to hide in all cases. >> >> I don't know if I interpreted local_unnamed_addr correctly but I think it >> is mostly the same in thinLTO for ld64. The code generator only looks at >> the individual module and ld64 will be in charge of merging all the symbols >> with autohide. It doesn't really help in this case. But it is interesting >> in general because according to the definition for local_unnamed_addr, the >> symbol has to be linkonce_odr to be auto hide as well. ThinLTO promotion >> can break that as well. >> >> Steven >> &g...

...>> That is a good question and I don't know. The optimization is >> defined include/llvm/Analysis/ObjectUtils.h. If I enable that for >> weak_odr + unnamed_addr, no tests are failing so I guess it is a safe >> optimization? :) >> >> It is probably because the autohide optimization is targeted at c++ >> templates and inline functions and we know they have linkonce_odr linkage, >> which suggests whoever uses this symbol should have their own copy. Because >> the linkonce_odr is safe to drop so it is safe to assume that nothing else >> shoul...

...eakodr_addr + unnamed_addr is safe to hide in all cases. > > I don't know if I interpreted local_unnamed_addr correctly but I think it is mostly the same in thinLTO for ld64. The code generator only looks at the individual module and ld64 will be in charge of merging all the symbols with autohide. It doesn't really help in this case. But it is interesting in general because according to the definition for local_unnamed_addr, the symbol has to be linkonce_odr to be auto hide as well. ThinLTO promotion can break that as well. > > Steven > > > >> On Feb 7, 2018, at...

...s. >>> >>> I don't know if I interpreted local_unnamed_addr correctly but I think >>> it is mostly the same in thinLTO for ld64. The code generator only looks at >>> the individual module and ld64 will be in charge of merging all the symbols >>> with autohide. It doesn't really help in this case. But it is interesting >>> in general because according to the definition for local_unnamed_addr, the >>> symbol has to be linkonce_odr to be auto hide as well. ThinLTO promotion >>> can break that as well. >>> >>&gt...

...ddr + unnamed_addr is safe to hide in all cases. >> >> I don't know if I interpreted local_unnamed_addr correctly but I think it is mostly the same in thinLTO for ld64. The code generator only looks at the individual module and ld64 will be in charge of merging all the symbols with autohide. It doesn't really help in this case. But it is interesting in general because according to the definition for local_unnamed_addr, the symbol has to be linkonce_odr to be auto hide as well. ThinLTO promotion can break that as well. >> >> Steven >> >> >> >&gt...

...would affect link semantics. Thanks, Teresa On Tue, Feb 6, 2018 at 5:35 PM, Steven Wu <stevenwu at apple.com> wrote: > Hi, > > I recently found that thinLTO doesn't deal with globals that has > linkonce_odr and unnamed_addr (for macho at least) because it prohibits the > autohide optimization during link time. > > In LLVM, we tagged a global linkonce_odr and unnamed_addr to indicate to > the linker can hide them from symbol table if they were picked (aka, > linkonce_odr_auto_hide linkage). It is very commonly used for some type of > Tables for c++ code in cla...