Re: bug in char_test() ?
- Posted by useless_ Oct 15, 2012
- 1023 views
The code ran 100's of times before this crash, and nowhere did i redefine CS_Printable to be 6.
It should not have run at all.
Edit:
CS_Printable is enumerated as 6, it's set in
public procedure set_default_charsets()
but Defined_Sets isn't public, so i cannot call
if char_test(dataline,Defined_Sets[CS_Printable]) then
or
if char_test(dataline,types:Defined_Sets[CS_Printable]) then
So how do i make this work?
By appending all the various enumerated types by copy/pasting out of types.e until a text line passed as TRUE, i changed my source to:
if char_test(dataline,{{' ', '~'},{' ', '/'},{':', '?'},{'[', '`'},{'{', '~'},{' ', '~'}, " ", "\t\t", "\n\n", "\r\r", {8,8}, {7,7}})
It seems to me that you have a bit of redundancy there in your ranges. Several ranges have the same start, a few have the same ends, two are identical.
Yes, i know. I made every attempt to make the app work and no attempt to optomise it.
Programatically, you can use get_charsets() to get the various sets that are defined, and then you can put them together as required.
Matt
So not being able to use them by name directly is done on purpose? Why? Namespace pollution? I guess i missed the line in the manual about that. To me, get_charsets() seemed to be for modifying the charsets, and retrieving the charset(s) so i could send it(s) right back in char_test() didn't occur to me. I didn't see what was in each charset by reading http://openeuphoria.org/docs/std_types.html , i discovered them by accident when reading std/types.e.
useless
