[#30995] [Bug #3523] win32 exception c0000029 on exit using fibers — B Kelly <redmine@...>

Bug #3523: win32 exception c0000029 on exit using fibers

19 messages 2010/07/02

[#31100] [rubysoc] Queue C-extension patch to come — Ricardo Panaggio <panaggio.ricardo@...>

Hello,

26 messages 2010/07/07
[#31148] Re: [rubysoc] Queue C-extension patch to come — Roger Pack <rogerdpack2@...> 2010/07/09

> As this it my first patch to Ruby, I don't know where to begin with.

[#31320] Re: [rubysoc] Queue C-extension patch to come — Ricardo Panaggio <panaggio.ricardo@...> 2010/07/16

Sorry for leaving this thread for so long. I've tried to finish the

[#31322] Re: [rubysoc] Queue C-extension patch to come — Aaron Patterson <aaron@...> 2010/07/16

On Sat, Jul 17, 2010 at 06:55:35AM +0900, Ricardo Panaggio wrote:

[#31324] Re: [rubysoc] Queue C-extension patch to come — Caleb Clausen <vikkous@...> 2010/07/17

NB: I am Ricardo's mentor for this project.

[#31331] Re: [rubysoc] Queue C-extension patch to come — Benoit Daloze <eregontp@...> 2010/07/17

On 17 July 2010 06:00, Caleb Clausen <vikkous@gmail.com> wrote:

[#31332] Re: [rubysoc] Queue C-extension patch to come — Caleb Clausen <vikkous@...> 2010/07/17

On 7/17/10, Benoit Daloze <eregontp@gmail.com> wrote:

[#31138] Why is there no standard way of creating a String from a char *? — Nikolai Weibull <now@...>

Hi!

14 messages 2010/07/08
[#31146] Re: Why is there no standard way of creating a String from a char *? — Urabe Shyouhei <shyouhei@...> 2010/07/09

(2010/07/09 7:04), Nikolai Weibull wrote:

[#31149] Re: Why is there no standard way of creating a String from a char *? — Nikolai Weibull <now@...> 2010/07/09

On Fri, Jul 9, 2010 at 06:20, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#31150] Re: Why is there no standard way of creating a String from a char *? — Urabe Shyouhei <shyouhei@...> 2010/07/09

(2010/07/09 18:28), Nikolai Weibull wrote:

[#31217] [Bug #3562] regression in respond_to? — Aaron Patterson <redmine@...>

Bug #3562: regression in respond_to?

14 messages 2010/07/12

[#31269] [Bug #3566] memory leak when spawning+joining Threads in a loop — Eric Wong <redmine@...>

Bug #3566: memory leak when spawning+joining Threads in a loop

14 messages 2010/07/13

[#31399] [Backport #3595] Theres no encoding to differentiate a stream of Binary data from an 8-Bit ASCII string — Dreamcat Four <redmine@...>

Backport #3595: Theres no encoding to differentiate a stream of Binary data from an 8-Bit ASCII string

17 messages 2010/07/21

[#31459] [Bug #3607] [trunk/r28731] Gem.path has disappeared? — Ollivier Robert <redmine@...>

Bug #3607: [trunk/r28731] Gem.path has disappeared?

22 messages 2010/07/23

[#31519] [Bug #3622] Net::HTTP does not wait to send request body with Expect: 100-continue — Eric Hodel <redmine@...>

Bug #3622: Net::HTTP does not wait to send request body with Expect: 100-continue

9 messages 2010/07/28

[ruby-core:31438] Re: [Feature #3595] Theres no encoding to differentiate a stream of Binary data from an 8-Bit ASCII string

From: Bill Kelly <billk@...>
Date: 2010-07-22 08:03:31 UTC
List: ruby-core #31438
Dreamcat Four wrote:
> 
> It seems that the correct thing to do when reading a file through an
> IO object is set the encoding to Encoding::BINARY and ignore the
> ascii tags. Unless the ASCII tag says its a text file, then set the
> Encoding to ASCII. Thats pretty easy really.

But one doesn't want to ignore the tags when they denote the
structure of the file.

Here's an excerpt from a simple WAV file parser I had written
several years ago while using ruby 1.8.4, which still works on
1.9.2 thanks to ASCII-8BIT.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

class WAVParseError < StandardError; end
class NotRIFFFormat < WAVParseError; end
class NotWAVEFormat < WAVParseError; end

def read_chunk_header(file)
  chunk_name = file.read(4)
  len = file.read(4).unpack("V").first
  [chunk_name, len]
end

def parse_wav(file)
  riff, riff_len = read_chunk_header(file)
  raise NotRIFFFormat unless riff == 'RIFF'
  riff_end = file.tell + riff_len
  wave = file.read(4)
  raise NotWAVEFormat unless wave == 'WAVE'
  while file.tell < riff_end
    chunk_name, len = read_chunk_header(file)
    fpos = file.tell
    yield file, chunk_name, len if block_given?
    file.seek(fpos + len)
  end
end

if $0 == __FILE__
  # by way of example, just print the chunk names and lengths
  ARGV.each do |fname|
    File.open(fname, "rb") do |io_|
      puts fname
      begin
        parse_wav(io_) do |io, chunk_name, len|
          puts "%4s %08x" % [chunk_name, len]
        end
      rescue StandardError => ex
        warn "error: #{ex.message}"
      end
    end
  end
end


~~~~~~~~~~~~~~~~~~~~~~~~~


$ ruby -v parse_wav.rb m:/snd/startrek/trezap.wav
ruby 1.8.4 (2005-12-24) [i386-mswin32]
m:/snd/startrek/trezap.wav
fmt  00000010
data 0000b9f1
LIST 00000058
cue  0000001c
LIST 00000038


$ ruby19 -v parse_wav.rb m:/snd/startrek/trezap.wav
ruby 1.9.2dev (2010-07-06) [i386-mswin32_100]
m:/snd/startrek/trezap.wav
fmt  00000010
data 0000b9f1
LIST 00000058
cue  0000001c
LIST 00000038


The above just lists the chunks; but an extended version of
the parser decided whether to parse certain chunks in more
detail with logic like the following:

      case chunk_name
        when 'fmt ' then handle_fmt_chunk(io, len)
        when 'data' then handle_data_chunk(io, len)
      end

So we definitely don't wish to ignore the chunk names.


> What prompted me to report this:
> 
> Translating data from a Ruby hash object and simple Ruby types into
> a Plist representation. To give users a standard and appropriate
> way to differentiate between their Ruby strings which are either
> textual (ascii or unicode), and their persistent binary data.

Could you use Encoding::ASCII instead of ASCII-8BIT in this case,
to differentiate between ascii vs. binary?



Regards,

Bill



In This Thread