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

World: r3wp

[!REBOL3]

Carl
2-Feb-2010
[355]
Anyway, bbl to read replies.
james_nak
2-Feb-2010
[356]
My regards to Cindy and your kids. I'll get out of the way for the 
"real" rebol troops. Thanks for all your effort. See you at the Devcon 
:-)
Graham
2-Feb-2010
[357]
Just for those reading here (that is, please.... do not post web 
links to it), new wiki has:

This group is web public !!
Gregg
2-Feb-2010
[358]
With the progress Graham, Andreas, and Steeve (and maybe others I've 
missed) have made on schemes, I would like to see their momentum 
and work leveraged. 


The host kit is probably also very important, so others can pursue 
that. Redirection, for writing pipe and filter apps. If the GUI console 
for Windows isn't too hard, that would be great IMO.
Graham
2-Feb-2010
[359x2]
My feeling is that whatever is the most enabling should be done first.
Otherwise a lot of people remain blocked.
Andreas
2-Feb-2010
[361]
i agree. which is why i would like to see renewed focus on the hostkit
BrianH
2-Feb-2010
[362]
Working on compressed modules this week, inline export already done, 
protected header fields waiting on PROTECT fixes. It would be really 
helpful for there to be a discussion about the design requirements 
for embedded deferred init modules.


Really looking forward to host kit changes. Waiting on READ/as and 
WRITE/as before I start improving the clipboard:// scheme.
Andreas
2-Feb-2010
[363]
here's a personal wishlist:


1. a license for the hostkit, which would allow us to publish and 
distribute patches and custom builds. this would be a necessary precondition 
to bootstrap a healthy hostkit ecosystem (if such a thing is desired).


2. documentation of more hostkit intricacies, such as "documenting 
the boot script build method" mentioned on the priorities page. another 
pet peeve of mine would be documentation on how to add new native 
port types (such as ssl). and fixes (if any) to enable creation of 
such native ports by only touching mezzanines and the host kit.

3. a libr3.dylib built for osx.
Maxim
2-Feb-2010
[364]
right now flushing out (finishing) the extensions is actually the 
most enabling.  so: 


1.  Releasing the view host-kit with improved extensions would be 
the first step into finishing WHAT the first R3 beta will be, in 
terms of architecture. Right now, there are a lot of datatypes missing, 
and a proper REBOL callback mechanism *** with return value***  is 
probably the most frustrating issue with R3 extensibility.  image 
and vector types are critical to extensions... please they have to 
be part of next extensions.


2. Schemes!!!   with a lot of work ALREADY done,  plus willing and 
able helpers, Carl, you should REALLY look into this and orient the 
spontaneous team that is dying to get your attention so they can 
proceed FOR YOU.


3. Documentation ... I'd say.. .TWO complete and final pages a day... 
no need to do more.   At that rate, the documentation will be much 
more helpfull within weeks.  But sections of it will start to be 
worthy of being called documentation... right now... I'd call it 
the "sprawled notes" part of the site.
Graham
2-Feb-2010
[365]
So, is SSL an extension?
BrianH
2-Feb-2010
[366]
SSL needs the ability to add devices, which in theory you can do 
in the host kit but noone has managed it yet. It would not be addable 
as an extension until we get device extensions. So many things are 
waiting on device extensions...
Graham
2-Feb-2010
[367]
So, is there a documented dependency tree somewhere ....?
BrianH
2-Feb-2010
[368]
On external libs, or internal dependencies?
Graham
2-Feb-2010
[369x2]
so that the most enabling work can be done .. what's at the top of 
the tree?
I suspect it's the license!
BrianH
2-Feb-2010
[371x2]
Oh, sorting the todo list. No, the license isn't at the top.
Let's see:
- 1.6 depends on 1.2, and 1.3, 1.5 and 1.6 are related to these
- 2.1 and 4.3 depends on 1.1 (probably)
- 2.2 depends on 1.6 (probably)
- 3.3 depends on 2.1, 3.1 and 3.2
- 4.1 is written and submitted already
- 4.2 is in process
- 4.3 is waiting for discussion
- 4.4 depends on 7.1

- Clipboard support for other formats than text depends on 5.1 and 
5.2
- 7.3 and 7.4 will probably use the same code
- 8.2 depends on 5.7

- 8.5 (and secure use of R3) depends on 5.5, 5.8, 7.1, 7.2 and possibly 
6.2
Those are the dependencies I can see in the R3 priorities list.
Andreas
2-Feb-2010
[373]
now topo-sort it, break cycles and off you go :)
Maxim
2-Feb-2010
[374]
hahaha.
Paul
2-Feb-2010
[375x2]
Has return changed in R3?
requires a value now?
BrianH
2-Feb-2010
[377]
No, it's function argument handling that has changed. RETURN required 
a value in R2 as well, you could just cheat.
Andreas
2-Feb-2010
[378]
yes, use EXIT if you don't want to return a value
Paul
2-Feb-2010
[379x2]
got ya.
thanks.
BrianH
2-Feb-2010
[381]
You can't cheat on word [unset!] arguments anymore. You have to use 
lit-word [unset!] or get-word [unset!].
Paul
2-Feb-2010
[382]
ahh - that is good to know also.
BrianH
2-Feb-2010
[383]
Look at the source of CD for an example.
Paul
2-Feb-2010
[384x2]
will do.
yeah unset it returns current directory - nice feature.
BrianH
2-Feb-2010
[386]
That kind of thing is *only* for use in functions meant to be used 
interactively from the console (at least that's the policy).
Maxim
2-Feb-2010
[387x2]
this means R3 *technically* actually has variable length arguments 
 :-)
on top of refinements.
BrianH
2-Feb-2010
[389x3]
That CD has been ported to 2.7.8 - see the Core group for the source.
Maxim, you misspelled :-(
Priorities not in the priorities list:

- User-addable devices in the host, and device extensions (probably 
the same mechanism) in section 1
- SSL in section 8
Maxim
2-Feb-2010
[392]
misspelled what?
BrianH
2-Feb-2010
[393]
You spelled :-( as :-)
Maxim
2-Feb-2010
[394x2]
aaaah hehehehe
but don't see why this is bad, its very confined... I mean... its 
not like we're going to start seeing this in code:

do [cd]

just so we can supply less arguments and slow down our code.
BrianH
2-Feb-2010
[396]
Yup, it wouldn't surprise me if that would slow down your code.
Pekr
3-Feb-2010
[397x4]
Most important from my perspective:

- finish Extension enhancements
- finish Host enhancements
- move View to the enhanced command! interface

both to the state, that ppl can fully exploit those features.

- multitasking


... for Doc starting to port Cheyenne as mostly the only one REBOL 
killer product

- support porting efforts, get us to the mobile devices (ARM)


... as for Console and some other items - yes it sucks to not have 
them available, but I think that having strong infrastructure in-place 
is really important. But overall we need all the priority list implemented 
for R3 being worth calling a beta ...
... and someone damned fix the useless 'call function :-)
.... some ppl also requested enhanced /library interface being done 
as an extension. I started by donating 100USD, and now we are at 
someting like 400 USD ppl would pay for such a feature. So, what 
do we sponsor next? :-)
... but ... I think that A97 should lower the number of CC non-solved 
tickets. There is plenty of them added recently ...
Graham
3-Feb-2010
[401x4]
A GUI table would be nice ...
nearly a month after Carl said he was going to work on a new alpha
>> chat
Fetching chat...
Cannot load chat from web.
Can't reach rebol.com and rebol.net ...