Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1961 > unrolled thread

Over 256 Character BASIC string

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Over 256 Character BASIC string Kevin Wells <kev@kevsoft.co.uk> - 2012-07-31 16:48 +0100
    Re: Over 256 Character BASIC string Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-07-31 19:22 +0100
      Re: Over 256 Character BASIC string "David Holden" <SpamBin@apdl.co.uk> - 2012-08-01 07:27 +0000
        Re: Over 256 Character BASIC string Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-08-01 10:52 +0100
      Re: Over 256 Character BASIC string Kevin Wells <kev@kevsoft.co.uk> - 2012-08-01 19:17 +0100
        Re: Over 256 Character BASIC string jgh@arcade.demon.co.uk - 2012-08-01 20:41 -0700
        Re: Over 256 Character BASIC string Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-08-02 10:39 +0100
          Re: Over 256 Character BASIC string Kevin Wells <kev@kevsoft.co.uk> - 2012-08-04 18:56 +0100
            Re: Over 256 Character BASIC string Steve Drain <steve@kappa.me.uk> - 2012-08-04 19:56 +0100
              Re: Over 256 Character BASIC string Kevin Wells <kev@kevsoft.co.uk> - 2012-08-08 15:04 +0100
                Re: Over 256 Character BASIC string jgh@arcade.demon.co.uk (Jonathan Graham Harston) - 2012-08-08 23:15 +0100
                  Re: Over 256 Character BASIC string Kevin Wells <kev@kevsoft.co.uk> - 2012-08-09 15:14 +0100
        Re: Over 256 Character BASIC string Gavin Wraith <gavin@wra1th.plus.com> - 2012-08-02 18:35 +0100
          Re: Over 256 Character BASIC string Kevin Wells <kev@kevsoft.co.uk> - 2012-08-04 18:58 +0100
        Re: Over 256 Character BASIC string Steve Drain <steve@kappa.me.uk> - 2012-08-03 10:37 +0100
        Re: Over 256 Character BASIC string "Ste (news)" <steve@revi11.plus.com> - 2012-08-10 14:15 +0100
          Re: Over 256 Character BASIC string "Ste (news)" <steve@revi11.plus.com> - 2012-08-10 14:23 +0100
            Re: Over 256 Character BASIC string Kevin Wells <kev@kevsoft.co.uk> - 2012-08-13 19:19 +0100
    Re: Over 256 Character BASIC string druck <news@druck.org.uk> - 2012-07-31 22:20 +0100
    Re: Over 256 Character BASIC string Duncan Moore <duncan.moore@gmx.com> - 2012-08-03 02:11 -0700

#1961 — Over 256 Character BASIC string

Hi,

On my Lcheck application the Euro Millions feed one of the lines is over
256 characters long and breaks the application.

What is the best way in BASIC for strings over 256 characters?

Thanks.

-- 
Kev Wells  http://riscos.kevsoft.co.uk/
http://kevsoft.co.uk/   http://kevsoft.co.uk/AleQuest/
ICQ 238580561
Useless Fact 04 The number of islands around mainland Britain is 6289.

[toc] | [next] | [standalone]

#1962

In article <d5c1f8b752.Kevin@talktalk.net>,
   Kevin Wells <kev@kevsoft.co.uk> wrote:
> On my Lcheck application the Euro Millions feed one of the lines is
> over 256 characters long and breaks the application.

> What is the best way in BASIC for strings over 256 characters?

There are libraries available, but if you are doing it yourself, in
essence you need to DIM a block of memory of suitable length, and
then access the data using the $indirection operator. If you need
more details give a shout.

-- 
Chris Johnson

[toc] | [prev] | [next] | [standalone]

#1964

On 31-Jul-2012, Chris Johnson <chrisjohnson+news@spamcop.net> wrote:

> There are libraries available, but if you are doing it yourself, in
> essence you need to DIM a block of memory of suitable length, and
> then access the data using the $indirection operator. If you need
> more details give a shout.

You are still limited to 255 characters if you use the $ indirection
operator. You need to use ? to access individual characters.

Forget 'string', it's just a collection of bytes.

-- 
David Holden  -  APDL  -  <http://www.apdl.co.uk>

[toc] | [prev] | [next] | [standalone]

#1965

In article <a7s432FnajU1@mid.individual.net>,
   David Holden <SpamBin@apdl.co.uk> wrote:
> You are still limited to 255 characters if you use the $ indirection
> operator. You need to use ? to access individual characters.

Sorry - that's what I meant but it didn't come out that way 8(

-- 
Chris Johnson

[toc] | [prev] | [next] | [standalone]

#1966

In message <52b806d0dcchrisjohnson+news@spamcop.net>
          Chris Johnson <chrisjohnson+news@spamcop.net> wrote:

>In article <d5c1f8b752.Kevin@talktalk.net>,
>   Kevin Wells <kev@kevsoft.co.uk> wrote:
>> On my Lcheck application the Euro Millions feed one of the lines is
>> over 256 characters long and breaks the application.
>
>> What is the best way in BASIC for strings over 256 characters?
>
>There are libraries available, but if you are doing it yourself, in
>essence you need to DIM a block of memory of suitable length, and
>then access the data using the $indirection operator. If you need
>more details give a shout.
>

Yes please, the trouble is I don't know how long the line will be, as
what the application does is download the latest Euro Millions results
that are a csv file, and display the latest 11 draws one line at a time.

Every so often the Euro Millions have a super duper millionaire draws
where they draw many £1 Million winners and last Friday's they had 100
which gives that line 1033 characters long.


-- 
Kev Wells  http://riscos.kevsoft.co.uk/
http://kevsoft.co.uk/   http://kevsoft.co.uk/AleQuest/
ICQ 238580561
Useless Fact 03 You burn 3.5 calories each time you laugh.

[toc] | [prev] | [next] | [standalone]

#1967

Kevin Wells wrote:
>>> On my Lcheck application the Euro Millions feed one of the lines is
>>> over 256 characters long and breaks the application.

If you are trying to use strings over 256 characters in length,
stop treating them as strings, treat them as text blocks.

JGH

[toc] | [prev] | [next] | [standalone]

#1968

In article <f72f8ab852.Kevin@talktalk.net>,
   Kevin Wells <kev@kevsoft.co.uk> wrote:
> Yes please, the trouble is I don't know how long the line will be,
> as what the application does is download the latest Euro Millions
> results that are a csv file, and display the latest 11 draws one
> line at a time.

The first questions are
 - how are you downloading the data?
 - How do you know how much data there is to fetch?
 - Does it go into a buffer in memory, or to a file on disc?
 - If the former, are you fetching one line at a time, or does it all
   come at once?

Memory is relatively cheap on modern machines - a DIM of say 8000 is
not excessive if that is the way to go. Once you have the data block
in memory, it is easy to step through the data one byte at a time
looking for commas for end of cell and control characters (LF, CR,
even NULL) to signify end of line.

If you want more detailed help, it would be better to take it to
private email. My posting address is valid for first contact.

-- 
Chris Johnson

[toc] | [prev] | [next] | [standalone]

#1977

In message <52b8de9a49chrisjohnson+news@spamcop.net>
          Chris Johnson <chrisjohnson+news@spamcop.net> wrote:

>In article <f72f8ab852.Kevin@talktalk.net>,
>   Kevin Wells <kev@kevsoft.co.uk> wrote:
>> Yes please, the trouble is I don't know how long the line will be,
>> as what the application does is download the latest Euro Millions
>> results that are a csv file, and display the latest 11 draws one
>> line at a time.
>
>The first questions are
> - how are you downloading the data?

Wget and saving it to Scrap, the application is registered.

> - How do you know how much data there is to fetch?

I don't it is about 50 odd lines.
> - Does it go into a buffer in memory, or to a file on disc?
> - If the former, are you fetching one line at a time, or does it all
>   come at once?

I use an OPENIN to read the file and an A$=GETS# to access it as a
string.
>
>Memory is relatively cheap on modern machines - a DIM of say 8000 is
>not excessive if that is the way to go. Once you have the data block
>in memory, it is easy to step through the data one byte at a time
>looking for commas for end of cell and control characters (LF, CR,
>even NULL) to signify end of line.

I already go through it one character at a time looking for commas and
speech marks, so that looks like the way to go, I take it that the
A$=GETS# would be the bit that needs changing.
>
>If you want more detailed help, it would be better to take it to
>private email. My posting address is valid for first contact.
>


-- 
Kev Wells  http://riscos.kevsoft.co.uk/
http://kevsoft.co.uk/   http://kevsoft.co.uk/AleQuest/
ICQ 238580561
So many beers so little time.

[toc] | [prev] | [next] | [standalone]

#1978

Kevin Wells wrote:
> I already go through it one character at a time looking for commas and
> speech marks, so that looks like the way to go, I take it that the
> A$=GETS# would be the bit that needs changing.

A few thoughts.

If the file is not large, you could use BGET and read the file 
byte-by-byte, but many would suggest this is not very efficient.

If you are using strings, for elegance sake, I hope you are not checking 
characters using MID$ or its ilk. INSTR is very fast, and you can set up 
indices to control the searches through the string. I have a FN that 
will deliver a field from a string, taking account of quotes, if that 
would be useful.

If you load the whole file into a block of memory, then using a 
FOR...NEXT loop and ?index% is very much the quickest way to check 
character by character, but may well not be as quick as INSTR with a 
string, depending on the data.

Steve

[toc] | [prev] | [next] | [standalone]

#2031

In message <RheTr.452007$j37.433394@fx01.am4>
          Steve Drain <steve@kappa.me.uk> wrote:

>Kevin Wells wrote:
>> I already go through it one character at a time looking for commas and
>> speech marks, so that looks like the way to go, I take it that the
>> A$=GETS# would be the bit that needs changing.
>
>A few thoughts.
>
>If the file is not large, you could use BGET and read the file
>byte-by-byte, but many would suggest this is not very efficient.

I think BGET would be the easiest solution, but having never used it
before I would appreciate an example that will show me how to ignore the
first two lines, then when it finds a speech mark end that line, and go
as far as line 12.
>
>If you are using strings, for elegance sake, I hope you are not checking
>characters using MID$ or its ilk. INSTR is very fast, and you can set up
>indices to control the searches through the string. I have a FN that
>will deliver a field from a string, taking account of quotes, if that
>would be useful.

Thanks that would be very useful, a I'm using MID$ at the moment, I'm
only using strings as that is what I've always done, and occasionally a
line will be to long, so I'm not against using other means, as I'm
putting the information straight into a text icon.
>
>If you load the whole file into a block of memory, then using a
>FOR...NEXT loop and ?index% is very much the quickest way to check
>character by character, but may well not be as quick as INSTR with a
>string, depending on the data.
>
>Steve
>


-- 
Kev Wells  http://riscos.kevsoft.co.uk/
http://kevsoft.co.uk/   http://kevsoft.co.uk/AleQuest/
ICQ 238580561
Useless Fact 03 You burn 3.5 calories each time you laugh.

[toc] | [prev] | [next] | [standalone]

#2038

kev wrote:
> > I have a FN that will deliver a field from a string, taking
> > account of quotes, if that would be useful.
> 
> Thanks that would be very useful, a I'm using MID$ at the moment, I'm
> only using strings as that is what I've always done, and occasionally a
> line will be to long, so I'm not against using other means, as I'm
> putting the information straight into a text icon.
 
Is http://mdfs.net/blib/Unsorted/ReadCSV of any use?
 
-- 
J.G.Harston - jgh@mdfs.net - mdfs.net/jgh
Whitby Yards Gazetteer - http://mdfs.net/Docs/Books/YofWhitby/Gazetteer

[toc] | [prev] | [next] | [standalone]

#2041

In message <120808235504@arcade.demon.co.uk>
          jgh@arcade.demon.co.uk (Jonathan Graham Harston) wrote:

>kev wrote:
>> > I have a FN that will deliver a field from a string, taking
>> > account of quotes, if that would be useful.
>>
>> Thanks that would be very useful, a I'm using MID$ at the moment, I'm
>> only using strings as that is what I've always done, and occasionally a
>> line will be to long, so I'm not against using other means, as I'm
>> putting the information straight into a text icon.
>
>Is http://mdfs.net/blib/Unsorted/ReadCSV of any use?

Unfortunately it redirects to this page and a Not Found is produced:

<http://mdfs.net/System/Library/BLib/Unsorted/ReadCSV>
>


-- 
Kev Wells  http://riscos.kevsoft.co.uk/
http://kevsoft.co.uk/   http://kevsoft.co.uk/AleQuest/
ICQ 238580561
IF your nose runs and your feet smell it means your upside down.

[toc] | [prev] | [next] | [standalone]

#1969

In message <f72f8ab852.Kevin@talktalk.net>
          Kevin Wells <kev@kevsoft.co.uk> wrote:

> >> What is the best way in BASIC for strings over 256 characters?

> Yes please, the trouble is I don't know how long the line will be, as
> what the application does is download the latest Euro Millions results
> that are a csv file, and display the latest 11 draws one line at a time.
> 
> Every so often the Euro Millions have a super duper millionaire draws
> where they draw many £1 Million winners and last Friday's they had 100
> which gives that line 1033 characters long.

If you use RiscLua instead of Basic you can stop worrying about 
line lengths. Presuming you have downloaded the csv data to a file
and that you have set a variable x to hold the file's pathname
on your disc then

  for line in io.lines (x) do f (line) end

lets you apply a procedure f to each line of the file in turn,
where "line" means a string of characters terminated by a newline,
i.e. one record in a csv file. Breaking the line up into fields
separated by commas (that do not appear inside quoted strings, 
of course) is easy, too, if you use the lpeg library. 
      
-- 
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

[toc] | [prev] | [next] | [standalone]

#1976

In message <77320ab952.wra1th@wra1th.plus.com>
          Gavin Wraith <gavin@wra1th.plus.com> wrote:

>In message <f72f8ab852.Kevin@talktalk.net>
>          Kevin Wells <kev@kevsoft.co.uk> wrote:
>
>> >> What is the best way in BASIC for strings over 256 characters?
>
>> Yes please, the trouble is I don't know how long the line will be, as
>> what the application does is download the latest Euro Millions results
>> that are a csv file, and display the latest 11 draws one line at a time.
>>
>> Every so often the Euro Millions have a super duper millionaire draws
>> where they draw many £1 Million winners and last Friday's they had 100
>> which gives that line 1033 characters long.
>
>If you use RiscLua instead of Basic you can stop worrying about
>line lengths. Presuming you have downloaded the csv data to a file
>and that you have set a variable x to hold the file's pathname
>on your disc then

I've got RISCLua but I'm not far enough along the lines of it yet
reproduce Lcheck or any WIMP RISC OS app yet.
>
>  for line in io.lines (x) do f (line) end
>
>lets you apply a procedure f to each line of the file in turn,
>where "line" means a string of characters terminated by a newline,
>i.e. one record in a csv file. Breaking the line up into fields
>separated by commas (that do not appear inside quoted strings,
>of course) is easy, too, if you use the lpeg library.
>


-- 
Kev Wells  http://riscos.kevsoft.co.uk/
http://kevsoft.co.uk/   http://kevsoft.co.uk/AleQuest/
ICQ 238580561
There are 2 types of animals food and the useless kind.

[toc] | [prev] | [next] | [standalone]

#1971

Kevin Wells wrote:
> Yes please, the trouble is I don't know how long the line will be, as
> what the application does is download the latest Euro Millions results
> that are a csv file, and display the latest 11 draws one line at a time.

I agree that, in general, large text blocks are best not treated as 
strings at all. Even so, I might have suggested having a look at the 
latest version of Basalt, which can deal with long strings and CSV files 
with them in. However, I noted that your program uses DrWimp, which has 
an API that would make using Basalt very tricky.

There may, nevertheless, be a solution using BASIC strings if your data 
is in a file. I have dealt with a tab-separated file with long lines:

  Read a string from the file, which BASIC does up to 255 characters if 
there is no terminator.

  Flag if the string length is 255, as there will be more to read of 
that line.

  Extract those fields the string contains, noting how much of the 
string has been used.

  Reset the file pointer to the part of the line following what you have 
used so far.

  Repeat until the length of the string read is less than 255.

"Writing the code is left as an exercise for the reader". ;-)

Steve

[toc] | [prev] | [next] | [standalone]

#2047

In article <f72f8ab852.Kevin@talktalk.net>,
   Kevin Wells <kev@kevsoft.co.uk> wrote:
> Every so often the Euro Millions have a super duper millionaire draws
> where they draw many £1 Million winners and last Friday's they had 100
> which gives that line 1033 characters long.

With !Routines from www.7thsoftware.co.uk/software.htm

  LIBRARY "<Routines$Linker>"
  PROC`library("file.parse_file")

  PROC`parse_file_long(123, "#", file_name$)

  ...

  DEF PROCparsed_file_long(handle%, line%, hstr%, length%)
    REM handle% is the handle you passed into `parse_file_long() - e.g. 123
    REM line% is the line number
    REM hstr% is the long (heap) string - see string.long library for info
    REM length% is length of the string (bytes), excluding terminator   
  ENDPROC

Ta,

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

[toc] | [prev] | [next] | [standalone]

#2048

In article <52bd111261steve@revi11.plus.com>,
   Ste (news) <steve@revi11.plus.com> wrote:
>   PROC`parse_file_long(123, "#", file_name$)

I should've mentioned that "#" is the character to look for when ignoring a
line that is a comment. Just use "" if the file you are parsing doesn't have
this sort of thing.

Also note (for reasons of laziness), this routine _does_ load the whole file
into RAM so won't be able to cope with arbitrarily-sized files, but should
be able to cope with arbitrarily-sized lines.

Final note, any of LF, CR or NULL are treated as a line terminator.

Thanks,

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

[toc] | [prev] | [next] | [standalone]

#2078

In message <52bd11e180steve@revi11.plus.com>
          "Ste (news)" <steve@revi11.plus.com> wrote:

>In article <52bd111261steve@revi11.plus.com>,
>   Ste (news) <steve@revi11.plus.com> wrote:
>>   PROC`parse_file_long(123, "#", file_name$)
>
>I should've mentioned that "#" is the character to look for when ignoring a
>line that is a comment. Just use "" if the file you are parsing doesn't have
>this sort of thing.
>
>Also note (for reasons of laziness), this routine _does_ load the whole file
>into RAM so won't be able to cope with arbitrarily-sized files, but should
>be able to cope with arbitrarily-sized lines.
>
>Final note, any of LF, CR or NULL are treated as a line terminator.
>
>Thanks,
>
>Steve

Thanks for yours and all the others kind people for the help received,
in the end I went with the BGET# method and it now works satisfactory.

The updated application is up for download at:

<http://riscos.kevsoft.co.uk/>

<http://riscos.kevsoft.co.uk/news/?p=59>


-- 
Kev Wells  http://riscos.kevsoft.co.uk/
http://kevsoft.co.uk/   http://kevsoft.co.uk/AleQuest/
ICQ 238580561
The older I get the faster I used to be.

[toc] | [prev] | [next] | [standalone]

#1963

On 31/07/2012 16:48, Kevin Wells wrote:
> Hi,
>
> On my Lcheck application the Euro Millions feed one of the lines is over
> 256 characters long and breaks the application.
>
> What is the best way in BASIC for strings over 256 characters?

Break the line in to more than one string.

---druck

[toc] | [prev] | [next] | [standalone]

#1970

On Tuesday, 31 July 2012 16:48:33 UTC+1, Kevin Wells  wrote:

> What is the best way in BASIC for strings over 256 characters?

You could try using Brandy at http://jaguar.orpheusweb.co.uk/branpage.html

It's a BASIC V interpreter in C, so a bit slower, but allows strings up to 65536 characters.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web