Darren New wrote:
> 
> I already have millions of files. That's the problem. :-)
> 

Well yes, now, but possibly in the future? :)

-- 
Eero "Aero" Ahonen
    http://www.zbxt.net
       aer### [at] removethiszbxtnetinvalid

Post a reply to this message

Eero Ahonen wrote:
> Darren New wrote:
>>
>> I already have millions of files. That's the problem. :-)
>>
> 
> Well yes, now, but possibly in the future? :)

I am saying that I fail to see how split would *reduce* the number of 
files I have, considering its functionality.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> The only way I can see it being slower is there's actually two different 
> sets of code, based on what order things are in, such that (for example) 
> one branch adds two numbers using "+" and the other does some magic to 
> add 0xA000 and 0xA000 to get 0x4001 automatically without actually 
> treating them as binary integers. Is that what you're referring to?

  If I remember correctly, what mplayer does (well, some of its video
filters, actually) is to build 4-byte pixels into words and then it
writes those pixels on a per-word basis to some output buffer. Naturally
the endianess of the architecture determines if the R channel goes to
the lower byte or the upper byte of the word.
  If endianess is not taken into account, in architectures with the other
endianess the color channels will be effectively swapped. (I know this
from actual experience.)

  Naturally it could write the bytes themselves, ie. on a per-channel
basis instead of a per-pixel basis, but those would be 4 writes instead
of 1. Another possibility would be to build the word always in the same
way and have the "compiler reverse it in architectures with the other
endianess" (if that's even possible in any compiler of any language),
but that would mean a bunch of extra steps in that other endianess
architecture, for no good reason.

-- 
                                                          - Warp

Post a reply to this message

On Tue, 11 Mar 2008 13:45:25 -0700, Darren New wrote:

> Jim Henderson wrote:
>> Our software testers used the trick you describe to make programs work
>> together that had this type of conflict.
> 
> I wouldn't call it a *trick* as such. It's a part of the design in the
> OS to support exactly the situation you had. :-)

Well, you know what I mean - the standard installer wasn't smart enough 
to leverage this "feature" of the OS so the conflict didn't happen.

Jim

Post a reply to this message

Warp wrote:
> Another possibility would be to build the word always in the same
> way and have the "compiler reverse it in architectures with the other
> endianess" (if that's even possible in any compiler of any language),
> but that would mean a bunch of extra steps in that other endianess
> architecture, for no good reason.

No, you'd declare a four-byte integer in native endianness, and a 
four-byte word in the buffer in little (or big) endianness, and have the 
compiler either generate code to directly copy (if the native 
architecture's endianness matches the spec's endienness) or have it 
generate the optimal machine code sequence to do the swap if they don't 
match.

The "build four-byte pixels into words" works just fine too.

(I forget the exact syntax, but it's something like)
outint : new integer 0..2^32-1;
outint'endian = little;

buffer : array [0..N] of outint;
buffer[i] = r * 256*256*256 + g * 256 * 256 + b * 256 + a;

If outint is in native form, it does the shifts and stores it, or 
assigns the bytes, or whatever the compiler can come up with.

If outint is in byte-swapped order, the compiler can *also* deduce it 
needs to do the shifts differently, and just assign bytes to the 
appropriate places in the word.

(Note that compilers aren't dumb enough to actually multiply when you 
say r * 256 * 256 * 256.)

Makes it much clearer code, methinks, and no ifdefs.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New wrote:
> 
> I am saying that I fail to see how split would *reduce* the number of 
> files I have, considering its functionality.
> 

Composing with some of those 49,999 other tools it gives you the 
possibility of eg. removing a part (beginning, ending or from the 
middle) of a file.

"Now, if Linux supported the thing that NTFS supports where you can 
delete the beginning of a file, maybe I'd use that."

Well ok, after that you wrote about chopping the file, which practically 
is what split does, but it should be able to work without creating 
millions of (temp)files in the middle of the process.

-- 
Eero "Aero" Ahonen
    http://www.zbxt.net
       aer### [at] removethiszbxtnetinvalid

Post a reply to this message

>>> But if I wanted it to work all the time, I'd write it in C and be done
>>> with it - then the shell doesn't come into play. :-)
>> Yah, as I said, when it gets messy, I use Tcl. :-)
> 
> Really the best option - remove the shell. :-)

Cool. I just hope your filenames don't contain any of the characters 
that Tcl considers to be "special" either. :-P

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> outint'endian = little;

  Exactly which language is this? And have you actually corroborated by
examining the resulting machine code that it indeed does as you say?

-- 
                                                          - Warp

Post a reply to this message

On Wed, 12 Mar 2008 09:15:42 +0000, Invisible wrote:

>>>> But if I wanted it to work all the time, I'd write it in C and be
>>>> done with it - then the shell doesn't come into play. :-)
>>> Yah, as I said, when it gets messy, I use Tcl. :-)
>> 
>> Really the best option - remove the shell. :-)
> 
> Cool. I just hope your filenames don't contain any of the characters
> that Tcl considers to be "special" either. :-P

Well, I use C, and it deals with literal strings, but I suspect TCL is 
the same in that regard.

Jim

Post a reply to this message

Nicolas Alvarez wrote:

> And also one reason why command-line tools are better for many things. 
> (image editing probably not one of them)

Funny, there's a set of commandline tools for just that called 
ImageMagick. :D

Post a reply to this message