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

Carlos
29-Jun-2005
[821]
while I am posting this I notice the foreign characters under Linux 
is not yet solved. Using Debian Ubuntu with brazilian ABNT2 keyboard 
layout I am not able to input some usual characters in Portuguese 
such as Ža Že Ži Žo `u `a ^o ~a .
Izkata
29-Jun-2005
[822x2]
Not sure if it goes here.. but Rebol 1.3 doesn't seem to like the 
bit on a Draw animation in the cookbook: http://www.rebol.net/cookbook/recipes/0047.html
 (specifically, the adding and subtracting in the draw block...)
Nevermind, I haven't been paying much attention to the Draw dialect 
evolution - but the Cookbook ought to still be updated, right?
Anton
30-Jun-2005
[824x2]
Is the Rambo CGI code public ?
Izkata, right, submitted a rambo ticket with fixed code for that 
cookbook entry.
Gregg
30-Jun-2005
[826]
RAMBO code is not public at this time.
Maarten
30-Jun-2005
[827]
ANton: if you ask Carl you may get lucky.
Anton
30-Jun-2005
[828]
Oh, I just wanted to make a suggestion for the green "RAMBO Statistics" 
box. I would like each number to be a link that is the rambo search 
query which gives the tickets in question. ie. "New tickets: 1"  
 - when you click on the "1",  you should get a page with the summary 
of the new ticket.

But before I did that, I wanted to see if I could help by writing 
the code to implement the change.
Ladislav
1-Jul-2005
[829x6]
this looks strange:
>> o: make object! [test-word: none]

>> do bind probe reduce [to set-path! 'test-word to lit-word! 'test-contents] 
in o 'self
[test-word: 'test-contents]
== test-contents
>> probe o

make object! [
    test-word: none
]
it looks like needing Rambo presence, doesn't it?
simplified:

>> do probe reduce [to set-path! 'tst-word 1]
[tst-word: 1]
** Script Error: tst-word has no value
** Near: tst-word: 1
ah, sorry, it is 1.2.48
this is 1.3 result:

>> probe reduce [to set-path! 'tst-word 1]
[tst-word: 1]
== [tst-word: 1]
>> tst-word
** Script Error: tst-word has no value
** Near: tst-word
ah, I missed do when pasting, the results of 1.2.48 and 1.3. are 
the same, sorry for any confusion
Romano
1-Jul-2005
[835]
Lad what is exactly the problem for you?
Ladislav
1-Jul-2005
[836x2]
it is strange, that a set-path behaves this way
do probe reduce [to set-path! 'tst-word 1] should set tst-word without 
protests
Romano
1-Jul-2005
[838]
set-path! should fire an error in this case, right?
Ladislav
1-Jul-2005
[839]
no
Romano
1-Jul-2005
[840]
should behave like a set-word!?
Ladislav
1-Jul-2005
[841]
why not?
Romano
1-Jul-2005
[842x2]
i think that a path! with only 1 slot is a bad formed path
can be useful for insert/remove, but not for evaluate
Ladislav
1-Jul-2005
[844x3]
it already behaves like a set-word in case its length is higher than 
one, that is why I think, that the behaviour is natural
I needed to handle this:


foreach [path value] [a 1 o/b 2] [do reduce [to set-path! path value]]
and was very surprised, that it didn't work
Romano
1-Jul-2005
[847]
The problem i think is the first slot has a different meaning from 
second, third and so on
Ladislav
1-Jul-2005
[848]
nevertheless, the behaviour is wrong and unnatural, I vote for the 
least surprising behaviour in this case
Romano
1-Jul-2005
[849x2]
It is a surprise for me that a set-path! == set-word!
but it can be useful
Ladislav
1-Jul-2005
[851]
even an error may be more natural than the observed behaviour, but 
if the operation is valid, then there is no other choice
Romano
1-Jul-2005
[852]
that 'a in your example is a global word?
Ladislav
1-Jul-2005
[853x3]
in my example yes, but I had a more complicated code originally
where it wasn't a global word
I wanted to manipulate an object or its subobjects using this notation 
and had to find and circumvent this bug
Romano
1-Jul-2005
[856]
i agree on one fact! it should at least rise the bad-path error!
Ladislav
1-Jul-2005
[857x2]
OTOH, it seems logical to allow expression:

    to set-path 'a-word
and if such an expression isn't illegal, then there is not much choice 
left
Romano
1-Jul-2005
[859x2]
I think that give too importance to the fact that a set-path with 
1 slot is molded like a set-word (anc cannot be loaded as a set-path). 
But the first word of a set-path is not the same of a word! of a 
set-word!: the set-path word must be get and then selected.
The set-word word is like a second word in a path, the first hidden, 
implicit word! in a set-word is the context bound to the word.
Ladislav
1-Jul-2005
[861]
funny and "stupid" example:

do reduce [sp: to set-path! [] 1]
Romano
1-Jul-2005
[862]
but i agree: your proposal can  be useful, it is like to have to-set-word 
which does not change the context of a word
Ladislav
1-Jul-2005
[863]
OTOH you are right, that it *may* slow down set-path handling (?)
Romano
1-Jul-2005
[864x2]
i do not think too much, but it is true it needs a separate test 
and handling
also because the action "set the value" is not done by the set-path 
datatype! it is like an  action sent to the datatype of the value 
1 slot before the end of the path
Ladislav
1-Jul-2005
[866]
another experiment:

>> a: func [/b] [print b]
>> a/b: "OK"
true
== "OK"
>> get second second :a
== true
Izkata
2-Jul-2005
[867x2]
yarg... 'try was changed.. I just spent a half hour trying to figure 
out why a -short- peice of code would work!

>> try [to-time {Hi}]
== none
>> ? try
USAGE:
    TRY block

DESCRIPTION:

     Tries to DO a block and returns its value or an error. ;What happend 
     to the error?
     TRY is a native value.
would->wouldn't*
Allen
2-Jul-2005
[869x2]
It has nothing to do with TRY at all.
to-time {hi} is returning none. so therefore there is no error for 
TRY to trap