search for: autohides

...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 to find apps/panel/default_setup/toplevels/top_panel and apps/panel/toplevels/top_panel....

On 01/09/2015 06:07 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

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

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

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

>From looking at the code, it seems like LLVM is basically opting MachO into -fvisibility-inlines-hidden all the time, i.e. if the function is linkonce, it's discardable, so mark it hidden to pretend the compiler inlined it and discarded it. However, this isn't conforming, because the addresses of inline functions will no longer compare equal across DSOs. Realistically, nobody cares

...'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 to find > apps/panel/default_setup/toplevels/top_panel and > apps...

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

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

On Fri, 2015-01-09 at 21:02 -0600, Robert Nichols wrote: > On 01/09/2015 06:07 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

We didn't drop unnamed_addr. I just don'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.

Something I haven't seen mentioned: why are we dropping the unnamed_addr? Can't we preserve it with the weak symbol? Would it be OK to add auto-hide in this case (maybe it would already happen)? Can we use the new local_unnamed_addr that was added (by pcc or Rafael I don't remember)? I think this attribute matches exactly the `auto-hide` semantic. Wasn't the idea that this could be

I was using a Flash video player within a previous Rails version app Moving to Rails 3.1.0 , I dob''t know where I should put the script ... I tried to move it into an app asset sub-directory assets - jwplayer - - player.swf but this raises an error "NetworkError: 406 Not Acceptable - http://localhost:3000/assets/jwplayer/player.swf" player.swf the flash script is given as a

> 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. What do you mean that the promotion can break that? The original description I found here: https://reviews.llvm.org/D20348 says that it is possible to exclude a global from the symbol table if three

2018-02-07 12:45 GMT-08:00 Steven Wu <stevenwu at apple.com>: > > > On Feb 7, 2018, at 12:36 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > 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. > > What do

> From looking at the code, it seems like LLVM is basically opting MachO into -fvisibility-inlines-hidden all the time, i.e. if the function is linkonce, it's discardable, so mark it hidden to pretend the compiler inlined it and discarded it. However, this isn't conforming, because the addresses of inline functions will no longer compare equal across DSOs. I think there is a nuance, it

> On Feb 7, 2018, at 12:36 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > 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. > > What do you mean that the promotion can break that? > > The original description I found

2018-02-08 9:33 GMT-08:00 Steven Wu <stevenwu at apple.com>: > > > On Feb 7, 2018, at 4:03 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2018-02-07 12:45 GMT-08:00 Steven Wu <stevenwu at apple.com>: > >> >> >> On Feb 7, 2018, at 12:36 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: >> >> > But it is

> On Feb 7, 2018, at 4:03 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2018-02-07 12:45 GMT-08:00 Steven Wu <stevenwu at apple.com <mailto:stevenwu at apple.com>>: > > >> On Feb 7, 2018, at 12:36 PM, Mehdi AMINI <joker.eph at gmail.com <mailto:joker.eph at gmail.com>> wrote: >> >> > But it is interesting in

Hi Steven, I'd prefer not to inhibit importing. I am also concerned about putting these symbols in the llvm.compiler_used (I don't recall earlier discussion around this, but it seems like it could have effects on optimization as you mention). What are the downsides of #2 (adding visibility hidden)? We already do this when promoting internal linkage to external due to importing. I'm