search for: hashes

Hello folks, TL;DR: This is my proposed hashing interface based on a proposed standard hashing interface. It also is implemented with a much faster and higher quality algorithm than the current one. This is an *early draft* of the code, looking for initial feedback. There has been recent interest in improving the quality and consistency of LLVM's approach to hashing. In particular, getting

Hi folks, here is a short RFC regarding hashing for the implementation of switch statements and my preliminary patch. I posted this patch on 2014-01-16 21:58 at llvm-commits at cs.uiuc.edu. You can find a copy e.g. on http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140113/201782.html. Best regards Jasper === Preliminary: Special identifiers n number of given switch labels

For learning purposes mainly I attempted to implement hashes/maps/dictionaries (Python lingua) as S4 classes, see the coding below. I came across some rough S4 edges, but in the end it worked (for one dictionary). When testing ones sees that the dictionaries D1 and D2 share their environments D1 at hash and D2 at hash, though I thought a new and empty envir...

Hello everyone: I am quit new to View test using rspec. I want to write spec for a partial, which is rendered by a controller. However, the controller does not pass data to the partial using instance variables, it uses symbol variable instead. I read the example of view spec provided in the website. But the example is using instance variable. So I am looking for a way of assigning my test data

I have a database of bookmarks and tags, and want to count the number of bookmarks each tag is assigned to, for example: user "tyler" has the tag "concerts" on 15 out of his 30 bookmarks. This code: hash = Hash.new("0"); @user.tags.each do |t| @user.bookmarks.each do |b| x = 0 if b.tags.include?(t) then hash[b.id] =+ 1 puts "hash is #{hash}

Hi ! During linking LLD and other linkers builds a static hash table for dynamic symbols, so that in runtime dynamic linker can use this table and find symbols faster. --hash-style=style linker option is used to select the hash type: "Set the type of linker's hash table(s). style can be either "sysv" for classic ELF ".hash" section, "gnu" for new style GNU

I'm working on a bug where LLVM takes over six minutes to compile a module. After some hand-editing, the module looks like this: class half { private: union uif { unsigned int i; float f; }; static const uif _toFloat[1 << 16]; }; const half::uif half::_toFloat[1 << 16] = { {0x00000000}, {0x33800000}, {0x34000000}, {0x34400000}, {0x34800000},

On 1/5/23 06:22, Rowland Penny via samba wrote: > > > On 05/01/2023 10:20, Zombie Ryushu via samba wrote: >> Does anyone know how to completely remove the Computer SID of a >> Demoted DC? As in, another DC has taken it's place, the system is >> down and offline, but if it rejoins, it will not get the SID entry it >> had before? >> > > >

Here's my latest version of Hashing.h, which I propose to add to llvm/ADT. Comments welcome and encouraged. On Thu, Feb 9, 2012 at 11:23 AM, Talin <viridia at gmail.com> wrote: > By the way, the reason I'm bringing this up is that a number of folks are > currently working on optimizing the use of hash tables within LLVM's code > base, and unless we can come up with a

...for the various uniquing maps which I'm attempting to optimize. Take for example the case of uniquing a constant array - the key consists of a type* pointer and an array of constant*. Those data fields are not stored contiguously in memory, so I need to hash them separately and then combine the hashes. Being able to hash the data fields in place (as opposed to copying them to a contiguous buffer) turns out to be a fairly significant win for the uniquing maps - otherwise you end up having to do a malloc just to look up a key, and that's going to be slower than any incremental hash algorithm....

Hi, I’ve been looking at Chandler Carruth talks about internal data structures for LLVM in order to implement my own library. That’s how I ended up looking at the internals of DenseMap and the default hash functions defined in DenseMapInfo. I have been very surprised by the hash function used for integers which is hash(k) = 37 * k. This kind of hashing function does not change the lowest bits of

LLVM currently has a bunch of different hashing algorithms scattered throughout the code base. There's also a number of places in the code where a FoldingSetNodeID is created for the purpose of calculating a hash, and then discarded. From an efficiency standpoint, this isn't all that bad unless the number of individual items being hashed > 32, at which point the SmallVector overflows

...nly evidence of any problem from the vampire command is the > events logged on the PDC, and the invalid passwords. I tried > deleting the trust account on the PDC and rejoining several times, > with Samba on, off, and nmbd on and off. The result is always the > same. The bad password hashes are always the same for each account. > If I change a password on the PDC then run vampire again, the NT > hash changes on the Samba box. It just seems like the NT hash is > somehow being scrambled, but in a consistent way. I believe I have found two bugs in the 3.2 code and one bug that...

...remote IMAP client. I've also tried using the -p flag and including the password in the command, and that doesn't do it either, though it oddly gives a different response than using the prompt. (What causes this? Newlines?) So... what am I missing? If the hash was salted, it would seem the hashes in the database would be longer than the ones generated at the command line, but that isn't the case. I'm out of ideas. Any guidance appreciated. -Dave

...am not sure if this is the right place to post, please redirect me if there is a mailinglist more specifically dealing with prototype.js. After playing around with the very inspiring prototype library I have found a rather annoying thing, that makes the usefulness of the Enumerable mixin for Hashes questionable, if I am not totally wrong (again :-). Here an example: var a = $H({a:1, b:2, c:1, d:3}); document.writeln(a.inspect().escapeHTML()); // yields: #<Hash:{''a'': 1, ''b'': 2, ''c'': 1, ''d'': 3}> var b = a.reject(...

Jeffrey and I are working on future standard library functionality for hashing user defined types: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3333.html I would much rather have an interface that is close to or mirrors this one. We already have some field experience with it, and using it in LLVM and Clang would provide more. Also, it would be possible to essentially share code

Use better functions to check for proper values instead of assert: - refute_nil for non-null functions - assert_equal for checking equality Also, make sure that the parameters for assert_equal are correct: expected value, then got value. --- ruby/tests/tc_120_rlenvalue.rb | 4 ++-- ruby/tests/tc_130_special.rb | 12 ++++++------ ruby/tests/tc_200_write.rb | 4 ++--

On Mon, Apr 06, 2015 at 10:55:44PM -0400, Waiman Long wrote: > +++ b/kernel/locking/qspinlock_paravirt.h > @@ -0,0 +1,321 @@ > +#ifndef _GEN_PV_LOCK_SLOWPATH > +#error "do not include this file" > +#endif > + > +/* > + * Implement paravirt qspinlocks; the general idea is to halt the vcpus instead > + * of spinning them. > + * > + * This relies on the

On Mon, Apr 06, 2015 at 10:55:44PM -0400, Waiman Long wrote: > +++ b/kernel/locking/qspinlock_paravirt.h > @@ -0,0 +1,321 @@ > +#ifndef _GEN_PV_LOCK_SLOWPATH > +#error "do not include this file" > +#endif > + > +/* > + * Implement paravirt qspinlocks; the general idea is to halt the vcpus instead > + * of spinning them. > + * > + * This relies on the

...uing > maps which I'm attempting to optimize. Take for example the case of > uniquing a constant array - the key consists of a type* pointer and an > array of constant*. Those data fields are not stored contiguously in > memory, so I need to hash them separately and then combine the hashes. > Being able to hash the data fields in place (as opposed to copying them to > a contiguous buffer) turns out to be a fairly significant win for the > uniquing maps - otherwise you end up having to do a malloc just to look up > a key, and that's going to be slower than any incremen...