similar to: [BTS] Dr Nic''s Magic Models - Class creation

Welcome! Welcome! Welcome! Ladies and Gentlemen, soon you shall be thrilled and dazzled by wonders of magical mystery. Soon, very soon, Dr Nic''s Magic Models will be unveiled to all. Children will giggle; Rubists will nod acknowledgingly; Railers will applaud loudly. No entry fee. 2 drink minimum. Watch out for the Invisible Model Classes. Got a legacy database of 50 tables? You

Welcome! Welcome! Welcome! Ladies and Gentlemen, today you shall be thrilled and dazzled by wonders of magical mystery. Dr Nic?s Magic Models will now be unveiled to all. Mystery and magic that you will be able to perform at home. Within your ActiveRecord models, never again will you need to write: * validates_presence_of validations * has_many and belongs_to statements * has_many

Announcement Release 0.7.1 provides support for the new rails 1.1.5/6 releases that included an updated activerecord-1.14.4 version. It will now also support all future version (as it should have in the first place) More information on release: http://drnicwilliams.com/2006/08/12/magic-models-and-activerecords-1144/ Description of Dr Nic''s Magic Models Dr Nic''s Magic Models

I side with David when it comes to databases. They suck! Just my own opinion. So what about the people who don''t want to define validations and stuff in the database, but still want to be DRY. I really hate how the schema is separate from my models. I kind of like how Django defines the table attributes in the model. I was think about trying something like that in Rails. You could

Jim Grosbach wrote: > That does raise a clarifying question here. Is the code you’re interested in > using Intel or AT&T syntax? > > Also note that the question isn’t whether we should support the btr/bts > instructions. We absolutely must (and do). The question is whether we are > properly handling the un-suffixed mnemonic form of the assembly syntax. > > Perhaps you

Also, please elaborate on why this is a good change. Because gas accepts it isn’t sufficient reason in and of itself. -Jim On Jul 10, 2013, at 1:18 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra > <artagnon at gmail.com> wrote: >> The instructions btr and bts are perfectly valid, and have existed since

Eli Friedman wrote: > The reason it's the right thing to do is that the mem/imm forms of > btsw and btsl have exactly the same semantics. The Intel documentation implies that this is the case: > If the bit base operand specifies a memory location, it represents the address of the byte in memory that contains the bit base (bit 0 of the specified byte) of the bit string (see Figure

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/asm/bitops.h#L68 Here is one example that I found. Are the inline assembly arguments ambiguous in size? -Jevin Sent from my mobile device. Typos are par for the course. On Jul 10, 2013, at 5:47 PM, Jim Grosbach <grosbach at apple.com> wrote: On Jul 10, 2013, at 2:30 PM, Eric Christopher <echristo at

On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386. GNU as supports them fine. Unfortunately, LLVM does not > support them, and barfs with: > > error: ambiguous instructions require an explicit suffix > > Fix this problem by disambiguating it

Hi, this patch passes the orginal cpuid bits for X86_FEATURE_DTES64 (64-bit DS Area) and X86_FEATURE_DSCPL (CPL Qualified Debug Store) to the guest when the BTS feature is switched on. I forgot this when I did this BTS emulation. Thanks. Dietmar. Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> diff -r a6b81234b189 xen/arch/x86/hvm/vmx/vpmu_core2.c ---

Anyone on this list have extensive experience with BTS? http://deancollinsblog.blogspot.com/2009/03/open-bts.html Please email me, particularly if you have experience in deploying over multiple cells covering large geographical areas (200k's sq). Regards, Dean Collins Cognation Inc dean at cognation.net <mailto:dean at cognation.net> +1-212-203-4357 New York

On Wed, Jul 10, 2013 at 2:08 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Jim Grosbach wrote: >> To say that another way, is the assembler correctly diagnosing a previously >> unnoticed problem in the project source code, or is the assembler not >> behaving correctly according the the documented Intel assembly mnemonics? > > Where are the authoritative

Jim Grosbach wrote: > To say that another way, is the assembler correctly diagnosing a previously > unnoticed problem in the project source code, or is the assembler not > behaving correctly according the the documented Intel assembly mnemonics? Where are the authoritative instruction set pages? If such a thing were readily available, why are there gaps in the current implementation? A

Hi. After upgrading my Debian (installed a brand new Wheezy 64bits a few months ago), I decided to reinstall Civ4, and its amazing sequel BTS. Both applications finally installed (I had a problem with .net...), but now something is teribly wrong : Civ4 starts and plays just fine, but BTS, after starting, crashes when I clic "Play". The error message is the following : Unhandled

Jim Grosbach wrote: > Also, please elaborate on why this is a good change. Because gas accepts it > isn’t sufficient reason in and of itself. That they're valid instructions isn't sufficient reason? Should I additionally say that linux.git uses them? I wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386.

Hi, I happened to notice that linux.git uses plenty of btr and bts instructions (not btrl, btrw, btsl, btsw). For examples, see arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, while GNU as is fine with them. Surely, there must be architectures where the w/l variant is unavailable? LLVM must support those architectures, no? Thanks.

On Jul 10, 2013, at 1:44 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Jim Grosbach wrote: >> Also, please elaborate on why this is a good change. Because gas accepts it >> isn’t sufficient reason in and of itself. > > That they're valid instructions isn't sufficient reason? Should I > additionally say that linux.git uses them? > Is the

On Wed, Jul 10, 2013 at 11:12 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Hi, > > I happened to notice that linux.git uses plenty of btr and bts > instructions (not btrl, btrw, btsl, btsw). For examples, see > arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, > while GNU as is fine with them. Surely, there must be architectures > where

On Jul 17, 2013 7:41 AM, "Joerg Sonnenberger" <joerg at britannica.bec.de> wrote: > > On Wed, Jul 17, 2013 at 11:54:21AM +0530, Ramkumar Ramachandra wrote: > > Jim Grosbach wrote: > > > No. The above rule is absolutely the wrong thing to do, as has been > > > previously noted. > > > > I don't give a shit about whether you think it is

On Jul 10, 2013, at 2:30 PM, Eric Christopher <echristo at gmail.com> wrote: > On Wed, Jul 10, 2013 at 2:08 PM, Ramkumar Ramachandra > <artagnon at gmail.com> wrote: >> Jim Grosbach wrote: >>> To say that another way, is the assembler correctly diagnosing a previously >>> unnoticed problem in the project source code, or is the assembler not >>>