Hey all, thanks for reading. Today is my first attempt at getting some
hands on with Ruby. So far so good, but I'm having a slight issue I hope
to clear up.

Anyways, I decided to write a SRAM save file editor for a popular
GameBoy game. Problem is for some reason putc is writing 2 bytes when
ever I try to write 0x0A. It instead writes 0D 0A into the file.

Heres my code (go easy, first attempt at Ruby ever xD )

def ZeldaEdit.ChangeBButtonItem()
ZeldaEdit.ListItemValues()
ZeldaEdit.ReadBButtonItem()
printf("Enter new item value from the list above: ")
@NewItemB = STDIN.gets.chomp #1
@NewItemB = @NewItemB.hex
@SaveFile.pos = "0x405".hex
@SaveFile.putc @NewItemB #2
end

If I type "a" at the gets for #1, once it gets to #2 is putc's 0D 0A.
If I enter 0-9 or B-F it works just fine, the problem seems to only be
with A. For the past few hours I've been scratching my head. I have no
clue why it is doing that, when other values work just fine.

Any is greatly appreciated, it's not a crucial project by any
means. Just a learning experience.

Thanks in advance for your !
-Minic
--
Posted via http://www.ruby-forum.com/.

On Sun, May 11, 2008 at 03:28:31PM +0900, Minic Minic wrote:
> Anyways, I decided to write a SRAM save file editor for a popular
> GameBoy game. Problem is for some reason putc is writing 2 bytes when
> ever I try to write 0x0A. It instead writes 0D 0A into the file.

Looks like you are on Windows. Try opening @SaveFile in binary mode (@SaveFile
= File.open("fname", "wb")) which prevents LF -> CRLF conversion.

--
Jos Backus
jos at catnook.com

Ah ha! Indeed I am on Windows. I knew about the LF to CRLF conversion,
but it never struck me.

To make a long story short, I tried to open the file with mode a+b which
was what I needed. Then @SaveFile.pos quit working on me even after
@SaveFile.rewind, it would write to the end of the file. So I
@SaveFile.binmode and BOOM, my first Ruby script is now working as
intended!

Thank you so very much. I never would of figured it would do the
conversion when not in binary mode.

So now the REAL question is, am I to blame or is Windows? :P (don't
answer that)

Thanks again, you truly made my night!
-Minic
--
Posted via http://www.ruby-forum.com/.

Jos Backus wrote:
> On Sun, May 11, 2008 at 03:28:31PM +0900, Minic Minic wrote:
>> Anyways, I decided to write a SRAM save file editor for a popular
>> GameBoy game. Problem is for some reason putc is writing 2 bytes when
>> ever I try to write 0x0A. It instead writes 0D 0A into the file.
>
> Looks like you are on Windows. Try opening @SaveFile in binary mode
> (@SaveFile
> = File.open("fname", "wb")) which prevents LF -> CRLF conversion.

Why would that ? The output in the file is 0A 0D, which is a
windows newline. If the file was not opened in binary mode, that means
the ruby code must have tried to write '\n' to the file, which ruby then
converted to the OS's newline, which for windows is 0A 0D. However,
getting the string "a + newline" from the user and then chomp()'ing off
the newline should leave you with "a". And using putc() to write the
string "a" to a file does not involve any newlines.




--
Posted via http://www.ruby-forum.com/.

On 11 May 2008, at 09:58, 7stud -- wrote:
> Jos Backus wrote:
>> On Sun, May 11, 2008 at 03:28:31PM +0900, Minic Minic wrote:
>>> Anyways, I decided to write a SRAM save file editor for a popular
>>> GameBoy game. Problem is for some reason putc is writing 2 bytes
>>> when
>>> ever I try to write 0x0A. It instead writes 0D 0A into the file.
>>
>> Looks like you are on Windows. Try opening @SaveFile in binary mode
>> (@SaveFile
>> = File.open("fname", "wb")) which prevents LF -> CRLF conversion.
>
> Why would that ? The output in the file is 0A 0D, which is a
> windows newline. If the file was not opened in binary mode, that
> means
> the ruby code must have tried to write '\n' to the file, which ruby
> then
> converted to the OS's newline, which for windows is 0A 0D. However,
> getting the string "a + newline" from the user and then chomp()'ing
> off
> the newline should leave you with "a". And using putc() to write the
> string "a" to a file does not involve any newlines.

Because he's not reading or writing 'a' (ASCII character 97) but the
linefeed character (ASCII character 10, otherwise known as CTRL-A).
DOS and her derivatives use the two-character CR LF sequence to
indicate a new line and the C library performs automatic conversion
when a file is opened in text mode. Hence the need to open it in
binary mode instead.

This would be the case in most languages on the Windows platform.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

Hi,

At Sun, 11 May 2008 17:42:25 +0900,
Minic Hoberoff wrote in [ruby-talk:301446]:
> So now the REAL question is, am I to blame or is Windows? :P (don't
> answer that)

It's just a curse of CP/M. (sorry, but couldn't resist...

--
Nobu Nakada

Eleanor McHugh wrote:
> On 11 May 2008, at 09:58, 7stud -- wrote:
>>
>> Why would that ? The output in the file is 0A 0D, which is a
>> windows newline. If the file was not opened in binary mode, that
>> means
>> the ruby code must have tried to write '\n' to the file, which ruby
>> then
>> converted to the OS's newline, which for windows is 0A 0D. However,
>> getting the string "a + newline" from the user and then chomp()'ing
>> off
>> the newline should leave you with "a". And using putc() to write the
>> string "a" to a file does not involve any newlines.
>
> Because he's not reading or writing 'a' (ASCII character 97) but the
> linefeed character (ASCII character 10, otherwise known as CTRL-A).

I don't understand where the op is writing the LF character? It's
obvious from the file output that the op's ruby code must be trying to
write a '\n' to the file somewhere, which then gets converted to a
windows newline, which is a '\r\n', or 0A 0D in hex. But the op claims
to be entering an 'a' for input. The op's program then chomps() off any
newline. So where does the ruby code write a '\n' to the file?
--
Posted via http://www.ruby-forum.com/.

7stud -- wrote:
> Eleanor McHugh wrote:
>> On 11 May 2008, at 09:58, 7stud -- wrote:
>>>
>>> Why would that ? The output in the file is 0A 0D, which is a
>>> windows newline. If the file was not opened in binary mode, that
>>> means
>>> the ruby code must have tried to write '\n' to the file, which ruby
>>> then
>>> converted to the OS's newline, which for windows is 0A 0D. However,
>>> getting the string "a + newline" from the user and then chomp()'ing
>>> off
>>> the newline should leave you with "a". And using putc() to write the
>>> string "a" to a file does not involve any newlines.
>>
>> Because he's not reading or writing 'a' (ASCII character 97) but the
>> linefeed character (ASCII character 10, otherwise known as CTRL-A).
>
> I don't understand where the op is writing the LF character? It's
> obvious from the file output that the op's ruby code must be trying to
> write a '\n' to the file somewhere, which then gets converted to a
> windows newline, which is a '\r\n', or 0A 0D in hex. But the op claims
> to be entering an 'a' for input. The op's program then chomps() off any
> newline. So where does the ruby code write a '\n' to the file?

Furthermore, all that opening the file in binary mode does is prevent
newline conversions--it does not prevent newlines from being written to
the file. The result being that what gets written to the file is
exactly what you specify in your ruby code. Therefore, if the op's ruby
code is writing a '\n' to the file, then what will end up in the file
will be a '\n', or 0D in hex--which is still not an 'a'.



--
Posted via http://www.ruby-forum.com/.

[Note: parts of this message were removed to make it a legal post.]

On Mon, May 12, 2008 at 12:08 AM, 7stud -- <bbxx789_05ss@yahoo.com> wrote:

> 7stud -- wrote:
> > Eleanor McHugh wrote:
> >> On 11 May 2008, at 09:58, 7stud -- wrote:
> >>>
> >>> Why would that ? The output in the file is 0A 0D, which is a
> >>> windows newline. If the file was not opened in binary mode, that
> >>> means
> >>> the ruby code must have tried to write '\n' to the file, which ruby
> >>> then
> >>> converted to the OS's newline, which for windows is 0A 0D. However,
> >>> getting the string "a + newline" from the user and then chomp()'ing
> >>> off
> >>> the newline should leave you with "a". And using putc() to write the
> >>> string "a" to a file does not involve any newlines.
> >>
> >> Because he's not reading or writing 'a' (ASCII character 97) but the
> >> linefeed character (ASCII character 10, otherwise known as CTRL-A).
> >
> > I don't understand where the op is writing the LF character? It's
> > obvious from the file output that the op's ruby code must be trying to
> > write a '\n' to the file somewhere, which then gets converted to a
> > windows newline, which is a '\r\n', or 0A 0D in hex. But the op claims
> > to be entering an 'a' for input. The op's program then chomps() off any
> > newline. So where does the ruby code write a '\n' to the file?
>
> Furthermore, all that opening the file in binary mode does is prevent
> newline conversions--it does not prevent newlines from being written to
> the file. The result being that what gets written to the file is
> exactly what you specify in your ruby code. Therefore, if the op's ruby
> code is writing a '\n' to the file, then what will end up in the file
> will be a '\n', or 0D in hex--which is still not an 'a'.
>
>
>
Re-Read that original post again. And I do mean re-read it again. From the
top.

-jf

--
"It's so hard to write a graphics driver that open-sourcing it would not
."
-- Andrew Fear, Software Product Manager, NVIDIA Corporation
http://kerneltrap.org/node/7228

* 7stud -- <bbxx789_05ss@yahoo.com> (18:08) schrieb:

> Therefore, if the op's ruby code is writing a '\n' to the file, then
> what will end up in the file will be a '\n', or 0D in hex--which is
> still not an 'a'.

Well, that's '\r', '\n' is 0x0a or 'a'.hex.

mfg, simon .... l

On May 11, 5:02pm, 7stud -- <bbxx789_0...@yahoo.com> wrote:

> I don't understand where the op is writing the LF character?

Hint: "a".hex == 10 decimal / 0x0a hex == LF

Vidar

Vidar Hokstad wrote:
> On May 11, 5:02�pm, 7stud -- <bbxx789_0...@yahoo.com> wrote:
>
>> I don't understand where the op is writing the LF character?
>
> Hint: "a".hex == 10 decimal / 0x0a hex == LF
>
> Vidar

Thanks.
--
Posted via http://www.ruby-forum.com/.