|
Authored by: nsomos on Thursday, May 17 2012 @ 05:08 PM EDT |
Please post corrections here.
e.g. Misteak -> Mistake
[ Reply to This | # ]
|
|
Authored by: Anonymous on Thursday, May 17 2012 @ 05:10 PM EDT |
How does reading back testimony actually work?
I mean can Oracle just pick and choose what bit they want read back, or can
Google also choose rebuttal testimony to be read back? Or do they present
different options and the judge decides?[ Reply to This | # ]
|
|
Authored by: SilverWave on Thursday, May 17 2012 @ 05:15 PM EDT |
:-)
---
RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions
[ Reply to This | # ]
|
|
Authored by: SilverWave on Thursday, May 17 2012 @ 05:16 PM EDT |
:-D
---
RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions
[ Reply to This | # ]
|
|
Authored by: SilverWave on Thursday, May 17 2012 @ 05:18 PM EDT |
https://twitter.com/#!/tqft
9999/googlevoracle --- RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions
[ Reply to This | # ]
|
- Juror sick... - Authored by: Anonymous on Thursday, May 17 2012 @ 05:21 PM EDT
- Doesn't want to be discharged... - Authored by: Anonymous on Thursday, May 17 2012 @ 05:22 PM EDT
- Sick juror is actually a nurse... - Authored by: Anonymous on Thursday, May 17 2012 @ 05:24 PM EDT
- Alsup's plan... - Authored by: Anonymous on Thursday, May 17 2012 @ 05:25 PM EDT
- Waiting to hear result of plan... - Authored by: Anonymous on Thursday, May 17 2012 @ 05:27 PM EDT
- Jury heading home - no transcript reading... - Authored by: Anonymous on Thursday, May 17 2012 @ 05:28 PM EDT
- Alsup: "Wash your hands like crazy" - Authored by: Anonymous on Thursday, May 17 2012 @ 05:32 PM EDT
- If sick juror not well tomorrow and doesn't come in, she will be discharged... - Authored by: Anonymous on Thursday, May 17 2012 @ 05:32 PM EDT
- Tweets - Authored by: feldegast on Thursday, May 17 2012 @ 06:20 PM EDT
|
Authored by: SilverWave on Thursday, May 17 2012 @ 05:21 PM EDT |
o_0
---
RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions
[ Reply to This | # ]
|
|
Authored by: Chromatix on Thursday, May 17 2012 @ 05:35 PM EDT |
I might be getting a little optimistic here, but this is what the jury could
be
thinking at this point:
Firstly, they're confused. They got a lot of
conflicting testimony, of which (as
we know) much was *designed* to confuse
them, but at least they *know*
they're confused.
So now they're trying to
sort out the confusion by eliminating witnesses that
they can show are
untrustworthy. If, after eliminating those, most of the
evidence is consistent
and clear, they'll be in a much better position to make a
decision.
They've
selected Dr. Mitchell as potentially untrustworthy, and want to get the
readback as part of that evaluation. Don't ask me why they need a readback
for this - surely they have the transcripts in front of them? [ Reply to This | # ]
|
|
Authored by: bugstomper on Thursday, May 17 2012 @ 06:32 PM EDT |
Reading over the question and the answer I think that Judge Alsup did give them
something they can work with.
They asked if something is "permitted to be taken as evidence". He
answered, "I've previously told you what's evidence in this case, and
what's not, I'm not going to repeat that." That tells them to review their
instructions which will say that expert testimony is part of the evidence, and
it is up to them to weigh the credibility of the expert testimony as they weigh
all of the evidence and witness testimony.
He then says "your question is one that goes to the weight of the evidence
and how to evaluate it. That is for you to decide." Combined with the first
part it tells them that yes, it is part of the evidence, and like all the
evidence it is up to them to decide who and what to believe.
What they asked is if they could consider what Parr said about how he
demonstrated that the stack code was not run as evidence. They were told that
they could consider it and it is up to them to consider it and decide about it.
Now they are asking for Mitchell's testimony which disagrees with Parr. That
shows that they are considering the dueling expert testimony. That's what they
should be doing.
[ Reply to This | # ]
|
|
Authored by: bugstomper on Thursday, May 17 2012 @ 07:01 PM EDT |
PJ, I know that having a nym would not really identify the reporter, but can we
have one by which we can refer to her or him when expressing appreciation for
this truly amazing job of on the fly transcription? Is this person an off-duty
court reporter?
[ Reply to This | # ]
|
|
Authored by: BitOBear on Thursday, May 17 2012 @ 08:13 PM EDT |
Imagining the deliberations, I suspect that there is one guy on the jury who
just doesn't "get" his job.
The jury seems to be trying to find a verdicts that make -all- the testimony
true. This is a typical scenario where someone is trying to be an intellectual
peace maker.
If you have ever been in an argument with someone who doesn't understand that
all citations and recitations of alleged fact are not -equally- true, then you
know the exact experience I suspect is bogging down this jury.
If someone throws in a "bad fact" such completionists can deadlock
-themselves- let alone a quorum.
Think "twelve angry men", but more passive aggressive. /joke.[ Reply to This | # ]
|
|
Authored by: Ian Al on Friday, May 18 2012 @ 06:45 AM EDT |
I'm glad I reviewed Mr. Parr's testimony. It helped me spot this bit of nonsense
from Oracle.Now, the first point: the experiment that Dr. Parr did
went to proving that the stack was not used in Android. That is legally
irrelevant, as there's no requirement in the claims that the stack be used. In
other claims there is such a requirement, but not in the asserted
claims.
What Mr. Parr did was to explain how dex (I think that is
the pronunciation of dx) uses simulated execution, as described extensively in
its comments. Whenever dx does simulated execution it makes extensive use of
stack manipulation. Whenever it stops using simulation, it stops manipulating
the stack. This is nothing to do with patent claims. It is to do with how dx
works.
You need to see quite a lot of Mr. Parr's testimony to answer
the juries question for yourself."We are attempting to determine the
scope of the meaning of the term 'simulating execution of the bytecodes' in
patent '520. Is the existence of an example of the Android code not functiong
(punting), when formatted in a normal simulated execution setting, permitted to
be taken as evidence that Android's array initialization diverges from the
patented array intiialization?"
Here is a lot of what Mr. Parr
said, including the reference to 'punt'.
Mr. Parr: I understand
"execution" to mean running live on the JVM. Simulating execution is in the
preloader -- it's like a dress rehearsal versus a live show. The goal is to
simulate these bytecodes to determine the static initialization of the
array.
Google: What's the core requirement for simulating execution on
a stack machine?
Mr. Parr: Well, you need to manipulate the stack --
pushing, popping, etc.
Google: Is this described in the
patent?
Mr. Parr: It does not say stack manipulation.
[Shows
how the example code in the patent is operating on a stack]
"Object
stack[] = new Object[stackSize]; // create stack for play execution"
etc...
Google: Were you in court for Dr. Mitchell's testimony on
infringement?
Mr. Parr: Yes.
Google: Do you agree with his
testimony?
Mr. Parr: No.
Google: Why not?
Mr.
Parr: Because dexopt doesn't use simulated execution for the purpose of
determining static initialization of the array.
Google: How did you
determine that?
Mr. Parr: Spent a long time looking at the dex source,
running tests, etc.
Google: What's the purpose of the Android dex
tool?
Mr. Parr: It takes the .class files emitted by the Java
compiler, and translates them to .dex files.
The Java Virtual Machine
and the Dalvik VM have completely different instruction sets, so a translation
has to occur... That's what dex does. It translates Java bytecodes into Android
bytecodes, so Android can execute them.
[Discussion about how dex uses
simulated execution, as described extensively in its comments.]
Google: So you'd agree that the Simulator class does know how to simulate
bytecodes?
Mr. Parr: Yes.
Google: So why doesn't it infringe
the '520 patent?
Mr. Parr: That's because for the very specific
purpose of identifying the static initialization of the array, it does something
different -- it uses pattern matching...
Mr. Parr: What I identified
was the specific part of the program, dex, that identified the static
initialization of the array. It's in parseNewarray... there's a comment: "Try to
match the array initialization idiom. For example, if the subsequent code is
initializing an int array, we are expecting the following pattern repeatedly" --
and then you see the pattern we saw earlier, for how to initialize an array. It
appeared to me to be a classic example of a pattern matcher.
Google:
How do you know?
Mr. Parr: Well, I've been building parsers for 30
years. See line 965, it defines a variable called "punt" -- it's looking for
something, if it doesn't find it, it fails. It's a classic example of pattern
recognition.
Google: Is it manipulating the stack at all
here?
Mr. Parr: No, I didn't see any stack manipulation.
Google: What experiments did you use to test your hypothesis that this was using
pattern matching?
Mr. Parr: Well, first I did a simple test to see
that there were no stack manipulations in the static array initialization. I put
print statements in the stack manipulation instructions (push, pop), like an
alarm, so they'd trigger if there was any stack manipulation. I didn't see
any.
[Demonstrative, titled "parseNewarray does not use the stack",
showing the output of running the program with his debug prints added]
During the normal operation of the simulated execution, we see stack
manipulation. But as we enter the parseNewarray method, what I observed is the
stack alarms went silent until the parseNewarray method had exited. But once we
returned from parseNewarray, we again got stack manipulations.
Since
there are no stack manipulations, it can't be using simulated execution to
identify these initialization.
Google: What was the second experiment
you performed?
Mr. Parr: Well, this one's a little trickier, but
useful. If it were using pattern matching, then if the pattern of
initializations were altered, the pattern would fail to match. But if it were
using simulated execution, then a minor change wouldn't affect it and it would
still work...
Mr. Parr: First, I ran dexopt on this sequence,
generated by the compiler. It does indeed create an instruction to initialize
this array, all in one go. So the default output of the compiler is recognized
by the dex tool as static initialization.
So, how can I change this
sequence of instructions without modifying the end result? Remember a new array
is already initialized to zero. I'm just going to add an extra instruction at
the beginning to set it to zero again. This is a tweak that doesn't affect the
code; if it executes, it wouldn't change the end array. However, if the dex tool
is a pattern matcher, it'll fail to recognize this pattern.
I ran the
dex tool on this modified bytecode stream, and the dex tool failed to generate
an instruction to initialize these elements in one go...
You can see
these extra instructions don't change anything, since that zero is already
there.
Here are the Dalvik bytecode instructions created by the dex
tool in response to the original bytecode sequence: it uses
fill-array-data.
But with the modified code, there's no
fill-array-data to initialize the array in one go. You see the normal conversion
of Java bytecodes to Dalvik instructions (new-array, aput, etc.).
Google: If the dex tool were in fact simulating the execution of the Java
bytecode, what would have resulted?
Mr. Parr: If it were simulating,
it wouldn't care about the extra instruction.
What he has done is
identified that arrays are statically initialised by dx using parseNewarray.
During its operation it does not manipulate the stack. His demonstration shows
that the stack is not manipulated during the execution of parseNewarray and that
this is shown by monitoring for the break in stack manipulation which is used by
dx for simulated execution.
His second experiment was to add an extra
single instruction at the beginning to set the array to zero. Running dx on the
modified code fails to generate an additional single instruction to initialise
the array. If simulation had been used, dx would have ignored the existence of
that first single step initialisation instruction, spotted the subsequent
instruction group initialising the array and generated an additional replacement
single instruction.
So, the answer to the jury question is 'yes' if
you believe that Mr. Parr has demonstrated that dx uses stack manipulation when
simulating execution.
--- Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid! [ Reply to This | # ]
|
|
|
|
|