search for: imo

...s to explicitly contribute this to the LLVM project to make it unambiguous that it has been contributed and is completely available for folks not at Apple to iterate on the code and turn it into code-reviewable chunks. So whatever happens needs to be quite explicit in its nature as a contribution. IMO, a branch of the repository definitely qualifies. IMO, a pull request isn't as clear given that they haven't been used for contributions before. This is not a time to be innovative IMO. A branch as a staging location has been used many times over the history of the project though and seems...

...; need a "other endian" flag because we have fourcc codes for all sorts of > byte orders (i.e. DRM_FORMAT_XRGB8888 little endian == > DRM_FORMAT_BGRX8888 big endian). Yeah, those could be handled without the flag. But when mixed with any other format the code would look a bit weird IMO. So my idea with the flag was that if you display is big endian you always have the flag, and then you don't have to think so much which way the bytes go for each format. Less special casing is good IMO. > > The DRM_FORMAT_BIG_ENDIAN flags also seems not be used anywhere in the > cod...

...; need a "other endian" flag because we have fourcc codes for all sorts of > byte orders (i.e. DRM_FORMAT_XRGB8888 little endian == > DRM_FORMAT_BGRX8888 big endian). Yeah, those could be handled without the flag. But when mixed with any other format the code would look a bit weird IMO. So my idea with the flag was that if you display is big endian you always have the flag, and then you don't have to think so much which way the bytes go for each format. Less special casing is good IMO. > > The DRM_FORMAT_BIG_ENDIAN flags also seems not be used anywhere in the > cod...

...ugzilla: > > https://bugzilla.mindrot.org/show_bug.cgi?id=2468 > > The code gets little bit more complicated because of requirement to re-read > the configuration for every incoming connection. Giving a test and comments > would be very appreciated. I'll update the bug, but IMO re-reading config at runtime is a significant behaviour change and is probably unacceptable. We go through some hassle wrt re-execution to ensure that the configuration sshd is started with is the one that it. To do otherwise is IMO inviting surprise and trouble for administrators. -d

...replace a plain 'FileCheck'. > > The first approach seems cleaner to developers who read and write > tests (it suggests that they are invoking some "macro" -- but does > that matter?) The second approach is much easier to implement since > tests will be unchanged. IMO the biggest issue with (a) is that developers will continue to use `FileCheck` instead of `%FileCheck`. So IMO (a) should only be implemented if simultaneously there is a change that makes just plain `FileCheck` an error. Another approach would be to have a script or symlink `FileCheck-dump-input-...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, We are discussing removing the capability to chaining passdb backends. It's a decent idea but overly complicates things IMO and unless it has wide spread use, we'll probably axe it soon (voting is starting up on the samba-tecnnical ml now). To give you an example of what I mean, is anyone using something like: passdb backend = smbpasswd ldapsam If you haven't been using this type of configuration, don't...

...code. Extract common part from PCI drivers into separate > > > remove_conflicting_pci_framebuffers(). > > > > > > Signed-off-by: Micha? Miros?aw <mirq-linux at rere.qmqm.pl> > > > > Since the only driver that seems to use this is the staging one, which imo > > is a DOA project, not sure it's worth to bother with this here. > > afaik, this device is used in production by few manufacturers and it is > usefull for them to have it in the tree and the only reason it is still > in staging is because Tomi announced he will not take an...

...code. Extract common part from PCI drivers into separate > > > remove_conflicting_pci_framebuffers(). > > > > > > Signed-off-by: Micha? Miros?aw <mirq-linux at rere.qmqm.pl> > > > > Since the only driver that seems to use this is the staging one, which imo > > is a DOA project, not sure it's worth to bother with this here. > > afaik, this device is used in production by few manufacturers and it is > usefull for them to have it in the tree and the only reason it is still > in staging is because Tomi announced he will not take an...

...am.c:1216(tstream_tls_params_server)   Invalid permissions on TLS private key file 'server.key.pem':   owner uid 0 should be 0, mode 0440 should be 0600   This is known as CVE-2013-4476.   It there anyway to override this setting?  I do need 0440 here.  ( or 0400 ) 0600 is not needed imo.     Greetz,   Louis    

...about anything, happy to dig into it. - The core framework is there. It works, and we even have CGSCC passes using both Module and Function analyses with caching and everything. Yay! We also have initial loop pass infrastructure thanks to Justin! Yay! - The biggest missing piece of infrastructure IMO is communicating invalidation information between two parts of the pass manager itself when they are operating over the results of an analysis. Both the loop passes and the CGSCC passes really need this. I'm currently working on this and hope to finish the first cut at CGSCC stuff for this in a...

...others. >>> >> In OpenCL 2.0, you can cast between the generic address space and >> global/local/private, so there's also that to consider. >> >> Thanks for correction. My reference was the opencl 1.2 specification. > > Considering the case of OpenCL 2.0 IMO we would have another address space > that contains the private, the global and the local address spaces. > > > -Michele > > ______________________________**_________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://...

Hi! Since some time the download of the newest Asterisk does not contains the version number anymore, but is just called "asterisk-1.4-current.tar.gz" This gives me a tarball where I do not know the version without looking into the tarball. Thus, IMO it would be very useful to switch back to old schema war the download contained the version number. Thanks Klaus

Anyone ever thought about an Ethernet based channel bank? Basically a rack mount set of 24 IAXys? That would be cool, IMO. No wrangling with zaptel, etc. IAX as the * <-> Channel bank protocol. Just an idea...

...with addrspace modifier (3 for constant and 1 for global) so the optimizer can distinguish the two and using "address space metadata" can derive properties related to this address spaces. During the instruction selection the mapping information are used to drive the selection phase. IMO whenever possible both address spaces informations must be maintained. > > On Wed, Aug 7, 2013 at 7:15 PM, Michele Scandale > <michele.scandale at gmail.com <mailto:michele.scandale at gmail.com>> wrote: > > On 08/08/2013 12:55 AM, Matt Arsenault wrote: > >...

...> The first approach seems cleaner to developers who read and write >>> tests (it suggests that they are invoking some "macro" -- but does >>> that matter?) The second approach is much easier to implement since >>> tests will be unchanged. >> >> IMO the biggest issue with (a) is that developers will continue to use >> `FileCheck` instead of `%FileCheck`. So IMO (a) should only be >> implemented if simultaneously there is a change that makes just plain >> `FileCheck` an error. > > I think that within a month this knowle...

Hi, IMO we should support this, even though if given the option I'd have asked the linux guys not to invent a new triple. It's in linux now, and `uname -a` is a very standard way of obtaining the host's triple. James On Tue, 5 Jan 2016 at 08:34 Tim Northover via llvm-dev < llvm-dev at list...

...ay to build to build LLVM into a shared > library on Windows that's suitable for shipping. I don't remember the > details here; maybe Reid does. Some of the other platforms' binaries look like they also ship static libraries, and that would be more useful than no libraries at all IMO. I believe the issue with the dll build is marking symbols for dllexport. -Tony

...e very limited crypto algorithm selection in the resulting build). AFAIK most supported mainstream OSs have long since moved on from these versions. The only OSs that seem to use OpenSSL 1.0.x are RHEL7 (in some commercial limited extended support mode) and Ubuntu 14.04 (supported until 2024/04). IMO almost nobody will be upgrading OpenSSH on these systems, and (also IMO) they aren't worth the cost of maintaining the compatibility code. Before I go ahead and delete it, does anyone have opinions to the contrary? -d

...developers who read and write >>>>> tests (it suggests that they are invoking some "macro" -- but does >>>>> that matter?) The second approach is much easier to implement since >>>>> tests will be unchanged. >>>> >>>> IMO the biggest issue with (a) is that developers will continue to use >>>> `FileCheck` instead of `%FileCheck`. So IMO (a) should only be >>>> implemented if simultaneously there is a change that makes just plain >>>> `FileCheck` an error. >>> >>>...

...k'. >> >> The first approach seems cleaner to developers who read and write >> tests (it suggests that they are invoking some "macro" -- but does >> that matter?) The second approach is much easier to implement since >> tests will be unchanged. > > IMO the biggest issue with (a) is that developers will continue to use > `FileCheck` instead of `%FileCheck`. So IMO (a) should only be > implemented if simultaneously there is a change that makes just plain > `FileCheck` an error. I think that within a month this knowledge will be propagated...