Re: Nasty filter bug

[Brian Milby via use-livecode]

It seems that an unmatched opening bracket makes it completely fail.  My
guess is that the filter string is not valid so it doesn't even try.  I
couldn't get a filter string containing a "[" to match anything.

On Wed, Jan 24, 2024 at 5:23 PM Craig Newman via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Brian.
>
> So the inclusion of “[“ would have matched nothing in the original string
> ""aaa[bbb””? That is, even though the bracketed string was not “closed”
> with “]”, did it try to find a string that began with “b”, failed, and
> therefore returned the original string untouched?
>
> Craig
>
> > On Jan 24, 2024, at 4:37 PM, Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I just want to clarify that this isn’t the regex version of filter but
> the wildcard pattern version.  It is much less complicated than regex.
> Square brackets are used to group characters to be matched so you can use
> [abc]* to match any item that starts with a, b, or c.  The dictionary entry
> for this is pretty good.
> >
> > Brian Milby
> > br...@milby7.com 
> >
> >> On Jan 24, 2024, at 3:35 PM, Craig Newman via use-livecode <
> use-livecode@lists.runrev.com >
> wrote:
> >>
> >> Brian.
> >>
> >> The original post tried to filter a string by filtering (without) that
> actual string, and was interested in why that did not yield empty.
> Intuitively, the result of such a filter operation ought always to be
> empty. The presence of the char “[“ is the “culprit”. That is as far as I
> took it.
> >>
> >> Anyway, you state that the char “[“ is a regex special character, which
> explains a lot. The other two, “?” and “*” filter without issue, though,
> and I guess one has to be a regex user to see why.
> >>
> >> I am not.
> >>
> >> Craig
> >>
> >>> On Jan 24, 2024, at 2:53 PM, Brian Milby via use-livecode <
> use-livecode@lists.runrev.com >
> wrote:
> >>>
> >>> Your test misses the actual issue:
> >>>
> >>> on mouseup
> >>> local tStr
> >>> local tFilter
> >>> put "a*b" into tFilter
> >>> put "anything bold" into tStr
> >>> filter tStr with tFilter
> >>> put tStr
> >>> end mouseup
> >>>
> >>> Will yield "anything bold"
> >>>
> >>> while using the following 2 lines:
> >>> put "a?b" into tFilter
> >>> put "a*b" into tStr
> >>> will yield "a*b"
> >>>
> >>> Finally, using the following 2 lines:
> >>> put "a[?]b" into tFilter
> >>> put "a?b" into tStr
> >>> will  yield "a?b"
> >>>
> >>> The point is that you can end up with issues if you are counting on
> "*" and
> >>> "?" to filter literally.  They don't - they are wildcards and can match
> >>> anything (multiple char or single char respectively).  The "[" is also
> >>> special.
> >>>
> >>> To ensure that your filters work properly if you do not want to use any
> >>> wildcards (i.e. match * and ? literally) would require you to change
> *, ?,
> >>> and [ to [*], [?], and [[].
> >>>
>  On Wed, Jan 24, 2024 at 1:19 PM Craig Newman via use-livecode <
>  use-livecode@lists.runrev.com >
> wrote:
> 
>  OK, instead of working I did this:
> 
>  on mouseUp
> 
>  repeat with y = 1 to 255
> 
>  put "XX" & numToChar(y) & "XX"  into temp
> 
>  filter temp without temp
> 
>  if temp <> "" then put y & return after accum
> 
>  end repeat
> 
>  answer accum
> 
>  end mouseUp
> 
>  There are two characters that prevent the filter command from doing
> its
>  job: ASCII 91 (“[“) and ASCII 10, the return char.
> 
> 
> 
>  Craig
> 
> 
> > On Jan 24, 2024, at 12:51 PM, Craig Newman via use-livecode <
>  use-livecode@lists.runrev.com >
> wrote:
> >
> > Brian.
> >
> > Nope. Those two chars pass through the filter, er, filtered.
> >
> > Again, I did not test the entire character set.
> >
> > Craig
> >
> >> On Jan 24, 2024, at 11:05 AM, Brian Milby via use-livecode <
>  use-livecode@lists.runrev.com> wrote:
> >>
> >> The only other two that would cause issues are ? and * which are
> single
>  and multiple char wildcards respectively.
> >>
> >> Brian Milby
> >> br...@milby7.com
> >>
> >>> On Jan 24, 2024, at 10:21 AM, Craig Newman via use-livecode <
>  use-livecode@lists.runrev.com> wrote:
> >>>
> >>> I did not test the ASCII set exhaustively, but the culprit is the
>  char “[“ (ASCII 91). Any other char (including “]”) in the string
> works
>  correctly, that is, nothing is left after the filter command executes.
> >>>
> >>> I do not know enough to say whether that particular char  does
>  something to the filter command, which may use regex somehow in its
> inner
>  workings.
> >>>
> >>> Craig
> >>>
> >>> Craig
> >>>
>  On Jan 23, 2024, at 

Re: Nasty filter bug

[Craig Newman via use-livecode]

Brian.

So the inclusion of “[“ would have matched nothing in the original string 
""aaa[bbb””? That is, even though the bracketed string was not “closed” with 
“]”, did it try to find a string that began with “b”, failed, and therefore 
returned the original string untouched?

Craig

> On Jan 24, 2024, at 4:37 PM, Brian Milby via use-livecode 
>  wrote:
> 
> I just want to clarify that this isn’t the regex version of filter but the 
> wildcard pattern version.  It is much less complicated than regex.  Square 
> brackets are used to group characters to be matched so you can use [abc]* to 
> match any item that starts with a, b, or c.  The dictionary entry for this is 
> pretty good.
> 
> Brian Milby
> br...@milby7.com 
> 
>> On Jan 24, 2024, at 3:35 PM, Craig Newman via use-livecode 
>> mailto:use-livecode@lists.runrev.com>> wrote:
>> 
>> Brian.
>> 
>> The original post tried to filter a string by filtering (without) that 
>> actual string, and was interested in why that did not yield empty. 
>> Intuitively, the result of such a filter operation ought always to be empty. 
>> The presence of the char “[“ is the “culprit”. That is as far as I took it.
>> 
>> Anyway, you state that the char “[“ is a regex special character, which 
>> explains a lot. The other two, “?” and “*” filter without issue, though, and 
>> I guess one has to be a regex user to see why.
>> 
>> I am not.
>> 
>> Craig
>> 
>>> On Jan 24, 2024, at 2:53 PM, Brian Milby via use-livecode 
>>> mailto:use-livecode@lists.runrev.com>> 
>>> wrote:
>>> 
>>> Your test misses the actual issue:
>>> 
>>> on mouseup
>>> local tStr
>>> local tFilter
>>> put "a*b" into tFilter
>>> put "anything bold" into tStr
>>> filter tStr with tFilter
>>> put tStr
>>> end mouseup
>>> 
>>> Will yield "anything bold"
>>> 
>>> while using the following 2 lines:
>>> put "a?b" into tFilter
>>> put "a*b" into tStr
>>> will yield "a*b"
>>> 
>>> Finally, using the following 2 lines:
>>> put "a[?]b" into tFilter
>>> put "a?b" into tStr
>>> will  yield "a?b"
>>> 
>>> The point is that you can end up with issues if you are counting on "*" and
>>> "?" to filter literally.  They don't - they are wildcards and can match
>>> anything (multiple char or single char respectively).  The "[" is also
>>> special.
>>> 
>>> To ensure that your filters work properly if you do not want to use any
>>> wildcards (i.e. match * and ? literally) would require you to change *, ?,
>>> and [ to [*], [?], and [[].
>>> 
 On Wed, Jan 24, 2024 at 1:19 PM Craig Newman via use-livecode <
 use-livecode@lists.runrev.com > 
 wrote:
 
 OK, instead of working I did this:
 
 on mouseUp
 
 repeat with y = 1 to 255
 
 put "XX" & numToChar(y) & "XX"  into temp
 
 filter temp without temp
 
 if temp <> "" then put y & return after accum
 
 end repeat
 
 answer accum
 
 end mouseUp
 
 There are two characters that prevent the filter command from doing its
 job: ASCII 91 (“[“) and ASCII 10, the return char.
 
 
 
 Craig
 
 
> On Jan 24, 2024, at 12:51 PM, Craig Newman via use-livecode <
 use-livecode@lists.runrev.com > 
 wrote:
> 
> Brian.
> 
> Nope. Those two chars pass through the filter, er, filtered.
> 
> Again, I did not test the entire character set.
> 
> Craig
> 
>> On Jan 24, 2024, at 11:05 AM, Brian Milby via use-livecode <
 use-livecode@lists.runrev.com> wrote:
>> 
>> The only other two that would cause issues are ? and * which are single
 and multiple char wildcards respectively.
>> 
>> Brian Milby
>> br...@milby7.com
>> 
>>> On Jan 24, 2024, at 10:21 AM, Craig Newman via use-livecode <
 use-livecode@lists.runrev.com> wrote:
>>> 
>>> I did not test the ASCII set exhaustively, but the culprit is the
 char “[“ (ASCII 91). Any other char (including “]”) in the string works
 correctly, that is, nothing is left after the filter command executes.
>>> 
>>> I do not know enough to say whether that particular char  does
 something to the filter command, which may use regex somehow in its inner
 workings.
>>> 
>>> Craig
>>> 
>>> Craig
>>> 
 On Jan 23, 2024, at 9:45 PM, Brian Milby via use-livecode <
 use-livecode@lists.runrev.com> wrote:
 
 Not sure this is really a bug.  The default is to match a
 wildcardPattern.  If you want to match [ then you must use [[] in the
 pattern.
 
 Brian Milby
 br...@milby7.com
 
>> On Jan 23, 2024, at 9:02 PM, Neville Smythe via use-livecode <
 use-livecode@lists.runrev.com> wrote:
> 
> Try this in the msg box:
> 
> put "aaa[bbb" into tStr; put line 1 of tStr into tLine; filter tStr
 without tLine; put tStr

Re: Nasty filter bug

[Brian Milby via use-livecode]

I just want to clarify that this isn’t the regex version of filter but the 
wildcard pattern version.  It is much less complicated than regex.  Square 
brackets are used to group characters to be matched so you can use [abc]* to 
match any item that starts with a, b, or c.  The dictionary entry for this is 
pretty good.

Brian Milby
br...@milby7.com

> On Jan 24, 2024, at 3:35 PM, Craig Newman via use-livecode 
>  wrote:
> 
> Brian.
> 
> The original post tried to filter a string by filtering (without) that actual 
> string, and was interested in why that did not yield empty. Intuitively, the 
> result of such a filter operation ought always to be empty. The presence of 
> the char “[“ is the “culprit”. That is as far as I took it.
> 
> Anyway, you state that the char “[“ is a regex special character, which 
> explains a lot. The other two, “?” and “*” filter without issue, though, and 
> I guess one has to be a regex user to see why.
> 
> I am not.
> 
> Craig
> 
>> On Jan 24, 2024, at 2:53 PM, Brian Milby via use-livecode 
>>  wrote:
>> 
>> Your test misses the actual issue:
>> 
>> on mouseup
>>  local tStr
>>  local tFilter
>>  put "a*b" into tFilter
>>  put "anything bold" into tStr
>>  filter tStr with tFilter
>>  put tStr
>> end mouseup
>> 
>> Will yield "anything bold"
>> 
>> while using the following 2 lines:
>>  put "a?b" into tFilter
>>  put "a*b" into tStr
>> will yield "a*b"
>> 
>> Finally, using the following 2 lines:
>>  put "a[?]b" into tFilter
>>  put "a?b" into tStr
>> will  yield "a?b"
>> 
>> The point is that you can end up with issues if you are counting on "*" and
>> "?" to filter literally.  They don't - they are wildcards and can match
>> anything (multiple char or single char respectively).  The "[" is also
>> special.
>> 
>> To ensure that your filters work properly if you do not want to use any
>> wildcards (i.e. match * and ? literally) would require you to change *, ?,
>> and [ to [*], [?], and [[].
>> 
>>> On Wed, Jan 24, 2024 at 1:19 PM Craig Newman via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> OK, instead of working I did this:
>>> 
>>> on mouseUp
>>> 
>>> repeat with y = 1 to 255
>>> 
>>> put "XX" & numToChar(y) & "XX"  into temp
>>> 
>>> filter temp without temp
>>> 
>>> if temp <> "" then put y & return after accum
>>> 
>>> end repeat
>>> 
>>> answer accum
>>> 
>>> end mouseUp
>>> 
>>> There are two characters that prevent the filter command from doing its
>>> job: ASCII 91 (“[“) and ASCII 10, the return char.
>>> 
>>> 
>>> 
>>> Craig
>>> 
>>> 
 On Jan 24, 2024, at 12:51 PM, Craig Newman via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
 
 Brian.
 
 Nope. Those two chars pass through the filter, er, filtered.
 
 Again, I did not test the entire character set.
 
 Craig
 
> On Jan 24, 2024, at 11:05 AM, Brian Milby via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
> 
> The only other two that would cause issues are ? and * which are single
>>> and multiple char wildcards respectively.
> 
> Brian Milby
> br...@milby7.com
> 
>> On Jan 24, 2024, at 10:21 AM, Craig Newman via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>> 
>> I did not test the ASCII set exhaustively, but the culprit is the
>>> char “[“ (ASCII 91). Any other char (including “]”) in the string works
>>> correctly, that is, nothing is left after the filter command executes.
>> 
>> I do not know enough to say whether that particular char  does
>>> something to the filter command, which may use regex somehow in its inner
>>> workings.
>> 
>> Craig
>> 
>> Craig
>> 
>>> On Jan 23, 2024, at 9:45 PM, Brian Milby via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> Not sure this is really a bug.  The default is to match a
>>> wildcardPattern.  If you want to match [ then you must use [[] in the
>>> pattern.
>>> 
>>> Brian Milby
>>> br...@milby7.com
>>> 
> On Jan 23, 2024, at 9:02 PM, Neville Smythe via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
 
 Try this in the msg box:
 
 put "aaa[bbb" into tStr; put line 1 of tStr into tLine; filter tStr
>>> without tLine; put tStr
 I get (using MacOS, LC 9.6.11)
 
 aaa[bbb
 
 That is to say, the line is not filtered out.
 
 And:
 
 put "aaa[bbb" into tStr; filter tStr with tStr; put tStr
 
 produces an empty string instead of the original string.
 
 The bug occurs if the line contains the character “[“ anywhere; any
>>> lines containing that character are ignored by both filter with and filter
>>> without.
 
 This is really serious, because I rely on the filter command a lot,
>>> as I would think do many other developers!
 
 Don’t know if it occurs with other characters, but I have 

Re: Nasty filter bug (not)

[Neville Smythe via use-livecode]

Thanks Brian of putting me right (once again) . I had completely forgotten.the 
escape sequence for the wildcards is [*] and [? (an unexpected way to escape a 
character, but it is what it is) and so had overlooked that [ is itself a 
special character.

And neither * nor ? In the msg box example cause the so-called “bug” but for 
accidental reasons since they happen to match themselves, so they didn’t 
trigger my memory to look further for an explanation!

Neville Smythe




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Nasty filter bug

[Craig Newman via use-livecode]

Brian.

The original post tried to filter a string by filtering (without) that actual 
string, and was interested in why that did not yield empty. Intuitively, the 
result of such a filter operation ought always to be empty. The presence of the 
char “[“ is the “culprit”. That is as far as I took it.

Anyway, you state that the char “[“ is a regex special character, which 
explains a lot. The other two, “?” and “*” filter without issue, though, and I 
guess one has to be a regex user to see why.

I am not.

Craig

> On Jan 24, 2024, at 2:53 PM, Brian Milby via use-livecode 
>  wrote:
> 
> Your test misses the actual issue:
> 
> on mouseup
>   local tStr
>   local tFilter
>   put "a*b" into tFilter
>   put "anything bold" into tStr
>   filter tStr with tFilter
>   put tStr
> end mouseup
> 
> Will yield "anything bold"
> 
> while using the following 2 lines:
>   put "a?b" into tFilter
>   put "a*b" into tStr
> will yield "a*b"
> 
> Finally, using the following 2 lines:
>   put "a[?]b" into tFilter
>   put "a?b" into tStr
> will  yield "a?b"
> 
> The point is that you can end up with issues if you are counting on "*" and
> "?" to filter literally.  They don't - they are wildcards and can match
> anything (multiple char or single char respectively).  The "[" is also
> special.
> 
> To ensure that your filters work properly if you do not want to use any
> wildcards (i.e. match * and ? literally) would require you to change *, ?,
> and [ to [*], [?], and [[].
> 
> On Wed, Jan 24, 2024 at 1:19 PM Craig Newman via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> OK, instead of working I did this:
>> 
>> on mouseUp
>> 
>> repeat with y = 1 to 255
>> 
>> put "XX" & numToChar(y) & "XX"  into temp
>> 
>> filter temp without temp
>> 
>> if temp <> "" then put y & return after accum
>> 
>> end repeat
>> 
>> answer accum
>> 
>> end mouseUp
>> 
>> There are two characters that prevent the filter command from doing its
>> job: ASCII 91 (“[“) and ASCII 10, the return char.
>> 
>> 
>> 
>> Craig
>> 
>> 
>>> On Jan 24, 2024, at 12:51 PM, Craig Newman via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> Brian.
>>> 
>>> Nope. Those two chars pass through the filter, er, filtered.
>>> 
>>> Again, I did not test the entire character set.
>>> 
>>> Craig
>>> 
 On Jan 24, 2024, at 11:05 AM, Brian Milby via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
 
 The only other two that would cause issues are ? and * which are single
>> and multiple char wildcards respectively.
 
 Brian Milby
 br...@milby7.com
 
> On Jan 24, 2024, at 10:21 AM, Craig Newman via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
> 
> I did not test the ASCII set exhaustively, but the culprit is the
>> char “[“ (ASCII 91). Any other char (including “]”) in the string works
>> correctly, that is, nothing is left after the filter command executes.
> 
> I do not know enough to say whether that particular char  does
>> something to the filter command, which may use regex somehow in its inner
>> workings.
> 
> Craig
> 
> Craig
> 
>> On Jan 23, 2024, at 9:45 PM, Brian Milby via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>> Not sure this is really a bug.  The default is to match a
>> wildcardPattern.  If you want to match [ then you must use [[] in the
>> pattern.
>> 
>> Brian Milby
>> br...@milby7.com
>> 
 On Jan 23, 2024, at 9:02 PM, Neville Smythe via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> Try this in the msg box:
>>> 
>>> put "aaa[bbb" into tStr; put line 1 of tStr into tLine; filter tStr
>> without tLine; put tStr
>>> I get (using MacOS, LC 9.6.11)
>>> 
>>> aaa[bbb
>>> 
>>> That is to say, the line is not filtered out.
>>> 
>>> And:
>>> 
>>> put "aaa[bbb" into tStr; filter tStr with tStr; put tStr
>>> 
>>> produces an empty string instead of the original string.
>>> 
>>> The bug occurs if the line contains the character “[“ anywhere; any
>> lines containing that character are ignored by both filter with and filter
>> without.
>>> 
>>> This is really serious, because I rely on the filter command a lot,
>> as I would think do many other developers!
>>> 
>>> Don’t know if it occurs with other characters, but I have never seen
>> it before. I discovered it when filtering lines with regular expressions.
>> Other special regexp characters I have tested do not trigger the bug.
>>> 
>>> Neville Smythe
>>> 
>>> 
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> ___
>> 

Re: Nasty filter bug

[Brian Milby via use-livecode]

Your test misses the actual issue:

on mouseup
   local tStr
   local tFilter
   put "a*b" into tFilter
   put "anything bold" into tStr
   filter tStr with tFilter
   put tStr
end mouseup

Will yield "anything bold"

while using the following 2 lines:
   put "a?b" into tFilter
   put "a*b" into tStr
will yield "a*b"

Finally, using the following 2 lines:
   put "a[?]b" into tFilter
   put "a?b" into tStr
will  yield "a?b"

The point is that you can end up with issues if you are counting on "*" and
"?" to filter literally.  They don't - they are wildcards and can match
anything (multiple char or single char respectively).  The "[" is also
special.

To ensure that your filters work properly if you do not want to use any
wildcards (i.e. match * and ? literally) would require you to change *, ?,
and [ to [*], [?], and [[].

On Wed, Jan 24, 2024 at 1:19 PM Craig Newman via use-livecode <
use-livecode@lists.runrev.com> wrote:

> OK, instead of working I did this:
>
> on mouseUp
>
> repeat with y = 1 to 255
>
> put "XX" & numToChar(y) & "XX"  into temp
>
> filter temp without temp
>
> if temp <> "" then put y & return after accum
>
> end repeat
>
> answer accum
>
> end mouseUp
>
> There are two characters that prevent the filter command from doing its
> job: ASCII 91 (“[“) and ASCII 10, the return char.
>
>
>
> Craig
>
>
> > On Jan 24, 2024, at 12:51 PM, Craig Newman via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Brian.
> >
> > Nope. Those two chars pass through the filter, er, filtered.
> >
> > Again, I did not test the entire character set.
> >
> > Craig
> >
> >> On Jan 24, 2024, at 11:05 AM, Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> The only other two that would cause issues are ? and * which are single
> and multiple char wildcards respectively.
> >>
> >> Brian Milby
> >> br...@milby7.com
> >>
> >>> On Jan 24, 2024, at 10:21 AM, Craig Newman via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>>
> >>> I did not test the ASCII set exhaustively, but the culprit is the
> char “[“ (ASCII 91). Any other char (including “]”) in the string works
> correctly, that is, nothing is left after the filter command executes.
> >>>
> >>> I do not know enough to say whether that particular char  does
> something to the filter command, which may use regex somehow in its inner
> workings.
> >>>
> >>> Craig
> >>>
> >>> Craig
> >>>
>  On Jan 23, 2024, at 9:45 PM, Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>  Not sure this is really a bug.  The default is to match a
> wildcardPattern.  If you want to match [ then you must use [[] in the
> pattern.
> 
>  Brian Milby
>  br...@milby7.com
> 
> >> On Jan 23, 2024, at 9:02 PM, Neville Smythe via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Try this in the msg box:
> >
> > put "aaa[bbb" into tStr; put line 1 of tStr into tLine; filter tStr
> without tLine; put tStr
> > I get (using MacOS, LC 9.6.11)
> >
> > aaa[bbb
> >
> > That is to say, the line is not filtered out.
> >
> > And:
> >
> > put "aaa[bbb" into tStr; filter tStr with tStr; put tStr
> >
> > produces an empty string instead of the original string.
> >
> > The bug occurs if the line contains the character “[“ anywhere; any
> lines containing that character are ignored by both filter with and filter
> without.
> >
> > This is really serious, because I rely on the filter command a lot,
> as I would think do many other developers!
> >
> > Don’t know if it occurs with other characters, but I have never seen
> it before. I discovered it when filtering lines with regular expressions.
> Other special regexp characters I have tested do not trigger the bug.
> >
> > Neville Smythe
> >
> >
> >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> 
>  ___
>  use-livecode mailing list
>  use-livecode@lists.runrev.com
>  Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
>  http://lists.runrev.com/mailman/listinfo/use-livecode
> >>>
> >>>
> >>> ___
> >>> use-livecode mailing list
> >>> use-livecode@lists.runrev.com
> >>> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >>> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >> ___
> >> use-livecode mailing list
> >> use-livecode@lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >> 

Re: Nasty filter bug

[Craig Newman via use-livecode]

OK, instead of working I did this:

on mouseUp

repeat with y = 1 to 255

put "XX" & numToChar(y) & "XX"  into temp

filter temp without temp

if temp <> "" then put y & return after accum

end repeat

answer accum

end mouseUp

There are two characters that prevent the filter command from doing its job: 
ASCII 91 (“[“) and ASCII 10, the return char.



Craig


> On Jan 24, 2024, at 12:51 PM, Craig Newman via use-livecode 
>  wrote:
> 
> Brian.
> 
> Nope. Those two chars pass through the filter, er, filtered.
> 
> Again, I did not test the entire character set.
> 
> Craig
> 
>> On Jan 24, 2024, at 11:05 AM, Brian Milby via use-livecode 
>>  wrote:
>> 
>> The only other two that would cause issues are ? and * which are single and 
>> multiple char wildcards respectively.
>> 
>> Brian Milby
>> br...@milby7.com
>> 
>>> On Jan 24, 2024, at 10:21 AM, Craig Newman via use-livecode 
>>>  wrote:
>>> 
>>> I did not test the ASCII set exhaustively, but the culprit is the char “[“ 
>>> (ASCII 91). Any other char (including “]”) in the string works correctly, 
>>> that is, nothing is left after the filter command executes.
>>> 
>>> I do not know enough to say whether that particular char  does something to 
>>> the filter command, which may use regex somehow in its inner workings.
>>> 
>>> Craig
>>> 
>>> Craig
>>> 
 On Jan 23, 2024, at 9:45 PM, Brian Milby via use-livecode 
  wrote:
 
 Not sure this is really a bug.  The default is to match a wildcardPattern. 
  If you want to match [ then you must use [[] in the pattern.
 
 Brian Milby
 br...@milby7.com
 
>> On Jan 23, 2024, at 9:02 PM, Neville Smythe via use-livecode 
>>  wrote:
> 
> Try this in the msg box:
> 
> put "aaa[bbb" into tStr; put line 1 of tStr into tLine; filter tStr 
> without tLine; put tStr
> I get (using MacOS, LC 9.6.11)
> 
> aaa[bbb
> 
> That is to say, the line is not filtered out.
> 
> And:
> 
> put "aaa[bbb" into tStr; filter tStr with tStr; put tStr
> 
> produces an empty string instead of the original string.
> 
> The bug occurs if the line contains the character “[“ anywhere; any lines 
> containing that character are ignored by both filter with and filter 
> without.
> 
> This is really serious, because I rely on the filter command a lot, as I 
> would think do many other developers!
> 
> Don’t know if it occurs with other characters, but I have never seen it 
> before. I discovered it when filtering lines with regular expressions. 
> Other special regexp characters I have tested do not trigger the bug.
> 
> Neville Smythe
> 
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your 
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Nasty filter bug

[Craig Newman via use-livecode]

Brian.

Nope. Those two chars pass through the filter, er, filtered.

Again, I did not test the entire character set.

Craig

> On Jan 24, 2024, at 11:05 AM, Brian Milby via use-livecode 
>  wrote:
> 
> The only other two that would cause issues are ? and * which are single and 
> multiple char wildcards respectively.
> 
> Brian Milby
> br...@milby7.com
> 
>> On Jan 24, 2024, at 10:21 AM, Craig Newman via use-livecode 
>>  wrote:
>> 
>> I did not test the ASCII set exhaustively, but the culprit is the char “[“ 
>> (ASCII 91). Any other char (including “]”) in the string works correctly, 
>> that is, nothing is left after the filter command executes.
>> 
>> I do not know enough to say whether that particular char  does something to 
>> the filter command, which may use regex somehow in its inner workings.
>> 
>> Craig
>> 
>> Craig
>> 
>>> On Jan 23, 2024, at 9:45 PM, Brian Milby via use-livecode 
>>>  wrote:
>>> 
>>> Not sure this is really a bug.  The default is to match a wildcardPattern.  
>>> If you want to match [ then you must use [[] in the pattern.
>>> 
>>> Brian Milby
>>> br...@milby7.com
>>> 
> On Jan 23, 2024, at 9:02 PM, Neville Smythe via use-livecode 
>  wrote:
 
 Try this in the msg box:
 
 put "aaa[bbb" into tStr; put line 1 of tStr into tLine; filter tStr 
 without tLine; put tStr
 I get (using MacOS, LC 9.6.11)
 
 aaa[bbb
 
 That is to say, the line is not filtered out.
 
 And:
 
 put "aaa[bbb" into tStr; filter tStr with tStr; put tStr
 
 produces an empty string instead of the original string.
 
 The bug occurs if the line contains the character “[“ anywhere; any lines 
 containing that character are ignored by both filter with and filter 
 without.
 
 This is really serious, because I rely on the filter command a lot, as I 
 would think do many other developers!
 
 Don’t know if it occurs with other characters, but I have never seen it 
 before. I discovered it when filtering lines with regular expressions. 
 Other special regexp characters I have tested do not trigger the bug.
 
 Neville Smythe
 
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your 
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Nasty filter bug

[Brian Milby via use-livecode]

The only other two that would cause issues are ? and * which are single and 
multiple char wildcards respectively.

Brian Milby
br...@milby7.com

> On Jan 24, 2024, at 10:21 AM, Craig Newman via use-livecode 
>  wrote:
> 
> I did not test the ASCII set exhaustively, but the culprit is the char “[“ 
> (ASCII 91). Any other char (including “]”) in the string works correctly, 
> that is, nothing is left after the filter command executes.
> 
> I do not know enough to say whether that particular char  does something to 
> the filter command, which may use regex somehow in its inner workings.
> 
> Craig
> 
> Craig
> 
>> On Jan 23, 2024, at 9:45 PM, Brian Milby via use-livecode 
>>  wrote:
>> 
>> Not sure this is really a bug.  The default is to match a wildcardPattern.  
>> If you want to match [ then you must use [[] in the pattern.
>> 
>> Brian Milby
>> br...@milby7.com
>> 
 On Jan 23, 2024, at 9:02 PM, Neville Smythe via use-livecode 
  wrote:
>>> 
>>> Try this in the msg box:
>>> 
>>> put "aaa[bbb" into tStr; put line 1 of tStr into tLine; filter tStr without 
>>> tLine; put tStr
>>> I get (using MacOS, LC 9.6.11)
>>> 
>>> aaa[bbb
>>> 
>>> That is to say, the line is not filtered out.
>>> 
>>> And:
>>> 
>>> put "aaa[bbb" into tStr; filter tStr with tStr; put tStr
>>> 
>>> produces an empty string instead of the original string.
>>> 
>>> The bug occurs if the line contains the character “[“ anywhere; any lines 
>>> containing that character are ignored by both filter with and filter 
>>> without.
>>> 
>>> This is really serious, because I rely on the filter command a lot, as I 
>>> would think do many other developers!
>>> 
>>> Don’t know if it occurs with other characters, but I have never seen it 
>>> before. I discovered it when filtering lines with regular expressions. 
>>> Other special regexp characters I have tested do not trigger the bug.
>>> 
>>> Neville Smythe
>>> 
>>> 
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Nasty filter bug

[Craig Newman via use-livecode]

I did not test the ASCII set exhaustively, but the culprit is the char “[“ 
(ASCII 91). Any other char (including “]”) in the string works correctly, that 
is, nothing is left after the filter command executes.

I do not know enough to say whether that particular char  does something to the 
filter command, which may use regex somehow in its inner workings.

Craig

Craig

> On Jan 23, 2024, at 9:45 PM, Brian Milby via use-livecode 
>  wrote:
> 
> Not sure this is really a bug.  The default is to match a wildcardPattern.  
> If you want to match [ then you must use [[] in the pattern.
> 
> Brian Milby
> br...@milby7.com
> 
>> On Jan 23, 2024, at 9:02 PM, Neville Smythe via use-livecode 
>>  wrote:
>> 
>> Try this in the msg box:
>> 
>> put "aaa[bbb" into tStr; put line 1 of tStr into tLine; filter tStr without 
>> tLine; put tStr
>> I get (using MacOS, LC 9.6.11)
>> 
>> aaa[bbb
>> 
>> That is to say, the line is not filtered out.
>> 
>> And:
>> 
>> put "aaa[bbb" into tStr; filter tStr with tStr; put tStr
>> 
>> produces an empty string instead of the original string.
>> 
>> The bug occurs if the line contains the character “[“ anywhere; any lines 
>> containing that character are ignored by both filter with and filter without.
>> 
>> This is really serious, because I rely on the filter command a lot, as I 
>> would think do many other developers!
>> 
>> Don’t know if it occurs with other characters, but I have never seen it 
>> before. I discovered it when filtering lines with regular expressions. Other 
>> special regexp characters I have tested do not trigger the bug.
>> 
>> Neville Smythe
>> 
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: tsNetCustomUploadSync: what am I doing wrong? (Answer: RTFM-P)

[Ben Rubinstein via use-livecode]

For the record:

> put tsNetCustomUploadSync(tURL, "POST", tRequestData, tHeaders, ...

should have been

> put tsNetCustomUploadSync(tURL, "POST", tHeaders, tRequestData, ...

:facepalm-emoji:

Ben

On 22/01/2024 21:48, Ben Rubinstein via use-livecode wrote:

I'm trying to use tsNetCustomUploadSync, but something is going wrong.

To establish a baseline, I'm using it to do a POST request. I can prove that 
my data is good because this works:


   set the httpHeaders to tHeaders
   post tRequestData to URL tURL
   put it into fld "ResultData"
   put libUrlLastRhHeaders() into rOutHeaders

This, however:
   put tsNetCustomUploadSync(tURL, "POST", tRequestData, tHeaders, 
rOutHeaders, rResult, rBytes) into fld "ResultData"


returns an 'unauthorized' error, with message "Authentication required".

That suggests that either my URL (which contains part of the application ids 
to which my authorisation token is specific) or my headers (which contains the 
authorisation token) is not being passed correctly.


My guess is that it's more likely to be the headers. Can anyone advise?

TIA,

Ben

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Livecode Demo of two way javascript communication?

[David Bovill via use-livecode]

Is there a demo out there for simple bidirectional interaction between a
web page and a recent stack exported as wasm? Anyone experimenting with
this?
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Multipart form decode

[David Bovill via use-livecode]

Yes - I need a (standard) decoder. As far as I can tell we have a few
handlers in Livecode for encoding data for multipart form encoding - then
the Livecode server will do its magic and parse that making the rules
available - however there is no function to do the rfc7578
 decoding - at least that is
documented. We need this if we are coding our own server using the built in
sockets handling. I have a couple of hacks to extract uploaded images or
other files - but nothing robust or a general parser.

On Wed, 24 Jan 2024 at 02:51, Neville Smythe via use-livecode <
use-livecode@lists.runrev.com> wrote:

> David: do you need a special decoder?
>
> I thought the multipart form handlers just broke up the sent data into
> user-defined small chunks, and the server was responsible for waiting for
> all the parts to be received and then re-assembling the data. From that
> point it is just a normal POST.
>
> Maybe I have misunderstood the question?
>
>
> Neville Smythe
>
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode