Displaying 7 results from an estimated 7 matches for "overgeneral".
2003 Jun 20
7
ok, so oplocks: good or bad?
I have been searching for info on this and haven't found an
authoritative answer. From what I have read, oplocks are good because
they increase connection speeds, but they are bad because they don't
really work, but they actually do work, but they only work in some
cases, etc etc.
so, here's my problem and my question together: I get tons of these
messages every day (over a thousand a
2008 Feb 07
2
a kinder view of Type III SS
...w = xw. Fundamentally everything is the same in terms
of the above tests. However, one must be careful to understand what the
coefficient and test for x|w,xw and w|x,xw mean. That is, x|w,xw tests the
relationship between x and y when and only when w = 0. A very, very common
mistake, due to an overgeneralization of traditional anova models, is to
refer to x|w,xw as the "main effect." In my list of ten statistical
commandments I include: "Thou shalt never utter the phrase main effect"
because it causes so much unnecessary confusion. In this case, x|w,xw is
the SIMPLE effect of...
2006 Apr 26
0
[LLVMdev] Re: Newbie questions
On Wed, 2006-04-26 at 16:32 -0500, Chris Lattner wrote:
> I still don't follow. Having annotations on the IR is *exactly*
> equivalant to having a map from IR objects to the things you want to
> annotate them with.
>
> Why isn't this just as acceptable (and problematic) as annotations?
Because LLVM doesn't store that map, someone else has to. Furthermore,
LLVM
2006 Apr 26
5
[LLVMdev] Re: Newbie questions
On Wed, 26 Apr 2006, Archie Cobbs wrote:
>>> With no annotation support, it doesn't seem like you can. This is
>>> the problem. I'm not saying annotations are good, just that they
>>> represent one (sub-optimal) solution to the problem. Without them,
>>> we have zero solutions to the problem.
>>
>> Why do you believe this?
>
> Sorry,
2006 Jan 17
0
asterisk.ctl limitations
...sockets */
#include <netinet/in.h> /* sockaddr_in, htons, in_addr */
#include <netinet/in_systm.h> /* misc crud that netinet/ip.h references */
#include <netinet/ip.h> /* IPOPT_LSRR, header stuff */
@@ -87,6 +88,7 @@
/* handy stuff: */
#define SA struct sockaddr /* socket overgeneralization braindeath */
+#define SAU struct sockaddr_un /* */
#define SAI struct sockaddr_in /* ... whoever came up with this model */
#define IA struct in_addr /* ... should be taken out and shot, */
/* ... not that TLI is any better. sigh.. */
@@ -149,12...
2016 Jan 07
3
lld: ELF/COFF main() interface
On Thu, Jan 7, 2016 at 7:18 AM Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> In the process of migrating from old lld ELF linker to new (previously
>> ELF2) I noticed the interface lost several important features (ordered by
>>
2009 Oct 14
14
spec-ing private methods?
On Wed, Oct 14, 2009 at 5:49 PM, Scott Taylor <scott at railsnewbie.com> wrote:
>
> On Oct 14, 2009, at 3:36 PM, Joaquin Rivera Padron wrote:
>
> hello there,
> how do you tipically spec private methods? The thing is ? have something
> like this:
>
> def some_method
> ?? complex_method + other_complex_methods
> end
>
> private
> def complex_method...