search for: maxoffset

...similar data matrix: data = double(0.54878431372549,0.468,0.553411764705882,0.663529411764706, 0.440156862745098,0.330313725490196,0.473843137254902,0.690980392156863, 0.483333333333333,0.344862745098039,0.458156862745098,0.647843137254902) ImageWidth = size(data,2); dim(A)[2] # i.e. number of col MaxOffset = 99; # defined variable, =2R ImageWidthToProcess = ImageWidth-MaxOffset; # =2R defined variable for Offset = 1:MaxOffset ; loop to calculate the autocorrelation. basicly, they do cor2, which I think is Spearman correlation, between every column and store it in the vector position??? OffsetPlaq...

...tly correspond to their actual stack locations. In X86FrameLowering's emitCalleeSavedFrameMoves, when emitting DWARF information, this discrepancy gets fixed up by subtracting the offset reported by MFI->getObjectOffset from the minimum offset for any CSR (this is done by the "Offset = MaxOffset - Offset + saveAreaOffset;" line). Is there a reason why llvm doesn't keep around the offsets in the right order from very beginning, by pushing the CSRs in increasing order of FrameIdxs? [1]: in fact, the way X86FrameLowering's spillCalleeSavedRegisters and PEI's calculateCallee...

...locations. In X86FrameLowering's >> emitCalleeSavedFrameMoves, when emitting DWARF information, this >> discrepancy gets fixed up by subtracting the offset reported by >> MFI->getObjectOffset from the minimum offset for any CSR (this is done >> by the "Offset = MaxOffset - Offset + saveAreaOffset;" line). Is >> there a reason why llvm doesn't keep around the offsets in the right >> order from very beginning, by pushing the CSRs in increasing order of >> FrameIdxs? > > Now, that you mention it, I remember being down to the same rabb...

...} + +/* + * Based on fs/ext2/ext2.c + * find a dir entry, return it if found, or return NULL. + */ +static const struct ufs_dir_entry * +ufs_find_entry(struct fs_info *fs, struct inode *inode, const char *dname) +{ + const struct ufs_dir_entry *dir; + const char *data; + int32_t i, offset, maxoffset; + block_t index = 0; + + ufs_debug("ufs_find_entry: dname: %s ", dname); + for (i = 0; i < inode->size; i += fs->block_size) { + data = ufs_get_cache(inode, index++); + offset = 0; + maxoffset = min(inode->size-i, fs->block_size); + + /* The smallest possible size...

...} + +/* + * Based on fs/ext2/ext2.c + * find a dir entry, return it if found, or return NULL. + */ +static const struct ufs_dir_entry * +ufs_find_entry(struct fs_info *fs, struct inode *inode, const char *dname) +{ + const struct ufs_dir_entry *dir; + const char *data; + int32_t i, offset, maxoffset; + block_t index = 0; + + ufs_debug("ufs_find_entry: dname: %s ", dname); + for (i = 0; i < inode->size; i += fs->block_size) { + data = ufs_get_cache(inode, index++); + offset = 0; + maxoffset = min(inode->size-i, fs->block_size); + + /* The smallest possible size...

On Wed, 4 Nov 2009 17:42:26 +0000 Jakob Bornecrantz <jakob at vmware.com> wrote: > Hi Jerome > > On 4 nov 2009, at 15.58, Jerome Glisse wrote: > > > > Note: For reference my issue is with cursor on old radeon hw, > > cursor must be in the next 128M from the crtc scanout buffer. We > > got issue when someone start to resize their screen at which > >

From: Raphael S. Carvalho <raphael.scarv at gmail.com> Wrote the documentation below. I think it would be good to push the doc to the wiki as soon as the UFS support gets merged. Unix Fast File System (UFS/FFS) 1/2 on Syslinux - (usage/install) ----- There is a confusion about the name of this file system, then I decided to contact the author who replied: "The name has always been

From: Raphael S. Carvalho <raphael.scarv at gmail.com> Change since v1: * Fix bug on dentry structure (thank you specification; btw, sarcasm), and consequently a bug on ufs_readdir. * Add readlink support (applied tests for symlinks whose destionation path were stored in blk pointers and the file itself). * Several improvements. Wrote the documentation below. I think it would be good to