1. problems with 4.0.3
- Posted by useless Oct 08, 2011
- 1203 views
I tried again to switch from euphoria 40b4-3412, which i have been using for some time now, to v4.0.3. I ran into two problems, one of which will stop me from ever using v4.0.3. And both problems have occured on two computers.
Problem one is when tracing a program using v4.0.3, i cannot F1/F2 to see the output of puts(1,"blarg"). Nothing happens when pressing any function keys. This puts a significant dent in tracing.
Problem two is remove_all() doesn't, on v40b4-3412 or on v4.0.3.
-- test the idiot remove_all() with trace include std\sequence.e object data trace(1) data = "<a href=\"?selectlang=ru\"><img>" puts(1,data&"\n") -- <a href="?selectlang=ru"><img> -- cannot F1 or F2 here, nothing happens, -- i cannot see the puts in 4.0.3 -- i CAN see the puts in 40b4-3412 data = remove_all("?selectlang=ru",data) puts(1,data&"\n") -- <a href="?selectlang=ru"><img> -- cannot F1 or F2 here, nothing happens, -- i cannot see the puts in 4.0.3 -- i CAN see the puts in 40b4-3412 -- but data still contains "?selectlang=ru" abort(0) -- something to end the trace on
But this works fine on both versions:
place1 = match("?selectlang=ru",data) while place1 do data = data[1..place1-1] & data[place1+14..$] place1 = match("?selectlang=ru",data) end while
What i want to end up with in the example above is:
data = "<a href=\""><img>"
useless
2. Re: problems with 4.0.3
- Posted by DerekParnell (admin) Oct 08, 2011
- 1171 views
... when tracing a program using v4.0.3, i cannot F1/F2 to see the output
This is a bug that occurs when Euphoria is built using MingW (GCC for Windows). I'm current working on a fix for this and it will probably be released very shortly. If you build Euphoria using Watcom, then this bug does not occur.
Problem two is remove_all() doesn't, on v40b4-3412 or on v4.0.3.
The purpose of remove_all is to remove all elements in the second parameter that equal the first parameter. To quote the manual ...
This function weeds elements out, not sub-sequences.
In the example you gave there is no single element in the second parameter that is equal to "?selectlang=ru.' Remember that a string is a sequence of integer elements (characters), so you can see that there is no character that matches the string "?selectlang=ru".
I'm a bit surprised that we don't have a function that does what you want but here is an example function that you can use for now.
include std/console.e public function remove_match(object needle, sequence haystack) integer found = 1 while found with entry do haystack = remove( haystack, found, found + length(needle) - 1 ) entry found = match( needle, haystack, found ) end while return haystack end function sequence data data = "<a href=\"?selectlang=ru\"><img>" display(data) data = remove_match("?selectlang=ru", data) display(data)
3. Re: problems with 4.0.3
- Posted by jimcbrown (admin) Oct 08, 2011
- 1265 views
This is a bug that occurs when Euphoria is built using MingW (GCC for Windows). I'm current working on a fix for this and it will probably be released very shortly. If you build Euphoria using Watcom, then this bug does not occur.
Looking at http://openeuphoria.org/forum/m/116090.wc message:116090 the binary build of 4.0.3 for W32 that was released - despite the fact that it was built with Watcom - had a known issue with keyboard handling.
You later said the same thing at http://openeuphoria.org/forum/m/116411.wc message:116411 which makes me suspect that you believe this is an occurance of the same bug.
Unless someone has updated the binary release of W32 4.0.3 since then, it's necessary to build Euphoria from the source code with Watcom to avoid this issue.
4. Re: problems with 4.0.3
- Posted by DerekParnell (admin) Oct 08, 2011
- 1150 views
Looking at http://openeuphoria.org/forum/m/116090.wc message:116090 the binary build of 4.0.3 for W32 that was released - despite the fact that it was built with Watcom - had a known issue with keyboard handling.
You later said the same thing at http://openeuphoria.org/forum/m/116411.wc message:116411 which makes me suspect that you believe this is an occurance of the same bug.
Hmmm... I could be wrong of course. All I'm going on is that when I build with Watcom the F1/F2 keys work and when built with GCC those keys doesn't work. Also, now that I've looked at the source code, I can see why GCC builds ignore certain keys. I've replaced the compiler-specific code for keyboard handling with direct calls to the Windows API and it works fine with GCC now. I'm just working on some backward compatibility issues now.
5. Re: problems with 4.0.3
- Posted by jimcbrown (admin) Oct 08, 2011
- 1135 views
I'm a bit surprised that we don't have a function that does what you want
public function remove_match(object needle, sequence haystack)
Wait, can't find_replace() / match_replace() do this?
6. Re: problems with 4.0.3
- Posted by mattlewis (admin) Oct 08, 2011
- 1090 views
Looking at http://openeuphoria.org/forum/m/116090.wc message:116090 the binary build of 4.0.3 for W32 that was released - despite the fact that it was built with Watcom - had a known issue with keyboard handling.
You later said the same thing at http://openeuphoria.org/forum/m/116411.wc message:116411 which makes me suspect that you believe this is an occurance of the same bug.
Hmmm... I could be wrong of course. All I'm going on is that when I build with Watcom the F1/F2 keys work and when built with GCC those keys doesn't work. Also, now that I've looked at the source code, I can see why GCC builds ignore certain keys. I've replaced the compiler-specific code for keyboard handling with direct calls to the Windows API and it works fine with GCC now. I'm just working on some backward compatibility issues now.
I just tried tracing some simple stuff on Linux. The result is a little strange. Basically, when I hit F1, it shows what I've printed, though it doesn't clear out the rest of the trace screen. Going back to tracing works like normal (though in 4.1, it stops tracing and just runs the rest of the program).
Matt
7. Re: problems with 4.0.3
- Posted by DerekParnell (admin) Oct 08, 2011
- 1117 views
Wait, can't find_replace() / match_replace() do this?
Oops ... so they can. I totally forgot about these. We need to improve the documentation cross references for similar functions.
Kat, this should work for you ...
include std/search.e data = match_replace("?selectlang=ru", data, "")
8. Re: problems with 4.0.3
- Posted by DerekParnell (admin) Oct 08, 2011
- 1196 views
Problem one is when tracing a program using v4.0.3, i cannot F1/F2 to see the output of puts(1,"blarg").
By the way, you can use the '1' and '2' keys instead of F1 and F2, also the 'j' key for DOWN_ARROW. Have a look at the top line of the trace display screen for this.
9. Re: problems with 4.0.3
- Posted by useless Oct 09, 2011
- 1055 views
... when tracing a program using v4.0.3, i cannot F1/F2 to see the output
This is a bug that occurs when Euphoria is built using MingW (GCC for Windows). I'm current working on a fix for this and it will probably be released very shortly. If you build Euphoria using Watcom, then this bug does not occur.
Problem two is remove_all() doesn't, on v40b4-3412 or on v4.0.3.
The purpose of remove_all is to remove all elements in the second parameter that equal the first parameter. To quote the manual ...
This function weeds elements out, not sub-sequences.
In the example you gave there is no single element in the second parameter that is equal to "?selectlang=ru.' Remember that a string is a sequence of integer elements (characters), so you can see that there is no character that matches the string "?selectlang=ru".
I was somewhat thrown off by the use of the word "element". While i know Euphoric atoms and sequences, i interpreted "element" as a collection of atoms like "blagtorf", as opposed to a collection of sequences like {"blag","torf"}.
I wonder if sub-naming functions for what they operate on would be handy. So replace_all_s() and replace_all_a(). I don't know. I do think it's shortsighted to lock in a function name to atoms or sequences, when it's an equally great name for the other. Since the implementation of the function calls everything an object, why not sprinkle a few if sequence(needle) or if atom(needle) and handling the values differently?
useless