Displaying 10 results from an estimated 10 matches for "prexisting".
Did you mean:
preexisting
2006 Mar 16
6
removing ROWS with missing values
I am trying to find out if R can recognize specific criteria for removing
rows (i.e. a prexisting function)
I have a matrix myMatrix that is 12000 by 20
I would like to remove rows from myMatrix that have:
-999 across all columns
-999 across all columns but one
-999 across all columns but two
-999 across all columns but three
-999 across all columns but four
-999 across all columns but five...
2006 Sep 22
3
Error with :create => true and existing index
I implemented a "reindex" command which simply creates an IndexWriter
with :create => true for a prexisting index.
The "reindexing" seems to start out ok, with several thousand docs
added, then Ferret throws an exception:
IO Error occured: couldn''t rename file "index\_0.tmp" to "index\_0.cfs":
<File exists>
I guess that _0.cfs is held open by an IndexReade...
2006 Jul 19
4
Ferret Indexing
Does ferret only index, when you create, or udpate a record?
Is there a way to make it index prexisting records?
Thanks.
--
Posted via http://www.ruby-forum.com/.
2015 Jun 19
2
[LLVMdev] Attribute to mark that function only access memory through it's arguments
...ttributes.
>
>
> What does it mean? Can it only touch memory that is directly referred
> to by an argument? Or if that argument points to another pointer, can
> we follow it?
I just want to point out that the notion Igor is introducing as an
attribute is not a new one. It's a prexisting notion which is already
implemented within LLVM today; it's simply been restricted to
intrinsics. Here's the definition from Intrinsics.td:
// IntrReadWriteArgMem - This intrinsic reads and writes only from
memory that
// one of its arguments points to, but may access an unspecified
am...
2015 Jun 18
3
[LLVMdev] Attribute to mark that function only access memory through it's arguments
Hi,
Currently in AliasAnalysis we can model ModRef behaviour for functions which
only access memory through their pointer arguments. However we can't
express this propery as a function attribute.
For example, for intrinsics we can specify ReadWriteArgMem or ReadArgMem
attributes in tablegen definitions. But due to the lack of the related function
attributes on the llvm ir level, this
2012 Apr 03
3
[PATCH] xl: Don't require a config file for cpupools
Since the key information can be fairly simply put on the command-line,
there''s no need to require an actual config file.
Also improve the help to cross-reference the xlcpupool.cfg manpage.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
diff -r 30cc13e25e01 -r 0fb728d56bae docs/man/xl.pod.1
--- a/docs/man/xl.pod.1 Tue Apr 03 19:02:19 2012 +0100
+++ b/docs/man/xl.pod.1
2006 Jun 24
5
Rake vs Ruby for running tests (error discrepency)
I''m having (to me) a strange problem with errors when running my tests
with rake as opposed to using ruby. If I do rake test:units I get this
error for several tests, but not all:
13) Error:
test_player_has_game_statistics_for_season(PlayerSeasonTest):
ActiveRecord::StatementInvalid: Mysql::Error: Duplicate entry ''22'' for
key 1: INSERT INTO positions (`name`, `id`,
2019 Nov 07
0
[PATCH v2 02/15] mm/mmu_notifier: add an interval tree notifier
...mn's, as shown later when you say the need to an entirely new ops struct, and
> data struct too.
>
> Therefore, you need a separate events enum as well. This is important. MMN's
> won't be issuing MMN_NOTIFY_RELEASE events, nor will MNR's be issuing the first
> four prexisting MMU_NOTIFY_* items. So it would be a design mistake to glom them
> together, unless you ultimately decided to merge these MMN and MNR objects (which
> I don't really see any intention of, and that's fine).
>
> So this should read:
>
> enum mmu_range_notifier_event {
>...
2019 Nov 07
5
[PATCH v2 02/15] mm/mmu_notifier: add an interval tree notifier
...rtainly not the same
as mmn's, as shown later when you say the need to an entirely new ops struct, and
data struct too.
Therefore, you need a separate events enum as well. This is important. MMN's
won't be issuing MMN_NOTIFY_RELEASE events, nor will MNR's be issuing the first
four prexisting MMU_NOTIFY_* items. So it would be a design mistake to glom them
together, unless you ultimately decided to merge these MMN and MNR objects (which
I don't really see any intention of, and that's fine).
So this should read:
enum mmu_range_notifier_event {
MMU_NOTIFY_RELEASE,
};
...assumi...
2019 Oct 28
32
[PATCH v2 00/15] Consolidate the mmu notifier interval_tree and locking
From: Jason Gunthorpe <jgg at mellanox.com>
8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
they only use invalidate_range_start/end and immediately check the
invalidating range against some driver data structure to tell if the
driver is interested. Half of them use an interval_tree, the others