search for: stark

Hi, Given i have this share : [j.snow] Path = /home/j.snow Share and ntfs permission : j.snow user Now I add another folder share inside the first one : [a.stark] Path = /home/j.snow/a.stark Share and ntfs permission : a.stark user /home/j.snow/a.stark has now parent inherit permission (j.snow) AND a.stark user a.stark can't access to her share ! if I add a.stark NTFS access to [j.snow] share, she can.... Strange behavior. Bug or samba limitation ? I&...

...eting Mips -- Targeting MSP430 -- Targeting NVPTX -- Targeting PowerPC -- Targeting Sparc -- Targeting SystemZ -- Targeting X86 -- Targeting XCore -- Compiler-RT supported architectures: x86_64 -- Clang version: 3.8.0 -- Configuring done -- Generating done -- Build files have been written to: /home/stark/src/llvm-build $ make CC=/usr/local/bin/clang CXX=/usr/local/bin/clang++ [ 0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.o [ 0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/APInt.cpp.o [ 0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/AP...

...: S?bastien Le Ray [mailto:sebastien-samba at orniz.org] >Envoy??: vendredi 5 juin 2015 15:11 >??: MORILLO Jordi; samba at lists.samba.org >Objet?: Re: [Samba] [Bug or Limitation] Folder sharing inside >another share > >Hi, > >I guess it is ? by design ?. smb process for a.stark gets >a.stark UID and is thus subject to standard unix permissions >checks. If it cannot "execute" parent dirs, access will fail. > >Regards, > >Le 05/06/2015 14:53, MORILLO Jordi a ?crit : >> Hi, >> >> Given i have this share : >> >> [j.s...

clang revision is good, but the kernel is probably too new. Evgenii can comment on that. On Sat, Sep 12, 2015 at 3:23 PM, Greg Stark <stark at mit.edu> wrote: > On Sat, Sep 12, 2015 at 11:22 PM, Greg Stark <stark at mit.edu> wrote: > > Checked out a few days ago. It looks like r246697. I suppose I could > > try updating and rebuilding. > > Sorry, svn log in the tools/clang directory shows r24670...

...c $ ./a.out VARSIZE 6 ================================================================= ==19982==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eff4 at pc 0x0000004d4986 bp 0x7ffe14e2cb90 sp 0x7ffe14e2cb88 READ of size 4 at 0x60200000eff4 thread T0 #0 0x4d4985 in main (/home/stark/src/a.out+0x4d4985) #1 0x7f6360f40b44 in __libc_start_main /tmp/buildd/glibc-2.19/csu/libc-start.c:287 #2 0x41a935 in _start (/home/stark/src/a.out+0x41a935) 0x60200000eff6 is located 0 bytes to the right of 6-byte region [0x60200000eff0,0x60200000eff6) allocated by thread T0 here: #0...

...default sample() do the best possible thing, and take an extra step to use something like sample(..., legacy=TRUE) if I want to reproduce old results. Regards, Philip On Wed, Sep 19, 2018 at 9:50 AM Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 19/09/2018 12:23 PM, Philip B. Stark wrote: > > No, the 2nd call only happens when m > 2**31. Here's the code: > > Yes, you're right. Sorry! > > So the ratio really does come close to 2. However, the difference in > probabilities between outcomes is still at most 2^-32 when m is less > than that cut...

...itizer can not mmap the shadow memory. FATAL: Make sure to compile with -fPIE and to link with -pie. FATAL: Disabling ASLR is known to cause this error. FATAL: If running under GDB, try 'set disable-randomization off'. ==14645==Process memory map follows: 0x5615fae87000-0x5615faf26000 /home/stark/src/pg/postgresql-master/conftest 0x5615fb126000-0x5615fb12a000 /home/stark/src/pg/postgresql-master/conftest 0x5615fb12a000-0x5615fd59d000 0x7f86a64a3000-0x7f86a67f5000 0x7f86a67f5000-0x7f86a6994000 /lib/x86_64-linux-gnu/libc-2.19.so 0x7f86a6994000-0x7f86a6b94000 /lib/x86_64-linux-gnu/libc-2.19.so...

...case KNUTH_TAOCP2: cut = 33554431.0; /* 2^25 - 1 */ break; default: break; } double u = dn > cut ? ru() : unif_rand(); return floor(dn * u); } On Wed, Sep 19, 2018 at 9:20 AM Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 19/09/2018 12:09 PM, Philip B. Stark wrote: > > The 53 bits only encode at most 2^{32} possible values, because the > > source of the float is the output of a 32-bit PRNG (the obsolete version > > of MT). 53 bits isn't the relevant number here. > > No, two calls to unif_rand() are used. There are two 32 bi...

...ng. Suppose the rows are non-randomly ordered, e.g. odd rows are males, even rows are females. Oops! Very non-representative sample, bootstrap p values are garbage. David On Wed, 19 Sep 2018 at 21:20, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 19/09/2018 3:52 PM, Philip B. Stark wrote: > > Hi Duncan-- > > > > > > That is a mathematically true statement, but I suspect it is not very > relevant. Pseudo-random number generators always have test functions > whose sample averages are quite different from the expectation under the > true distrib...

...00 00 00 80 80 ================================================================= ==28714==ERROR: AddressSanitizer: unknown-crash on address 0x62900003d7ac at pc 0x00000144a6d6 bp 0x7ffed6680db0 sp 0x7ffed6680da8 READ of size 4 at 0x62900003d7ac thread T0 #0 0x144a6d5 in init_var_from_num /home/stark/src/pg/postgresql-master/src/backend/utils/adt/numeric.c:4764:17 ... SUMMARY: AddressSanitizer: unknown-crash /home/stark/src/pg/postgresql-master/src/backend/utils/adt/numeric.c:4764:17 in init_var_from_num Shadow bytes around the buggy address: ... =>0x0c527ffffaf0: f7 f7 00 00 f7[06]00 00 f7...

...; >>> be addressed first? > >>> > >>> I believe this issue was also raised by Killie & Philip in > >>> http://r.789695.n4.nabble.com/Bug-in-sample-td4729483.html, and more > >>> recently in > >>> https://www.stat.berkeley.edu/~stark/Preprints/r-random-issues.pdf, > >>> pointing to the python implementation for comparison: > >>> > https://github.com/statlab/cryptorandom/blob/master/cryptorandom/cryptorandom.py#L265 > >> > >> I think the analyses are correct, but I doubt if a change t...

On Sat, Sep 12, 2015 at 10:46 PM, Kostya Serebryany <kcc at google.com> wrote: > What's the version of Linux and Clang? Checked out a few days ago. It looks like r246697. I suppose I could try updating and rebuilding. $ uname -a Linux pixel 4.2.0-trunk-amd64 #1 SMP Debian 4.2-1~exp1 (2015-08-31) x86_64 GNU/Linux -- greg

Please note clarifications in <<>> below. My apologies for any confusion. Thanks again, Scott ---------- Forwarded message ---------- From: Scott Stark <stark.sc@gmail.com> Date: Aug 23, 2007 1:03 PM Subject: Expedite scalar f(x) evaluation over vectors To: r-help@lists.r-project.org Dear R community, I am trying to code a fairly complex equation for optim(). My current approach is too slow for optim(). I have a function that takes a dou...

...convince an R-core member to pursue this fix. In the meantime, a good, well-tested implementation in a user-contributed package (presumably written in C for speed) would be enormously useful. Volunteers ... ? On 2018-09-19 04:19 PM, Duncan Murdoch wrote: > On 19/09/2018 3:52 PM, Philip B. Stark wrote: >> Hi Duncan-- >> >> Nice simulation! >> >> The absolute difference in probabilities is small, but the maximum >> relative difference grows from something negligible to almost 2 as m >> approaches 2**31. >> >> Because the L_1 distance bet...

On 19/09/2018 3:52 PM, Philip B. Stark wrote: > Hi Duncan-- > > Nice simulation! > > The absolute difference in probabilities is small, but the maximum > relative difference grows from something negligible to almost 2 as m > approaches 2**31. > > Because the L_1 distance between the uniform distribution o...

...fix. > > In the meantime, a good, well-tested implementation in a > user-contributed package (presumably written in C for speed) would be > enormously useful. Volunteers ... ? > > > > On 2018-09-19 04:19 PM, Duncan Murdoch wrote: > > On 19/09/2018 3:52 PM, Philip B. Stark wrote: > >> Hi Duncan-- > >> > >> Nice simulation! > >> > >> The absolute difference in probabilities is small, but the maximum > >> relative difference grows from something negligible to almost 2 as m > >> approaches 2**31. > >&g...

...bug. Don't use sample(). Use the algorithm that Carl described. Duncan Murdoch > > David > > On Wed, 19 Sep 2018 at 21:20, Duncan Murdoch <murdoch.duncan at gmail.com > <mailto:murdoch.duncan at gmail.com>> wrote: > > On 19/09/2018 3:52 PM, Philip B. Stark wrote: > > Hi Duncan-- > > > > > > That is a mathematically true statement, but I suspect it is not very > relevant.? Pseudo-random number generators always have test functions > whose sample averages are quite different from the expectation...

On 19/09/2018 12:23 PM, Philip B. Stark wrote: > No, the 2nd call only happens when m > 2**31. Here's the code: Yes, you're right. Sorry! So the ratio really does come close to 2. However, the difference in probabilities between outcomes is still at most 2^-32 when m is less than that cutoff. That's not feasible t...

On Sat, Sep 12, 2015 at 7:48 PM, Greg Stark <stark at mit.edu> wrote: > I get that even if I put -fPIE in CFLAGS. Er, yeah. Even a trivial test case doesn't work: $ cat foo.c int main(int argc, char *argv[], char *envp[]) { return 1; } $ clang -o foo -fsanitize=memory -fPIE -pie foo.c $ sysctl kernel.randomize_va_space ker...

On Mon, Nov 9, 2015 at 7:20 PM, Kostya Serebryany <kcc at google.com> wrote: > Most likely, you need > https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer Thanks! > I don't think lsan supports this mode directly, > but why do you think that the init-time allocations are going to be > "leaked"? > If there is some object still pointing to