On 2011-06-06 21:06, Džen wrote:
> Pretty much answers my question. In my use case it'd be easier to use
> delimiters like \0 or \n, due to the data not being binary. However now
> I wonder, which method would need more cpu time? I suppose that when
> using delimiters there isn't a easier way than
On 07/06/11 01:14pm, hiro wrote:
> You'll have to admit it sounds complicated at least :)
Right, true on that -- just wasn't sure how ironic your comment was
meant to be ;)
--
Džen
You'll have to admit it sounds complicated at least :)
On Tue, Jun 7, 2011 at 10:18, Džen wrote:
> On 07/06/11 03:24am, hiro wrote:
>> Interesting, you seem to be on the right track.
>
> ... right track to what? Utter havoc?
>
>
>
On 07/06/11 03:24am, hiro wrote:
> Interesting, you seem to be on the right track.
... right track to what? Utter havoc?
> Reason why I'm asking is because I was wondering how a dmenu-alike
> utility would read data, where each items has multiple values, not
> just one. Kinda like a search utility for table-structured data.
Interesting, you seem to be on the right track.
On 6 June 2011 20:07, Džen wrote:
> I wonder, which method would need more cpu time? I suppose that when
> using delimiters there isn't a easier way than using fgetc(), reading
> through the whole data stream. Hard-coded field lengths would be faster
> if the fields contain a lot of characters I g
Pretty much answers my question. In my use case it'd be easier to use
delimiters like \0 or \n, due to the data not being binary. However now
I wonder, which method would need more cpu time? I suppose that when
using delimiters there isn't a easier way than using fgetc(), reading
through the whole
On 6 June 2011 19:22, Connor Lane Smith wrote:
> 0x000d 0x0006 "hello"\0 0x0007 "world!"\0
I made a mistake here, I meant to say...
0x0011 0x0006 "hello"\0 0x0007 "world!"\0
... including two 2-byte cell widths in the row width.
Hey,
On 6 June 2011 18:19, Džen wrote:
> I was wondering about which way would be the easiest/simplest to
> serialize data, f.e. being read via a file or stdin (data being a
> table of x rows and y columns, each cell a string). I thought of
> using NULL bytes as cell delimiters and newline charac
On 06/06/2011 19:36, Douglas S. Bregolin wrote:
In the ASCII table there's a "record separator" character (0x1E). At
least I think is better than using '\0'.
On 06/06/2011 19:42, Christoph Lohmann wrote:
then why wasn't \x1C-\x1F used before for a data exchange format?
To be honest, I've nev
Hello,
Douglas S. Bregolin wrote:
In the ASCII table there's a "record separator" character (0x1E). At
least I think is better than using '\0'.
then why wasn't \x1C-\x1F used before for a data exchange format?
I don't think we are the first to discover them in the ASCII
table. It would be quie
On Mon, 06 Jun 2011 19:19:56 +0200
Džen wrote:
> I was wondering about which way would be the easiest/simplest to
> serialize data, f.e. being read via a file or stdin (data being a
> table of x rows and y columns, each cell a string). I thought of
> using NULL bytes as cell delimiters and newlin
In the ASCII table there's a "record separator" character (0x1E). At
least I think is better than using '\0'.
On Mon, Jun 6, 2011 at 2:19 PM, Džen wrote:
> I was wondering about which way would be the easiest/simplest to
> serialize data, f.e. being read via a file or stdin (data being a
> table
On Mon, 06 Jun 2011 19:19:56 +0200
Džen wrote:
> I was wondering about which way would be the easiest/simplest to
> serialize data, f.e. being read via a file or stdin (data being a
> table of x rows and y columns, each cell a string). I thought of
> using NULL bytes as cell delimiters and newlin
I was wondering about which way would be the easiest/simplest to
serialize data, f.e. being read via a file or stdin (data being a
table of x rows and y columns, each cell a string). I thought of
using NULL bytes as cell delimiters and newline characters as row
delimiters. This way it wouldn't be
15 matches
Mail list logo
