World: r3wp

Peterwood not only C/C++ the ++ operand exists in most of the languages 
now in days compiled or interpreted... (python, perl, tcl/tk, ruby, 
java, etc...)

most people want i++, instead of i= i + 1 but i always thought the 
right operand instead of "++" should be "=+"  somthing like i=+ is 
in my opinion more explicit...


Pekr; some time the Carl says things we can't understand and mainly 
cause we don't have a full view on the source code he is talking 
about...

modular coding is obvious but  you have several ways to realise it... 
puting preporcesor flag to include or not part of the code when you 
compile is one solution

having them indeferent folders and binaries or libraries is another.. 
And that was always one of my  biggest comment rebol wants to do 
all every where so it ends being

weak every where and doing incompletly most of the things it pretends 
to do ...

http://eclectic-pencil.blogspot.com/2010/02/rebol-3.html

Nice :-)

He is still less desperate, than some of us :-)

he can read the chat thru a browser .. no need to fire up r3

or can we script the login, and download of new messages :)

Can we? Does R3 chat have an API? I mean - there are commands, but 
can we script it? Dunno how ...

http://www.rebol.com/r3/chat.r

Hmm... Script Error: This script needs View 2.100.28 or better to 
run correctly
So, why does a console app need view ?

auto-login: func [/force] [
            all [
                any [force prefs/auto-login]
                prefs/user
                prefs/pass
                attempt [login-serve prefs/user prefs/pass]
                true
            ]
        ]

Should be able to modify chat to autologin, check for new messages 
and then quit.

I wonder what sort of flood protection there is ...

Hmm, so we can only have 255 Windows?I thought I will make small 
stress-test one day, opening 10K Windows under Vista :-) IIRC, my 
friends did something like that with AmigaOS, and it still worked 
:-) http://curecode.org/rebol3/ticket.rsp?id=1610&cursor=1... anyway 
... this is imo unnecessary limitation ....

Graham:

If I want to set something to the index of a series, or something 
else if it's not there I have to do this

b: either a: find series var [
	index? a
][ 	default ]

when I'd rather do

 b: any [ index? find series var default ]

So how about letting index? also take none as an argument ?

Interesting idea, Graham. It's not that dissimilar to the recent 
proposal that EMPTY? take none. CureCode it :)

index? none 

+1

 :-)

http://www.curecode.org/rebol3/ticket.rsp?id=1611

Done

Cool, thanks! We can post a comment to the EMPTY? none blog mentioning 
this ticket as well :)

Done. Also tweaked the ticket to be more specific, and added a comment 
in favor of it.

I can make a prediction, Gradually, other functions will

be modified to propagate the value # none instead of returning an 
error.
This is only the beginning.

Seriously people, get to know and love ASSERT. You are going to miss 
those errors someday, to help you track down and prevent data corruption.

Steeve are you against the idea?

On the contrary, I''ve always been for :)

hard to tell :)

My comment also showed the downside: You will no longer be able to 
rely on INDEX? returning an integer. Though in balance I am in favor.

I dislike useless error bombing, as I already said

I want to write simpler code too

I hate having to trap for errors when I always have a default behaviour

#none is the ideal pass-true value. All your codes would be delighted 
by such feature

I also dislike useless error bombing. Though I am in favor of *useful* 
error bombing; not the case here though.

*pass-thru

You can thank ASSERT for making LOAD more reliable in R3 than it 
is in R2. Use it yourself to the same effect :)

In contrast, I don't think that NONE = INDEX? NONE is *necessarily* 
an error. You can screen with ASSERT or EITHER when it is.

Currently, just a bunch of natives have been tweaked in that sense.
remove, take, (and some other i can'"t remember now).

But there is no reason to restrain the invasion of the pass-thru 
behavior.


Indeed, just stop the propagation when a control flow function is 
reached :)

Is anyone analyzing rebol code to look for awkward sequences that 
might be solved by changes in functions?

Not systematically yet, but yes on an ad-hoc basis for a few years 
now. Even during the GUI design phase before the first 2.100 public 
alpha.

Not so easy to identify, and you have to recruit some Rebolers to 
your cause, then there is the last obstacle. How to summon Carl...

...which you do through CureCode, and messages in R3 chat.

Don't give all the secrets...

for free :)

The real problems blocking systematic fixing of awkward code is:

- A lack of a large enough set of R3 code to examine. R3 is already 
different enough from R2 that the code isn't comparable in this way.

- Not having metrics for "awkward". We've been eyeballing it so far, 
and meijeru and I have been the most systematic about that approach.

But we've made a rather large set of changes to R3 already that fix 
most of the R2 awkwardness.

I've give you one awkward idioms for free, pretty common.
>> unless find serie value [append serie value]

i'm bored to have to write such code again and again

prerebol it

ahah

APPEND is a modifying operation. This is an excellent example of 
where the propagation should stop.

Agree,  indeed

but not on the first parameter:
append find serie value value

Stupid me...