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

World: r3wp

[!REBOL3-OLD1]

Pekr
11-Sep-2009
[17540]
But - the situation is more diffuclt. If we want ppl to start using 
R3, we have to provide them at least with R2 funcitonality. But we 
are far from that. Noone imo gave proper thought to networking protocols. 
My question is - would they benefit from concurrency model? If so, 
we should definitely stay in alpha, and work-out to have really feature 
complete Core (kernel) first ...
Maxim
11-Sep-2009
[17541x5]
which is why I say that releasing a Beta with stuff as it is already 
working is a good idea.  but continue working on an alpha which lets 
us give valuable feedback on stuff to come.  The curecode bug squashing 
is concentrated on beta version, design & core implementation is 
limited to alpha/experimental versions.
this way he can let out an experimental version which has threads 
and let any of us with the know-how and use cases to test extensions 
and concurency in parrallel, while he continues to squash beta bugs.
the problem with RT is the parralelism of the development.  its already 
100 times better than it was with R2 since we are giving Carl & friends 
hundreds of man hours of testing which can't perform anyways.
many issues where raised because of the alpha nature of R3 which 
would have ended-up in a screwed up release version, in the old RT 
philosophy.
** But a lot of R3 is working very well right now.  **  


Going to beta could also mean that a select few people have the capacity 
to build the ports to other platforms. Squashing OS related stuff 
in parralel with stuff specifically in beta, meaning they would NOT 
have to concentrate on the latest alpha buggy stuff to fix and port.
Pekr
11-Sep-2009
[17546]
releasing a Beta with stuff as it is already working

 - what is the point in calling it beta then? Carl will surely continue 
 to implement new stuff the way he did it till now. Calling something 
 a beta just for the sake of the word itself, is not important for 
 me. Features and completness is important ...
Maxim
11-Sep-2009
[17547x2]
the beta only has what is complete and bug free in the alpha.  that 
is the point.
once you get to beta, the porting is official, for example... its 
just a definition of what you can expect at this point. what is in 
the beta works... what is in the alpha isn't guaranteed.  but many 
of the bugs are independent of what is new in the language.  so these 
later bugs can still be fixed in the beta stage even if new features 
are being added.
Pekr
11-Sep-2009
[17549x2]
so the point is not to open development on hundred of fronts, having 
all those unfinished, but select some featureset, and finish it, 
then move further ....
The problem is, that some things are interconnected. E.g. not having 
parse enhancements might influence how you parse networking protocols 
or rebol level decoders/encoders, altought it can be later adapted. 
The same goes for concurrency. Guys can be reluctant into writing 
networking protocols, especially if we want something like Uniserve 
inside, unless the concurrency model is well defined?
Maxim
11-Sep-2009
[17551x5]
Yes and more specifically, some of that can be handled by other people 
than Carl.  Probably faster even, cause Carl, like most thinkers, 
hates doing the repetitive work for sure.
yep.  beta is limited up to the point where the alpha stuff works, 
at which point the beta/releases have new but working features just 
needing more testing in order to be sure all is well.  but the important 
thing is that if something really is discovered in the beta, you 
can still officially change and go back.  at which point something 
rolls back to the alpha stage and Carl plies his will to that specific 
problem in priority.


its just a way to make expectations, promise, and procedures clear 
and explicit.
right now... there is no rule to say when "we go into beta"  no way 
to clearly say what will go into the beta and why.  its just some 
vague point in the future... "soon".  having this explicit means 
we can have beta and alpha concurrently, with a clear path to release. 
 today, I still can't know what to expect will be in the beta.
it also makes it clear that at this point, other people can join 
the release team.  some people would probably volunteer for some 
ports if they need it.  but what to port?   ahhh... what's in the 
current beta... don't bother with the alpha stuff its too shaky.
we could have a R3/core beta version next week with a subset of what 
is in the R3 alpha today.  (if the last of the very core issues are 
finished by then).
Henrik
14-Sep-2009
[17556]
so, ideas for how to run R3 through the web console?
Maxim
14-Sep-2009
[17557]
you might want to ask kaj, he beat you to a working example !  ;-)

http://tryrebol.esperconsultancy.nl
PeterWood
14-Sep-2009
[17558]
I think it will depend on the OS. Use ports on Windows and CGI on 
Linux/Mac.
Maxim
14-Sep-2009
[17559]
Henrik: your console is VERY nice,  I think I'd prefer green (maybe 
#00CC00) for Console answer though.
Henrik
14-Sep-2009
[17560x3]
the target is debian lenny for now
maxim, we can build color schemes, if we want.
Maxim, yes, Kaj beat me, but it appears to be a single run R3 process 
per query, so it's different from mine. The challenge would be to:


- Launch an R3 process and bind the process ID to a session ID for 
the user
- Send requests to that process.
- Get response back from that process, one at a time.
- Kill the specific R3 process.

- Build some kind of arbiter to manage R3 processes, time processes 
out, get requests from users, etc.
Maxim
14-Sep-2009
[17563]
maybe just a very simple set "bg", "text", "reply text" fields under 
the console where people can put valid #FFFFFF colors which are used 
by the javascript  :-)
Henrik
14-Sep-2009
[17564x2]
the console divs are very simple, so it should be possible.
BTW, managing the keyboard under various browsers is pretty crazy 
as there is no standard, so if there are places where it doesn't 
work, don't be surprised.
PeterWood
14-Sep-2009
[17566]
Have you looked at dojo.keys - http://docs.dojocampus.org/dojo/keys
Henrik
14-Sep-2009
[17567]
nope, but I don't think I'll need it. thanks, though.
Maxim
14-Sep-2009
[17568]
wow that is a cool library :-)
Maxim
15-Sep-2009
[17569]
btw Carl, it seems, is still open to renaming REBOL.  He seems to 
like "Zen" ... what do you guys think?
Oldes
15-Sep-2009
[17570]
I think it would be hard to find it on Google between all the cca 
62000000 other "zen" pages
BrianH
15-Sep-2009
[17571]
I'm not aware of another Zen language, but there is likely some obscure 
project called that. I like REBOL, but if there is a way to cut down 
on the blank stares when I talk about it I would be for it.
Sunanda
15-Sep-2009
[17572]
There is already a language with a very similar name: Zeno
http://home.att.net/~srschmitt/zeno.html
Oldes
15-Sep-2009
[17573]
There is also more than 10000000 "Zen language" pages
Henrik
15-Sep-2009
[17574]
I don't think renaming REBOL itself is a good idea. However not mentioning 
the name in products powered by REBOL, might be a good idea.
Geomol
15-Sep-2009
[17575]
If a new version of REBOL is very different from what we know as 
REBOL today, then it might be ok with a name-change. If it's just 
a new version in a line of versions of REBOL coming from Carl, then 
I think, it would be more confusing to rename it. And what's the 
point of a rename? The name is not the reason, the language is not 
more widespread.

List of 	programming languages:
http://en.wikipedia.org/wiki/List_of_programming_languages
Maxim
15-Sep-2009
[17576x2]
somehow, I've always found that rebol sounded boyish.
and IMHO zen is a very appropriate name for the language itself. 
 but I agree that in web searches it would be quite hard to find 
stuff... which is extremely easy today with  REBOL.
BrianH
15-Sep-2009
[17578x2]
That's why the typo-names are popular (like Google).
Google was an unintentional typo of googol.
Maxim
15-Sep-2009
[17580x2]
zen script is already used by a vertical market company in dtp to 
web services.
zen script would be a very cool name  IMHO  :-D
Geomol
15-Sep-2009
[17582x2]
How does Erlang sound to you? Boyish? Business? What?
How does IDL sound?
Maxim
15-Sep-2009
[17584]
REBOL sounds boyish because its a bad typo of Rebel.
Henrik
15-Sep-2009
[17585]
I think changing the name is going to severely add confusion to what 
it is that Carl is trying to sell people/developers. 

For one, it's not likely to help getting old REBOLers back in the 
fold. We would have to waste a large amount of time explaining the 
relationship between REBOL and <whatever name>. Probably much more 
than we realize.


REBOL 2 and REBOL 3 are understandable immediately in the same sense 
that PHP4 and PHP5 are.


What would happen if Microsoft renamed DirectX or if Javascript changed 
to a new name? Confusion. Nothing more.
BrianH
15-Sep-2009
[17586]
Erlang sounds technical and boring, but is OK. IDL sounds like the 
government made it.
Maxim
15-Sep-2009
[17587]
it really gives out the impression that you are out to "teach people 
a lesson" and very few people in an ego filled space like programming 
responds well to that.
BrianH
15-Sep-2009
[17588]
The word Rebel is boyish - the typo just sounds like it came from 
a tech company (everyone does it).
Geomol
15-Sep-2009
[17589]
Forth is so named because in 1968 "[t]he file holding the interpreter 
was labeled FOURTH, for 4th (next) generation software Ñ but the 
IBM 1130 operating system restricted file names to 5 characters."
:-)