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

World: r3wp

[!REBOL3-OLD1]

Janko
22-Jan-2009
[9946]
yes, I realized .. that's why I said big.. usually there are functions 
and variables, here are so many things, dialects, schemes .. etc 
:)
Henrik
22-Jan-2009
[9947]
I think you can figure out how it works by reading Steeves code. 
It's quite simple.
Janko
22-Jan-2009
[9948x2]
that link doesn't work for me , and I also don't have r3 to test 
it
I saw some tutorial about creating new "protoco handler" .. or is 
that a third thing?
Henrik
22-Jan-2009
[9950x3]
it should be the same thing
if you read about ports in the wiki, they'll give a fair explanation 
of how they work.
it's the same reason you can use READ on files, HTTP, FTP, etc.
Janko
22-Jan-2009
[9953x2]
aha yes.. this is interesting concept .. I was alredy thinking about 
it when I was using pop:// protocol (carl probably realized that 
most "communication" can be abstracted in means on operating on serries)..
then I suppose to create new scheme needs to just provide handlers 
for all those funcs, insert, copy, delete .. ?
[unknown: 5]
22-Jan-2009
[9955]
Henrik, to what level are you being involved in R3 development?
Henrik
22-Jan-2009
[9956]
I work on the GUI and point out bugs to Carl.
[unknown: 5]
22-Jan-2009
[9957]
Do you guys get to get down to the C code at all or is that strictly 
controlled by Carl?
Henrik
22-Jan-2009
[9958]
C is only Carl and Cyphre. Everyone else only work with REBOL. But 
we are allowed to contribute C code if he wants something specific.
[unknown: 5]
22-Jan-2009
[9959]
Oh what about Gabriele? I thought he had that type of access.
Henrik
22-Jan-2009
[9960]
Yes, but he is very busy with QTask for the moment. He has contributed 
HTTP, REBOL/Services and the first prototype of the VID3 GUI.
[unknown: 5]
22-Jan-2009
[9961]
I see.
Henrik
22-Jan-2009
[9962]
Janko, yes, exactly. If you open a port, you get a port object with 
information about what the scheme does. When that port is passed 
to COPY, appropriate actions are taken to carry out the COPY function 
that resides inside the scheme.
[unknown: 5]
22-Jan-2009
[9963]
All of you volunteers are do you guys get paid for your work?
Henrik
22-Jan-2009
[9964]
I volunteer. I don't know about others.
[unknown: 5]
22-Jan-2009
[9965]
Is there a list of all those contributing to R3?
Henrik
22-Jan-2009
[9966]
Our official people list appears not to be up to date:

http://rebol.net/wiki/People

:-)
[unknown: 5]
22-Jan-2009
[9967]
hehe - no doesn't appear so.
Henrik
22-Jan-2009
[9968]
well, there's me (GUI), BrianH (smart guy), Brian Tiffin (docs), 
Cyphre (graphics), Gabriele (network/GUI), Pekr (communications), 
Maarten (network), and about 10 others who've made contributions. 
Didn't really want to mention people in case I forget important ones.
[unknown: 5]
22-Jan-2009
[9969x2]
I understand.  But that is helpful, thanks.
I think Steeve and Doc are involved in some manner as well.
Henrik
22-Jan-2009
[9971]
oh yes. see? I forgot some. :-)
Janko
22-Jan-2009
[9972x4]
Paul: when you were asking about default arguments to funcs before, 
I think it's a "conceptual" limitation because of stuff like this 
example (for example that oneortwo can take 1 or 2 arguments : >> 
oneortwo 2 add 3 2  .............  and most things like if either 
are expressions which means they return a value (which you sometimes 
need and sometimes not )  you can "assume" that you will always require 
result of add because it has no side effect, but for example : >> 
oneortwo 2 if [ insert copy [ ] 1 ] ..... there is no theoretical 
way to determine if result of if SHOULD be taken by oneortwo or not
thats probably why refinements were invented , that also add a lot 
of new
OCaml for example has optional arguments , but you HAVE to use parentesis 
like this oneorwto 2 ( add 3 2 ) and every value that get's returned 
from expression must sink into something explicitly ..  so if you 
don't need it you have to still use     >> let _ = somefunc 10 in 
<<.. or >> ignore ( somefunc ) ; ..
(but I am a ocaml newbie too)
Steeve
22-Jan-2009
[9976]
[Virtual blocks] What do you think of an option to allow fixed-size 
records only, so that there is no need to create a file index (faster 
access but data file possibly bigger)
Henrik
22-Jan-2009
[9977]
yes, I like that.
Janko
22-Jan-2009
[9978x2]
yes that would be a cool option too
Steeve ... are there any chances to see this also in R2?
Steeve
22-Jan-2009
[9980x2]
theoricaly yes, schemes exist under R2 too
do you want R2 version at first ?
Anton
22-Jan-2009
[9982]
BrianH:  ELSE  -  I never used it. I don't care if it's removed.
Janko
22-Jan-2009
[9983x2]
well at least there is a chance :) .. well I don't know when I will 
be able to try R3 at all, and even less when I will be able to use 
in for real projects... that's why I am asking, but I don't "urgently" 
need it right now so no worries for me
I like that you focus on R3 because this all moves it forward too, 
so hopefully we will get to it sooner than later
Henrik
22-Jan-2009
[9985]
BrianH, I first noticed ELSE now that you mentioned it :-) Don't 
need it.
[unknown: 5]
22-Jan-2009
[9986x2]
Fixed sized would only be faster in the sense of retrieving specific 
records.  Traversal is actually slower.
But I would say offer it anyway because this would make the virtual 
block scheme more versatile for the respective application.
Janko
22-Jan-2009
[9988x2]
will R3 have something similar than coroutines or a way to simulate 
cooperative or preemptive (green-not on os level threads) concurrency?
(I imagine that if not otherwise this could somehow be made in libraries 
with its code is data feature)
Henrik
22-Jan-2009
[9990]
R3 has tasks, which I believe are OS threads.
Janko
22-Jan-2009
[9991]
wow, really? this is cool.. usually scripting langs have only green 
(not-os) threads
Henrik
22-Jan-2009
[9992x3]
Tasks are very interesting, as it will render slow and large cooperative 
threading libraries for R2 moot. You create a task like you create 
a function and it can be used in the same way, except you are returned 
to the console right after calling it. Also networking is completely 
async on the lower level, which helps speed up network operations. 
You can achieve similar things in R2 through hacks, but it's not 
well documented or stable.
Janko, I can't be completely sure that they will stay that way. This 
has something to do with the Wildman project, which is about getting 
R3 to run standalone on embedded hardware with a minimal OS underneath. 
So whether R3 will then employ its own threading model or always 
use OS threading, I don't know... and Wildman is not something that 
will happen soon.
Tasks are available in the old public alpha, but they may not be 
stable.
Steeve
22-Jan-2009
[9995]
what is that project ???? Who is working on WILDMAN ?