search for: 96x96

...e a negative control sample by not including it in any genotype cluster. I'm looking at both nuclear and mitochondrial DNA so hopefully it can be sophisticated enough to set the number of cluster between two or three within the array. These genotyping arrays are either 48 samples x 48 assays, 96x96, or 192x24 and it would be nice if it could accommodate any range of samples and assays. the data headings from the csv are: ID,Assay,Allele Y,Allele X,Name,Type,Auto,Confidence,Final,Converted,Allele Y,Allele X where Allele Y and Allele X are the plotted values and the vectors within the data.f...

...-321,7 +321,7 @@ icon_rhel (guestfs_h *g, int major, size_t *size_r) if (major < 7) shadowman = "/usr/share/pixmaps/redhat/shadowman-transparent.png"; else - shadowman = "/usr/share/pixmaps/fedora-logo-sprite.png"; + shadowman = "/usr/share/icons/hicolor/96x96/apps/system-logo-icon.png"; return get_png (g, shadowman, size_r, 102400); } -- 2.20.1

...ss users can trivially do this by assigning either categories or tags to their posts, which the provide dedicated RSS feeds; other blog software hopefully has similar capabilities. To be included on the planet, send (off-list) your RSS feed URL and a Hackergotchi face icon (upto an absolute max of 96x96 pixels in size). Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.or...

I see that the SVN version of the excellent file_column plug-in can create thumbnails using the url_for_image_column helper. This uses Rmagick to create the thumbnail... Quick question... Let''s say the file is a TIFF image - can the helper create a JPG version of the thumbnail for display in the browser? Curious if the plug-in can handle that transform with some creative use of the

...less, I'm not insisting it be exact, but at least not 1mm or 5mm high. In the (glorious) past I was able to look at xdpyinfo |egrep 'dimension| resolution' and check that Xorg was giving something reasonable.. eg dimensions: 1600x1200 pixels (423x317 millimeters) resolution: 96x96 dots per inch So far so good. With this new fangled gnome and fontconfig stuff, you also need to set up some X-resources with: xrdb -query |grep Xft Xft.antialias: 1 Xft.dpi: 96 Xft.hinting: 1 Xft.hintstyle: hintfull Xft.rgba: none ... and to inform gnome-settings-daemon with...

...to 640x480 the image loses its original ratio. has_attachment :content_type => :image, :storage => :file_system, :max_size => 4096.kilobytes, :resize_to => ''640x480'', :thumbnails => { :thumb => ''32x32'', :medium => ''96x96'', :large => ''320x240''}, :processor => :ImageScience . Thanks, Elías --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group...

...AU(0): Display dimensions: (290, 180) mm (**) NOUVEAU(0): DPI set to (112, 112) 290mm x 180mm and 112x112 DPI are indeed correct (1280x800, 13.3" widescreen), however: $ xdpyinfo | grep -E 'dimensions|resolution' dimensions: 1280x800 pixels (338x211 millimeters) resolution: 96x96 dots per inch X appears to be getting bogus data, which screws up font sizing. I'm on a MacBook Pro 13" with GeForce 9400M (NVac). Using nouveau-drm from the kernel tree with git rev eeec3a1ecd703d3a32fe223274d2a77686030d78 (built out of tree for kernel 2.6.32-gentoo-r2), and xf86-video...

http://bugs.freedesktop.org/show_bug.cgi?id=16033 Summary: [Randr12] DPI calculation ludicrously incorrect Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

Hello, I'm having difficulties to make Asterisk (1.6.0.6) interoperate correctly with a CISCO mediaGW in order to send faxes to the PSTN using T.38. When Asterisk sends the initial INVITE containing the T.38 media offer in the SDP, the CISCO answers with a 488 Not Acceptable Media. Apparently, it looks like a configuration problem in the CISCO, but I have tested the CISCO with the Zoiper

I am running xen (2.6.16-xen3_86.1_rhel4.1) on top of a stock CentOS-4.4 installation. I have not added any additional virtual machines however. When trying to install (as root) acrobat reader 7 for Linux from the adobe rpm (AdobeReader_enu.i386 7.0.8-1) I get the following errors: error: %pre(AdobeReader_enu-7.0.8-1.i386) scriptlet failed, exit status 255 error: install: %pre scriptlet

...PE SYNC X-Resource XC-MISC XFIXES XFree86-DGA XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: dimensions: 1920x1080 pixels (508x285 millimeters) resolution: 96x96 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0x1c2 depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x40 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options:...

v9 was here: https://www.redhat.com/archives/libguestfs/2017-July/msg00139.html This depends on these three series (the first two being single minor patches): https://www.redhat.com/archives/libguestfs/2017-July/msg00207.html https://www.redhat.com/archives/libguestfs/2017-July/msg00209.html https://www.redhat.com/archives/libguestfs/2017-July/msg00215.html There is no substantive change. I

This depends on the patch series "[PATCH 00/27] Reimplement many daemon APIs in OCaml." (https://www.redhat.com/archives/libguestfs/2017-July/msg00098.html) v8 was posted here: https://www.redhat.com/archives/libguestfs/2017-June/msg00274.html v9: - I split up the mega-patch into a more reviewable series of smaller, incremental patches. There are some other changes vs v8, but

This fixes almost everything. Note that it adds an extra commit which fixes the whole utf8/iconv business. It's probably better to list what isn't fixed: (1) I didn't leave the osinfo code around because I'm still haven't looked too closely at virt-builder-repository. Can't we just fetch this code from the git history when we need it? (2) I didn't change the way

v10: https://www.redhat.com/archives/libguestfs/2017-July/msg00245.html No actual change here, but I rebased and retested. Also this series now does not depend on any other patch series since everything else needed is upstream. Rich.

v6 was posted here: https://www.redhat.com/archives/libguestfs/2017-June/msg00103.html and this requires the utilities refactoring posted here: https://www.redhat.com/archives/libguestfs/2017-June/msg00169.html Inspection is now complete[*], although not very well tested. I'm intending to compare the output of many guests using old & new virt-inspector to see if I can find any

v5: https://www.redhat.com/archives/libguestfs/2017-June/msg00065.html Since v5, this now implements inspection almost completely for Linux and Windows guests. Rich.

v7 was: https://www.redhat.com/archives/libguestfs/2017-June/msg00169.html https://www.redhat.com/archives/libguestfs/2017-June/msg00184.html I believe this addresses all comments received so far. Also it now passes a test where I compared about 100 disk images processed with old and new virt-inspector binaries. The output is identical in all cases except one which is caused by a bug in blkid