Removing the restriction would involve major changes essentially to
every opcode, or at least that is the only way I can see to do it.

So the current state in github is that there is a new variant of
fillarray

  i[]   fillarray  "file_name"
  k[]   fillarray  "file_name"

where  the file is a list of numbers, space or comma separated and
dealing in a limited way with comments starting with ; or # until eol.
This is the same as gen23

There is also

  i[]   string2array {{ ....}}
  k[]   string2array {{ ....}}

which does much the same for a string except no comment skipping

The name of the second is not good so I would be happy with a new
name.  the fillarray has been tested and seems correct.  string2array
only lightly tested as of now.

While doing this processing  removed some restrictions on 1 and 2D
only arrays and some better checking.

Please try and give feedback

first test shows for me that there is one extra zero for each dimension 
of the array.  so for this code (the txt file is attached)

giSnippets[] fillarray "snippets_lines.txt"
printarray giSnippets

i get one extra zero at the beginning
   0: 0.0000 1.0000 0.6970 3.8500 66.2000 -38.8000 0.7700 2.0000 2.1250 
3.8400 89.4300
   10: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600 -31.3000 0.7500 
4.0000 2.5430 etc

wheras for
giSnippets[][] init 765, 6
giSnippets fillarray "snippets_lines.txt"
printarray giSnippets

i get two extra zeros at the beginning:
    0: 0.0000 0.0000 1.0000 0.6970 3.8500 66.2000
    1: -38.8000 0.7700 2.0000 2.1250 3.8400 89.4300
    2: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600

otherwise, the content looks ok.

when i put all my text in the string2array opcode, it seems to struggle 
with the length of the string, but with no obvious result.  i can 
interrupt, but it does not seem to be able to load such long strings.

best -
	joachim





On 08/01/19 16:34, John wrote:
> Removing the restriction would involve major changes essentially to
> every opcode, or at least that is the only way I can see to do it.
>
> So the current state in github is that there is a new variant of
> fillarray
>
>   i[]   fillarray  "file_name"
>   k[]   fillarray  "file_name"
>
> where  the file is a list of numbers, space or comma separated and
> dealing in a limited way with comments starting with ; or # until eol.
> This is the same as gen23
>
> There is also
>
>   i[]   string2array {{ ....}}
>   k[]   string2array {{ ....}}
>
> which does much the same for a string except no comment skipping
>
> The name of the second is not good so I would be happy with a new
> name.  the fillarray has been tested and seems correct.  string2array
> only lightly tested as of now.
>
> While doing this processing  removed some restrictions on 1 and 2D
> only arrays and some better checking.
>
> Please try and give feedback
>
> ==John ffitch

Apologies -- my stupidity on a ae change.  OK in github


On Tue, 8 Jan 2019, joachim heintz wrote:

> first test shows for me that there is one extra zero for each dimension of 
> the array.  so for this code (the txt file is attached)
>
> giSnippets[] fillarray "snippets_lines.txt"
> printarray giSnippets
>
> i get one extra zero at the beginning
>  0: 0.0000 1.0000 0.6970 3.8500 66.2000 -38.8000 0.7700 2.0000 2.1250 3.8400 
> 89.4300
>  10: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600 -31.3000 0.7500 4.0000 
> 2.5430 etc
>
> wheras for
> giSnippets[][] init 765, 6
> giSnippets fillarray "snippets_lines.txt"
> printarray giSnippets
>
> i get two extra zeros at the beginning:
>   0: 0.0000 0.0000 1.0000 0.6970 3.8500 66.2000
>   1: -38.8000 0.7700 2.0000 2.1250 3.8400 89.4300
>   2: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600
>
> otherwise, the content looks ok.
>
> when i put all my text in the string2array opcode, it seems to struggle with 
> the length of the string, but with no obvious result.  i can interrupt, but 
> it does not seem to be able to load such long strings.
>
> best -
> 	joachim
>
>
>
>
>
> On 08/01/19 16:34, John wrote:
>> Removing the restriction would involve major changes essentially to
>> every opcode, or at least that is the only way I can see to do it.
>> 
>> So the current state in github is that there is a new variant of
>> fillarray
>>
>>   i[]   fillarray  "file_name"
>>   k[]   fillarray  "file_name"
>> 
>> where  the file is a list of numbers, space or comma separated and
>> dealing in a limited way with comments starting with ; or # until eol.
>> This is the same as gen23
>> 
>> There is also
>>
>>   i[]   string2array {{ ....}}
>>   k[]   string2array {{ ....}}
>> 
>> which does much the same for a string except no comment skipping
>> 
>> The name of the second is not good so I would be happy with a new
>> name.  the fillarray has been tested and seems correct.  string2array
>> only lightly tested as of now.
>> 
>> While doing this processing  removed some restrictions on 1 and 2D
>> only arrays and some better checking.
>> 
>> Please try and give feedback
>> 
>> ==John ffitch
>> 

thanks!  the file reading works now, also for 2 dimensions.

i cannot get any success for the string2array version.  certainly, the 
string input for my example is 767 x 6 fields; but should it not work 
anyway?

	joachim



On 09/01/19 15:56, jpff wrote:
> Apologies -- my stupidity on a ae change.  OK in github
>
>
> On Tue, 8 Jan 2019, joachim heintz wrote:
>
>> first test shows for me that there is one extra zero for each
>> dimension of the array.  so for this code (the txt file is attached)
>>
>> giSnippets[] fillarray "snippets_lines.txt"
>> printarray giSnippets
>>
>> i get one extra zero at the beginning
>>  0: 0.0000 1.0000 0.6970 3.8500 66.2000 -38.8000 0.7700 2.0000 2.1250
>> 3.8400 89.4300
>>  10: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600 -31.3000 0.7500
>> 4.0000 2.5430 etc
>>
>> wheras for
>> giSnippets[][] init 765, 6
>> giSnippets fillarray "snippets_lines.txt"
>> printarray giSnippets
>>
>> i get two extra zeros at the beginning:
>>   0: 0.0000 0.0000 1.0000 0.6970 3.8500 66.2000
>>   1: -38.8000 0.7700 2.0000 2.1250 3.8400 89.4300
>>   2: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600
>>
>> otherwise, the content looks ok.
>>
>> when i put all my text in the string2array opcode, it seems to
>> struggle with the length of the string, but with no obvious result.  i
>> can interrupt, but it does not seem to be able to load such long strings.
>>
>> best -
>>     joachim
>>
>>
>>
>>
>>
>> On 08/01/19 16:34, John wrote:
>>> Removing the restriction would involve major changes essentially to
>>> every opcode, or at least that is the only way I can see to do it.
>>>
>>> So the current state in github is that there is a new variant of
>>> fillarray
>>>
>>>   i[]   fillarray  "file_name"
>>>   k[]   fillarray  "file_name"
>>>
>>> where  the file is a list of numbers, space or comma separated and
>>> dealing in a limited way with comments starting with ; or # until eol.
>>> This is the same as gen23
>>>
>>> There is also
>>>
>>>   i[]   string2array {{ ....}}
>>>   k[]   string2array {{ ....}}
>>>
>>> which does much the same for a string except no comment skipping
>>>
>>> The name of the second is not good so I would be happy with a new
>>> name.  the fillarray has been tested and seems correct.  string2array
>>> only lightly tested as of now.
>>>
>>> While doing this processing  removed some restrictions on 1 and 2D
>>> only arrays and some better checking.
>>>
>>> Please try and give feedback
>>>
>>> ==John ffitch
>>>
>>