r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[RAMBO] The REBOL bug and enhancement database

Geomol
1-Dec-2005
[1375x4]
Exactly!
Also works with thru:
>> parse "abcde" [to 2 mk: (print mk)]
bcde
== false
>> parse "abcde" [thru 2 mk: (print mk)]
cde
== false
Why do we write this under "RAMBO"? :-) It's not a bug!
Put it in the Wiki.
Chris
1-Dec-2005
[1379]
I think the original point is -- parse "" [to 5] -- perhaps should 
not return true.
Pekr
1-Dec-2005
[1380]
Chris - maybe it should, if you look at how skip "" 5 works. 'skip 
operation here is simply kind of doing "nothing" - trying to jump, 
but already at the end, so it jumps nowhere :-)
sqlab
1-Dec-2005
[1381]
Maybe my point is better explained with this example

 parse "12345" [to 6  copy a to 10 (print 1)]
1
== true

If  to 6 parses all positions, I do not expect that after the tail 
to 10 gives true
Volker
1-Dec-2005
[1382x2]
IMHO that is a bug. 
!> parse "123" [5 skip (print 1)]
== false
!> parse "123" [to 5 (print 1)]      
1
== true
skip makes more sense
Anton
2-Dec-2005
[1384x6]
[to 5] seems to be jumping off the end of the input.
event/key bugs with View 1.3.60 and 1.3.61
view layout [b: box feel [engage: func [face action event][if action 
= 'key [print event/key]]] do [focus b]]
(better make that PRINT a PROBE...)  My results when pressing various 
keys:
page-up -> "clipboard"
page-down -> "object"
home -> #"^@"
end -> "event"
insert -> "file"
etc... other keys are giving strange values too.
Anybody else see this ?
Doesn't seem to be reported in rambo anywhere.
Brett
2-Dec-2005
[1390x2]
>> parse {ab} [to {a} to {a} to {a} to {a} {b}]
== false
>> parse {ab} [to #"a" skip #"b"]
== true
>> parse {ab} [to #"a" to #"a" to #"a" skip #"b"]
== true
>> parse {ab} [to #"a" to #"a" to #"a" to #"a" skip #"b"]
== true
>> parse {12345} [to end to end to end to end]
== true
>> parse {12345} [to end to 6 to 10 to 100 to end]
== true
>> parse {123} [thru 4 (print 1)]
== false
>> parse {123} [to 5 skip]
== false
Thru seems closer semantics to skip. "To" seems to check before move 
and after move.  Which is wrong behaviour or expectations - I don't 
know.
Rebolek
2-Dec-2005
[1392]
Anton: It's same here. Function keys give strange results too. F1-console 
F2-listen F3-tcp F4-udp and so on.
Pekr
2-Dec-2005
[1393]
strange - then it seems like someone tried to do some experiments 
with either events or keyboard code, which can be a good sign of 
things to come :-)
Rebolek
2-Dec-2005
[1394]
things like what? :)
Anton
2-Dec-2005
[1395]
Strings in the rebol executable were changed to be stored differently. 
Maybe it has something to do with that.
Rebolek
2-Dec-2005
[1396]
You should RAMBO it
Pekr
2-Dec-2005
[1397]
things like key-up, ability to generate events, etc., simply things 
which were planned, don't yoy remember, Kru ;-)
Rebolek
2-Dec-2005
[1398]
I remember lot of things Pekr :)
Pekr
2-Dec-2005
[1399]
then you are good. I feel older and older, that I don't sometimes 
remember, what I wanted to remember :-)
Rebolek
2-Dec-2005
[1400]
It may be better not to remember everything that was promised :)
Anton
2-Dec-2005
[1401]
Ok, submitted to RAMBO.
Anton
3-Dec-2005
[1402x3]
I noticed Rebol/View 1.3.60 and 1.3.61 seem to have a problem making 
routine!s with a callback! arg in them. Anybody else ?
eg.
** Script Error: Invalid argument: callback!
** Near: setErrorHandler: make routine! [
    errorProc [callback! [string! integer! return: [int]]]
    return: [integer!]
] COMLib
The above routine has no problem being made in View 1.3.1.3.1
DideC
3-Dec-2005
[1405]
Cyphre has noticed that too.
Anton
4-Dec-2005
[1406x2]
Ah, just reading through rambo tickets, looks like this one is fixed 
already for View 1.3.2
:)
Gabriele
5-Dec-2005
[1408]
note that 1.3.2 is lesser than 1.3.61. ;) A lot of experimental code 
has been removed for the 1.3.2 release. They will be back in 1.4.
Rebolek
5-Dec-2005
[1409]
When can we expect 1.3.2 and when 1.4 ?
Gabriele
5-Dec-2005
[1410]
1.3.2 should be very soon. 1.4 i don't know.
Rebolek
5-Dec-2005
[1411]
So what can we expect from 1.3.2 ? Bugfixes? yes. Rebcode? no. Rebservices? 
don't know. Rich-text? probably no, as we haven't seen this in alphas. 
new datatypes? probably not. Something else? don't know.
Henrik
5-Dec-2005
[1412]
kru, probably what you see in RAMBO :-)
Rebolek
5-Dec-2005
[1413]
Henrik in RAMBO I can see only bugfixes, but no informations on what's 
going to be added (if anything will be added).
Henrik
5-Dec-2005
[1414]
rebservices would probably be considered a major change, so maybe 
that won't get in until 1.4.0
Rebolek
5-Dec-2005
[1415]
It would be great to know when can we expect 1.4.0 . In a month, 
two, half a year...I know that it's hard to predict release date, 
but give us some estimation, please :)
Gabriele
5-Dec-2005
[1416]
if i would, you'd then quote me on that. :P and anyway, only Carl 
could possibly tell you a date.
Rebolek
5-Dec-2005
[1417]
OK, I was just trying ;)
Anton
5-Dec-2005
[1418]
Ah no - temporal instability again :)
Volker
6-Dec-2005
[1419x3]
3896 Load {#[object! ...]} doesn't create global words as expected.

I thought that was a feature. My concern are tcp-daemons with open 
clients. The old way someoneId:	 cant overflow the word-table with 
garbage data. If data-words are added too, someone can.
Yuks, mouselcick to much..
3896 Load {#[object! ...]} doesn't create global words as expected.

I thought that was a feature. My concern are tcp-daemons with open 
clients. The old way someone cant overflow the word-table with garbage 
data. If data-words are added too, someone can.
Gabriele
7-Dec-2005
[1422]
not adding words to the global table leads to crashes, unless you're 
using them strictly as symbols (which is not the case if you are 
creating objects...)
Volker
7-Dec-2005
[1423x2]
Crashes or errors?
But yes, the words have to exist in case something in a block wants 
to bind to it. Or it gets complicated.