Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > SharkD <mik### [at] gmailcom> wrote:
> >> On 10/25/2009 7:51 AM, Warp wrote:
> >>> Orchid XP v8<voi### [at] devnull>  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

Darren New <dne### [at] sanrrcom> 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

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> SharkD <mik### [at] gmailcom> wrote:
>>>> On 10/25/2009 7:51 AM, Warp wrote:
>>>>> Orchid XP v8<voi### [at] devnull>  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

Warp wrote:
> Darren New <dne### [at] sanrrcom> 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

"Darren New" <dne### [at] sanrrcom> 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

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

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

>> 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

"Invisible" <voi### [at] devnull> 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

>> 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