Curious FILO behavior

[Randy Walker]

I'm trying to do a 2 byte buffer kinda thing -- shoving contents to the left to make room for the new byte on the right, something like this, and I do want to capture the CRLF at the end of the line:

Code: Select all

s$ = "12"
ReadFile(0,somefile$,#PB_Ascii)
While Eof(0) = 0
  redByte = Asc(ReadString(0,#PB_Ascii)
  Xit1.W = (Xit1.W << 8) + redByte ;move right byte To the left & add $0D
  PokeW(@s$,Xit1.W)
  ;Evaluate s$
Wend

Not working the way I expected so I did this to try to figure out what was happening and discovered my bytes were coming out FIFO:

Code: Select all

s$ = "12"
Xit1.W = 33
Debug Xit1.W ; prove Xit1 has 2 bytes
TAG_CR$ = Chr(13) + Chr(10)
redByte =13
Xit1.W = (Xit1.W << 8) + redByte ;move right byte To the left & add $0D
redByte =10
Xit1.W = (Xit1.W << 8) + redByte ;move right byte To the left & add $0A
PokeW(@s$,Xit1.W)
Debug Len(s$) ; prove Xit1 still has 2 bytes
Debug Hex(Asc(Left(s$,1))) ; NOT showing $0D value
Debug Hex(Asc(Right(s$,1))) ; NOT showing $0A value
If s$ = #CRLF$ ; Does not equal $0DOA but should?!!
  Debug "Matched" ; works if 10 and 13 are reversed above?!!
EndIf
Debug "Now Compare #CRLF"
Debug Hex(Asc(Left(#CRLF$,1))) ; NOW showing $0D value
Debug Hex(Asc(Right(#CRLF$,1))) ; NOW showing $0A value

I don't get it.

[infratec]

Since a longt time now, PB uses unicode to store strings.
(Always two bytes per character)
So your stuff is totally wrong.

Code: Select all

EnableExplicit

Define s$

s$ = "12"
ShowMemoryViewer(@s$, StringByteLength(s$) + SizeOf(Character))

Or are you using an outdated version of PB which sill uses ASCII for strings

[infratec]

Code: Select all

EnableExplicit


Define s$, Xit1.l, redByte.a

s$ = "12"

redByte = #CR
Xit1 = (Xit1 >> 16) | (redByte << 16)

redByte = #LF
Xit1 = (Xit1 >> 16) | (redByte << 16)

PokeL(@s$, Xit1)

Debug Len(s$)
Debug Hex(Asc(Left(s$,1)))
Debug Hex(Asc(Right(s$,1)))

If s$ = #CRLF$
  Debug "Matched"
EndIf

[infratec]

It would be easier to read the file by chunks into a buffer.

And ReadString() reads only up to a lineend.

[infratec]

I'm trying to do a 2 byte buffer kinda thing -- shoving contents to the left to make room for the new byte on the right, something like this, and I do want to capture the CRLF at the end of the line:

Code: Select all

s$ = "12"
ReadFile(0,somefile$,#PB_Ascii)
While Eof(0) = 0
  redByte = Asc(ReadString(0,#PB_Ascii)
  Xit1.W = (Xit1.W << 8) + redByte ;move right byte To the left & add $0D
  PokeW(@s$,Xit1.W)
  ;Evaluate s$
Wend

The above code is ... non sense.

ReadString() does not return CRLF, since it reads one line up to this 'mark'
If you want to check for CRLF, then you need ReadData().

But ... we need to know what you want to achieve in general, before we can give you more hints.

[infratec]

Code: Select all

EnableExplicit

Define Format.i, Line$


If ReadFile(0, #PB_Compiler_Home + "Examples\Sources\Arithmetic.pb")
  Format = ReadStringFormat(0)
  While Not Eof(0)
    Line$ = ReadString(0, Format)
    Debug Line$
    ShowMemoryViewer(@Line$, StringByteLength(Line$) + SizeOf(Character))
    If MessageRequester("Break", "Read next line?", #PB_MessageRequester_YesNo) = #PB_MessageRequester_No
      Break
    EndIf
  Wend
  CloseFile(0)
EndIf

No CRLF included.

[Randy Walker]

Code: Select all

EnableExplicit


Define s$, Xit1.l, redByte.a

s$ = "12"

redByte = #CR
Xit1 = (Xit1 >> 16) | (redByte << 16)

redByte = #LF
Xit1 = (Xit1 >> 16) | (redByte << 16)

PokeL(@s$, Xit1)

Debug Len(s$)
Debug Hex(Asc(Left(s$,1)))
Debug Hex(Asc(Right(s$,1)))

If s$ = #CRLF$
  Debug "Matched"
EndIf

I tried your code above and results were way off the mark. It reduced my 2 byte s$ variable down to one byte.
First let me start by saying I had a big booboo in my original post. Cannot pack a full string of data into a single byte, So this:
Asc(ReadString(0,#PB_Ascii)
should have been simply this:
ReadByte(0)

Second, I am Using PB Ver 5.40 LTS with JaPBe because it works for me and JaPBe is not compatible above 5.x AND when I run this code in v6.20 I get totally goofy results. PlUS, I cannot get my really significant project to run at all in ver 6.xx so I am stuck in ver 5.xx indefinitely. Guess its a good thing I got the LTS release.

Third, That ShowMemoryViewer thing only gives info I don't understand:
0000000000B90880 3B 00 ;.
I don't see how that can possibly relate to my original code.

Forth, I think what you are trying to tell me is that the switch to unicode means my 2 byte string is actually 4 bytes, but that doesn't seem to apply because these two lines give me $A and $D values respectively:
Debug Hex(Asc(Left(s$,1))) ; NOT showing $0D value
Debug Hex(Asc(Right(s$,1))) ; NOT showing $0A value
I don't know how they could do that if s$ was actually 4 bytes.

[normeus]

Most valuable player trophy goes to infratec for trying so hard to answer a question with the tiniest bit of information he had.
Thank you infratec

Randy Walker,
I would follow infratec's advice about reading the file into a buffer, it will be faster than reading one byte at a time. then doing your magic bit shifting in memory.
Always add the PureBasic version and your computer OS version to the question.


Norm

[Randy Walker]

Most valuable player trophy goes to infratec for trying so hard to answer a question with the tiniest bit of information he had.
Thank you infratec

Ditto that Thank You infratec!!!

Randy Walker,
I would follow infratec's advice about reading the file into a buffer, it will be faster than reading one byte at a time. then doing your magic bit shifting in memory.
Always add the PureBasic version and your computer OS version to the question.


Norm

Interesting concept. I will definitely consider that idea. Thanks.

[infratec]

So you are using a PB version which uses ASCII for the internal strings.
Unfortunately you did not tell us this main point in your starting post.

So, of course, my code terminates your string, because I insert additional 00s which are EOLs for an ASCII string.

But still, I don't know what you want to achieve.

Cut the file into lines?
Then use ReadString()

Do want to read the whole file into one string?
Then use ReadData() with a buffer which is one byte larger and set the lastbyte to 00 then use PeekS() to build a string from it.

I can not remember what 5.40 can and what not, so it's difficult for me to write code for you.
But if you tell me your goal and I can not provide hints for you, I will install 5.40 and try to solve it.

[Randy Walker]

Ok, reading the whole file into a buffer just doesn't make sense to me, because depending on user request It may load the entire file into an array anyway so that would unnecessarily occupy twice the memory. There is of course freememory option but still doesn't make sense. But here is what I found. If I just reverse the bit shift I get the proper results:

Code: Select all

s$ = "12"
Xit1.W = 33
Debug Xit1.W ; prove Xit1 has 2 bytes
TAG_CR$ = Chr(13) + Chr(10)
redByte =13
Xit1.W = (Xit1.W >> 8) + redByte*256 ;move right byte To the left & add $0D
redByte =10
Xit1.W = (Xit1.W >> 8) + redByte*256 ;move right byte To the left & add $0A
PokeW(@s$,Xit1.W)
Debug Len(s$) ; prove Xit1 still has 2 bytes
Debug Hex(Asc(Left(s$,1))) ; NOT showing $0D value
Debug Hex(Asc(Right(s$,1))) ; NOT showing $0A value
If s$ = #CRLF$ ; Does not equal $0DOA
  Debug "Matched" ; works if 10 and 13 are reversed above?!!
EndIf
Debug "Now Compare #CRLF"
Debug Hex(Asc(Left(#CRLF$,1))) ; NOT showing $0D value
Debug Hex(Asc(Right(#CRLF$,1))) ; NOT showing $0A value

AND NO -- it does not work in ver 6.20, But works fine in ver 5.40
I still don't understand why reading left to right didn't work to begin with. Plain to see though why it would be a huge error for anyone to call me a programmer.

[infratec]

You use a word variable.
This uses 2 bytes and ... they are stored with the endianess of the CPU
So your bytes needs top be swapped.

That's the reason why I used ShowMemoryViewer, that you can see what happens.

You need to know about endianess if you use such things.

[Randy Walker]

So you are using a PB version which uses ASCII for the internal strings.
Unfortunately you did not tell us this main point in your starting post.

No But I did mention somewhere that I was an idiot.

I can not remember what 5.40 can and what not, so it's difficult for me to write code for you.
But if you tell me your goal and I can not provide hints for you, I will install 5.40 and try to solve it.

OH NO -- Please do not go to such bother. Way too far above and beyond. WOW!! You've done that already, THANKS!!!

[SMaag]

You did a lot of 'not good things"

1. You use Shiftleft and Add on a signed 16Bit value. (This is not a problem in your example with the value of 33)
But generally this is not a good idea. Better use unsigned 16Bit what is .u

You have to be in mind, PB's shift is an arithmetic shift which checks the sign bit! PB do not support a simple binary bitshift.

2. You did not explain exactly what is your goal.
- do you want to shift a complete string 1 char left? If yes, why?

3. Character or Bytewise access to a String is much more effective with a pChar 'Pseudostructure'

Code: Select all

EnableExplicit

Structure pChar
  a.a[0]    ; Byte access, 'ASCii'
  c.c[0]    ; Char access
  u.u[0]    ; unsigned WORD access 'unicode'
EndStructure

Define s$ = "12"
Define *Char.pChar

*Char = @s$

Debug *Char\a[0]
Debug *Char\a[1]  ; on unicode systems this will be 0

Debug *Char\c[0]  ; with .c char access it's always the character, 1Byte at ASCii System 2Byte at Unicode 
Debug *Char\c[1]

[Randy Walker]

You did a lot of 'not good things"

I am a master at that. Thank you very much.

1. You use Shiftleft and Add on a signed 16Bit value. (This is not a problem in your example with the value of 33)
But generally this is not a good idea. Better use unsigned 16Bit what is .u

Is that why I can't read the CRLF string left to right and get CR LF in the same order?

You have to be in mind, PB's shift is an arithmetic shift which checks the sign bit! PB do not support a simple binary bitshift.

OK, maybe that's why I can't read the CRLF string left to right and get CR LF in the same order?

2. You did not explain exactly what is your goal.
- do you want to shift a complete string 1 char left? If yes, why?

Unfortunately for me, I cannot share my code for security reasons, so the explanation would be rather lengthly. NO, don't want to shift a complete string left. For that I would use a buffer longer than 2 bytes and maybe employ the MoveMemory() commend.

3. Character or Bytewise access to a String is much more effective with a pChar 'Pseudostructure'

i tried your code, but it didn't help explain or correct the problem with reading the CRLF string left to right and getting CR LF in the same order.

Uhh! maybe that's the trick -- shift using MoveMemory() instead of <<
But No. That makes no sense either.
This project started about 25-30 years ago using compiled GFA basic for PC, and later had to be ported over to PureBasic (as best option I could find) because 16 bit was moving out of fashion and that migration was so many years ago, I just can't begin to relate to my old code to resolve new issues that crop up. It's a mess. (headbang)