search for: is_empti

Displaying 20 results from an estimated 57 matches for "is_empti".

Did you mean: is_empty
2006 Mar 07
6
Flickr - Tutorial
So I''ve pretty much followed the steps in the video tutorial on RoR.com for creating a small app, to search for photos on flickr.com - all is good, and works as intended to.. How would I go about adding validation, so if no tags are specified it will fail. I know I have to use validates_presence_of :tags - but not in the controller.. so I tried to generate a model called
2024 Jul 30
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
On Tue, 2024-07-30 at 02:21 +0200, Danilo Krummrich wrote: > Hi Timur, > > > This method has the advantage that it allows the buffers to be parsed > > even when the logging ELF file is not available to the user. However, > > it has the disadvantage the debubfs entries need to remain until the > > debubfs -> debugfs Ok > > driver is unloaded. > >
2007 Aug 02
7
has_many and class function
Hello, i have two models : class Container < ActiveRecord::Base has_many :bottles end class Bottle < ActiveRecord::Base belongs_to :container def self.find_all_from_container(container) container.bottles.find(:all) end end i was asking myself if there was a better way to write the function find_all_from_container : i can call it from an instance of Container but
2024 Jul 30
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
Hi Timur, On Mon, Jul 29, 2024 at 06:07:20PM -0500, Timur Tabi wrote: The patch looks great, just a few more nits below. > The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers > that have printf-like logs from GSP-RM and PMU encoded in them. > > LOGINIT, LOGINTR, and LOGRM are allocated by Nouveau and their DMA > addresses are passed to GSP-RM during
2024 Jul 29
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers that have printf-like logs from GSP-RM and PMU encoded in them. LOGINIT, LOGINTR, and LOGRM are allocated by Nouveau and their DMA addresses are passed to GSP-RM during initialization. The buffers are required for GSP-RM to initialize properly. LOGPMU is also allocated by Nouveau, but its contents are updated when Nouveau
2005 Jul 18
2
scriptaculous dragdrop.js empty list problem
Hi, I''ve just been having a look at the scriptaculous drag-n-drop library, which looks exceedingly good. I''m running across a show-stopper here, though - something that''s cropping up in both the online demos and my own test scripts. If I set up two lists so that I can drag items between them, then if either list becomes empty, I can''t drag elements back into
2024 Oct 30
1
[PATCH 2/2] [v9] drm/nouveau: expose GSP-RM logging buffers via debugfs
The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers that have printf-like logs from GSP-RM and PMU encoded in them. LOGINIT, LOGINTR, and LOGRM are allocated by Nouveau and their DMA addresses are passed to GSP-RM during initialization. The buffers are required for GSP-RM to initialize properly. LOGPMU is also allocated by Nouveau, but its contents are updated when Nouveau
2024 Aug 02
1
[PATCH 1/2] [v2] drm/nouveau: retain device pointer in nvkm_gsp_mem object
Store the struct device pointer used to allocate the DMA buffer in the nvkm_gsp_mem object. This allows nvkm_gsp_mem_dtor() to release the buffer without needing the nvkm_gsp. This is needed so that we can retain DMA buffers even after the nvkm_gsp object is deleted. Signed-off-by: Timur Tabi <ttabi at nvidia.com> --- Notes: v2: added get/put_device calls
2024 Jul 31
1
[PATCH 2/2] [v6] drm/nouveau: expose GSP-RM logging buffers via debugfs
On Tue, Jul 30, 2024 at 09:49:15PM +0000, Timur Tabi wrote: > > "Driver exit" is a bit of an undefined term, the closest thing is probably > > "driver detach" (from a device). In this case I think you actually mean > > "module > > exit" though. > > Yes, I use driver and module interchangeably, but I guess that's not > accurate.
2006 Mar 31
2
RE: drag and drop sorting with an empty lis
I ran into this issue too. My solution was to add an "onUpdate" function to the sortable that tests the container to see if it''s got any children or not: function is_empty(container) { if ($(container).hasChildNodes()) { Element.removeClassName($(container),''empty''); } else if (!$(container).hasChildNodes()) {
2014 Mar 21
2
[LLVMdev] [RFC] Add empty() method to iterator_range.
Hi Chandler, Agreed - ranges aren't containers, just views of sequences. Still, that's all many algorithms want, and it's just as valid to ask whether a sequence is empty as it is to ask that of a container. No contest on points 2 or 3, but I'm confused about point 4. When are ranges not pairs of iterators? I mean in a way that would clash with the proposal for empty() to be
2024 Jun 12
2
[PATCH 1/2] [v2] drm/nouveau: retain device pointer in nvkm_gsp_mem object
Store the struct device pointer used to allocate the DMA buffer in the nvkm_gsp_mem object. This allows nvkm_gsp_mem_dtor() to release the buffer without needing the nvkm_gsp. This is needed so that we can retain DMA buffers even after the nvkm_gsp object is deleted. Signed-off-by: Timur Tabi <ttabi at nvidia.com> --- v2: rebased to drm-misc-next
2014 Mar 19
5
[LLVMdev] [RFC] Add empty() method to iterator_range.
Hi all, As RFCs go this is short and sweet - I think it would be nice to add an empty method to iterator_range. Something like: bool empty() const { return begin() != end(); } My motivation is to make the 'if' test at the start of this common pattern tidier: if (!collection.empty()) // initialization... for (auto& c : collection) // do something for each c. which I think that
2010 Jul 09
8
DO NOT REPLY [Bug 7565] New: --check-point=<TIME> +options.c.patch +generator.c.patch
https://bugzilla.samba.org/show_bug.cgi?id=7565 Summary: --check-point=<TIME> +options.c.patch +generator.c.patch Product: rsync Version: 3.0.7 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned at samba.org
2015 May 24
2
[Mesa-dev] [PATCH 07/11] glsl: Add arb_cull_distance support
On Sun, 2015-05-24 at 19:58 +0200, Tobias Klausmann wrote: > Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> > --- > src/glsl/ast_to_hir.cpp | 14 +++++ > src/glsl/builtin_variables.cpp | 13 +++- > src/glsl/glcpp/glcpp-parse.y | 3 + > src/glsl/glsl_parser_extras.cpp | 1 + > src/glsl/glsl_parser_extras.h
2024 Jul 29
2
[PATCH 1/2] [v2] drm/nouveau: retain device pointer in nvkm_gsp_mem object
Store the struct device pointer used to allocate the DMA buffer in the nvkm_gsp_mem object. This allows nvkm_gsp_mem_dtor() to release the buffer without needing the nvkm_gsp. This is needed so that we can retain DMA buffers even after the nvkm_gsp object is deleted. Signed-off-by: Timur Tabi <ttabi at nvidia.com> v2: added get/put_device calls ---
2024 Sep 10
1
[PATCH 1/2] [v2] drm/nouveau: retain device pointer in nvkm_gsp_mem object
Store the struct device pointer used to allocate the DMA buffer in the nvkm_gsp_mem object. This allows nvkm_gsp_mem_dtor() to release the buffer without needing the nvkm_gsp. This is needed so that we can retain DMA buffers even after the nvkm_gsp object is deleted. Signed-off-by: Timur Tabi <ttabi at nvidia.com> --- .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 1 +
2024 Oct 03
1
[PATCH 2/2] [v8] drm/nouveau: expose GSP-RM logging buffers via debugfs
On Tue, Sep 10, 2024 at 04:56:16PM -0500, Timur Tabi wrote: > The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers > that have printf-like logs from GSP-RM and PMU encoded in them. > > LOGINIT, LOGINTR, and LOGRM are allocated by Nouveau and their DMA > addresses are passed to GSP-RM during initialization. The buffers are > required for GSP-RM to initialize
2006 Dec 01
0
[766] trunk/wxruby2: Added item_data aliases for client_data functions, update doc & tests;
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head><meta http-equiv="content-type" content="text/html; charset=utf-8" /><style type="text/css"><!-- #msg dl { border: 1px #006 solid; background: #369; padding:
2018 Sep 11
1
[PATCH] daemon: consider /etc/mdadm/mdadm.conf while inspecting mountpoints.
From: Nikolay Ivanets <stenavin@gmail.com> Inspection code checks /etc/mdadm.conf to map MD device paths listed in mdadm.conf to MD device paths in the guestfs appliance. However on some operating systems (e.g. Ubuntu) mdadm.conf has alternative location: /etc/mdadm/mdadm.conf. This patch consider an alternative location of mdadm.conf as well. --- daemon/inspect_fs_unix_fstab.ml | 13