![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Warp wrote:
> > SharkD <mik### [at] gmail com> wrote:
> >> On 10/25/2009 7:51 AM, Warp wrote:
> >>> Orchid XP v8<voi### [at] dev null> wrote:
> >>>> I've never seen TSQL, but if it's anything like SQL...
> >>> How about making some googling? TSQL is SQL + some extensions.
> >
> >> "Doing" not "making".
> >
> > You "make love", you don't "do love". ;)
> But if you make love to google, you're probably doing it wrong.
You don't make love to google. You make some googling.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Orchid XP v8 wrote:
> > Conversely, I'm told Perl's regex handling is supposed to be quite fast...
> I'd guess .NET is faster, if only because it compiles the regex into machine
> code, rather than interpret it.
I think that the concept of "interpreting" might be a bit blurred here.
I assume that perl constructs a state machine from the regexp and then does
the matching against it. How much that is "interpreting"... Hard to say.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>> Warp wrote:
>>> SharkD <mik### [at] gmail com> wrote:
>>>> On 10/25/2009 7:51 AM, Warp wrote:
>>>>> Orchid XP v8<voi### [at] dev null> wrote:
>>>>>> I've never seen TSQL, but if it's anything like SQL...
>>>>> How about making some googling? TSQL is SQL + some extensions.
>>>> "Doing" not "making".
>>> You "make love", you don't "do love". ;)
>
>> But if you make love to google, you're probably doing it wrong.
>
> You don't make love to google. You make some googling.
I think "googly eyes" is the term you're looking for.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>> Orchid XP v8 wrote:
>>> Conversely, I'm told Perl's regex handling is supposed to be quite fast...
>
>> I'd guess .NET is faster, if only because it compiles the regex into machine
>> code, rather than interpret it.
>
> I think that the concept of "interpreting" might be a bit blurred here.
> I assume that perl constructs a state machine from the regexp and then does
> the matching against it. How much that is "interpreting"... Hard to say.
Yeah. .NET does the same thing, then actually generates custom machine code
to run through the state machine. As in, if you compile enough different
regular expressions, you'll eventually run out of code space, because the
compiler can't GC machine code you've generated.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Darren New" <dne### [at] san rr com> wrote in message
news:4ae475ef$1@news.povray.org...
> clipka wrote:
>> The best you can do is include a runtime self-test routine in the code to
>> actively check whether compile-time endianness assumptions were right.
>
> At which point the best approach is probably just to pack and unpack the
> bits yourself. :-)
>
I remember having written a game on a portable Unix machine (with a Motorala
68010 processor) and being amazed at what happened with my save files when I
moved to my first DOS machine (with an 80386 processor); I hadn't ever had
to deal with byte order before that. In that case, the save data was
relatively small, so I re-wrote it to save in ASCII printable characters,
which solved that problem. :)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Captain Jack wrote:
> I remember having written a game on a portable Unix machine (with a Motorala
> 68010 processor) and being amazed at what happened with my save files when I
> moved to my first DOS machine (with an 80386 processor); I hadn't ever had
> to deal with byte order before that. In that case, the save data was
> relatively small, so I re-wrote it to save in ASCII printable characters,
> which solved that problem. :)
It still makes me sad that Intel chose to store bytes in the wrong order
all those years ago...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible schrieb:
> Captain Jack wrote:
>
>> I remember having written a game on a portable Unix machine (with a
>> Motorala 68010 processor) and being amazed at what happened with my
>> save files when I moved to my first DOS machine (with an 80386
>> processor); I hadn't ever had to deal with byte order before that. In
>> that case, the save data was relatively small, so I re-wrote it to
>> save in ASCII printable characters, which solved that problem. :)
>
> It still makes me sad that Intel chose to store bytes in the wrong order
> all those years ago...
Define "wrong" in this context...
As a matter of fact, the only situation where byte ordering can be
defined as "right" or "wrong" with irrefutable arguments is in serial
transmission, dependent on the native bit ordering of the physical
layer: If the physical layer sends each byte starting with the least
significant bit, then consistency would demand to send multi-byte values
starting with the least significant byte, so that all in all the least
significant bit of the multi-byte value is sent first; on the other
hand, if the physical layer transmits the most significant bit of each
byte first, the same reasoning would mandate sending the most
significant byte first. There are other arguments pro and contra both
little and big endian, but none as compelling as serial transmission.
It so happens that Intel format is actually doing it "right" in this
respect: AFAIK two of the most important serial interfaces - RS232 and
Ethernet - both transmit each byte starting with the least significant
bit first.
So in this sense the "network byte ordering" used for multy-octet data
in most Internet standards is actually a crappy convention, as the bits
of multi-byte data will be transmitted in an inconsistent order.
BTW, Intel is not the only company that preferred little-endian convention.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> It still makes me sad that Intel chose to store bytes in the wrong
>> order all those years ago...
>
> Define "wrong" in this context...
When you read data from a first, you read the first byte first, and the
last byte last. Therefore, the first byte should be the MSB. But no,
Intel decided that this would be too easy. And now we have the spectacle
of cryptosystems and so forth designed with each data block being split
into octets and reversed before you can process it...
> It so happens that Intel format is actually doing it "right" in this
> respect: AFAIK two of the most important serial interfaces - RS232 and
> Ethernet - both transmit each byte starting with the least significant
> bit first.
Well then that would be pretty dubious as well. (AFAIK, MIDI does it the
correct way around.)
> BTW, Intel is not the only company that preferred little-endian convention.
Indeed, the 6502 did it decades ago. Still doesn't make it right.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Invisible" <voi### [at] dev null> wrote in message
news:4ae5bd35$1@news.povray.org...
> When you read data from a first, you read the first byte first, and the
> last byte last. Therefore, the first byte should be the MSB. But no, Intel
> decided that this would be too easy. And now we have the spectacle of
> cryptosystems and so forth designed with each data block being split into
> octets and reversed before you can process it...
That kinda sounds like saying that the only correct way to read a human
language is left to right.
.ti ot desu t'nera yeht fi neve ,enif tsuj tfel ot thgir daer nac elpoeP
:D
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> When you read data from a first, you read the first byte first, and the
>> last byte last. Therefore, the first byte should be the MSB.
>
> That kinda sounds like saying that the only correct way to read a human
> language is left to right.
As far as I know, even in languages that are usually written from right
to left, the most significant digit is still written "first" and the
least written "last".
But hey, why worry? I'm communicating with you right now using a code
that still has codepoints resurved for obsolete control signals like
BEL, RS, SYN and EOT...
(Don't get me started on the whole EOL marker thing!)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |