World: r3wp
[!REBOL3 Priorities] Project priorities discussion
older newer | first last |
Maxim 2-Nov-2009 [154] | Just giving a little report about a very interesting chat I had with Carl: - Host code package is in the works... given priority. My impression is that Carl is really wanting for this to happen. If any of you feel you can actually participate and do real tests and work, now is the time to raise your voice. - Devices and the Extensions dll code are part of the host code. Thus, by extrapolation... We (i.e. Not Carl) could work on a model of Device extensions and propose it to Carl, if anyone (or group) wants to put the effort. obviously using the current Extensions as the reference... - As it stands now, adding Native Datatypes is complex outside of the rebol core (ex: in host code) because of a few issues (GC integration being a major one). - Carl isn't against the idea of finding a way to add Native (binary) user datatype but it most probably will have to wait a bit until Carl and Host developers find a way to make it simple and bug free. a possible idea is to bave a special extension model which acts as a datatype marshaller, with defined commands as datatype actions (aka accessors in other languages). - Talked a little bit about threads, but nothing really specific to say about it... I'll need to try it in practice so I can ask relevant questions. |
Pekr 2-Nov-2009 [155x2] | I don't like point 2) - I think that Carl knows best, how to add integration of Devices, eventual callbacks, images, etc. - simply the requested stuff. We (the community) should use extensions, we should not try to develop its API. |
It is a language author call imo ... | |
Maxim 2-Nov-2009 [157x2] | Carl will say no if he doesn't like it. but do you really think that people which are going to be actively helping out in adding this type of code to the host to stray far from any ideals Carl may have? |
the case is to have a core group of people improving the host in parralel. | |
Pekr 2-Nov-2009 [159x2] | yes, I understand ... for later, maybe. But as for initial release, I would prefer Carl to implement (in regards to extensions) what's on a priority list. Believe me - if you shoul Carl, that maybe one day we have some ideas here or there, we will not get it for 3.0, as Carl will move onto other things. |
shoul = show | |
Maxim 2-Nov-2009 [161] | If a few of us take up the task of managing all of the extensions/device interface code, that means Carl can work on other things. Carl has already given us a reference on his idea of how to integrate native code into R3. I wouldn't have done it any differently, honestly. in any case, we will discuss it with Carl before commiting to any time to implementing it. |
Pekr 2-Nov-2009 [162] | Exactly - we should be sure, that the design aspect is acceptable for Carl, in order to be accepted as a default part of the distro. The last thing we need that in such an initial stage, we will end-up with one host layer per one developer ;-) |
Maxim 2-Nov-2009 [163x3] | obviously. Never said it differently. :-) |
as a concrete example, if its possible for me to add image! support in Extensions right now (code, test, examples, documentation).... I will, and if its done properly, Carl will just be happy to sign off on it. | |
if not, he'll point me in the right direction. then, when I get to vectors... the chance that I get it wrong will be smaller, but we have to start somewhere. We actually have to start doing it and stop just talking about it. :-P | |
BrianH 2-Nov-2009 [166] | If Carl is needed to really implement devices well, at least we can help by getting the almost-well implementations done, so all Carl has to do is tweak and merge. We can do a lot of research... |
Reichart 2-Nov-2009 [167] | True. |
Maxim 2-Nov-2009 [168] | yep... the grunt work is where Carl can use our help. |
Reichart 2-Nov-2009 [169] | Solve the annoying hardware issues and connection issues, even proving it with examples, and then Carl can just intigrate... |
Maxim 2-Nov-2009 [170] | devices could also be used for things like IPC or callbacks. so we could test out different ways to improve multi-threading in rebol before commiting to a specific method. |
Pekr 2-Nov-2009 [171] | Note: As Carl said for tasking - "the model is: threaded CPU, shared memory, shared symbol space, shared system function space, separate evaluation stacks, separate user contexts."" |
BrianH 2-Nov-2009 [172] | Shared write-protected structures too, afaict. |
Paul 2-Nov-2009 [173x4] | Now is THE TIME!!!!!! .... for REBOL to claim the king of PARSE!!!!! this is where all REBOL marketing needs to focus IMMEDIATELY!!!! |
Yeah I know many people here think I hate REBOL - but truth is I love REBOL more than most of you and I want REBOL DOMINATION!!!!! | |
Now is the TIME!!!!!! | |
We finally own a corner! | |
Maxim 2-Nov-2009 [177] | I'd say we always owned this corner ;-) |
Paul 2-Nov-2009 [178x2] | Well I would say until now we didn't. I believe Parse is now the most awesome thing in the programming world. Really I challenge our opponents to step forward with their product. What is greater? We dominate!!!!!! |
Before we had what was very promising but the talent behind people like BrianH made Parse what it is now! Cheers to BrianH for his contributions - it is truely selfless. | |
Maxim 2-Nov-2009 [180] | when rebol came out it was hands down the best parser implementation out there... 10 years later the rest of the industry is catching up to it. We've pushed it a little further again. |
Paul 2-Nov-2009 [181] | I know that me and Brian don't always see eye to eye but I'm an honest person where Christ has a say and I am humbled to acknowledge that Brian is instrumental in some of the greatest achievements of REBOL to date and see him as the REBOLer of the YEAR!!!!! if there were such a reward! |
Maxim 2-Nov-2009 [182] | there is such a reward, vote for him in the user.r group ... right here in altme :-) |
Paul 2-Nov-2009 [183x2] | I agree Maxim but now REBOL is far superior on the playing field. |
Thanks Maxim. I shall. | |
Maxim 2-Nov-2009 [185] | and yes, Brian has put a lot of his time into R3 for free. He has been pushing and helping Carl into doing a lot of things which are now part of R3. He deserves our gratitude. h might have shaven a full year off of R3's implementation just by himself. |
Paul 2-Nov-2009 [186x2] | I agreee Maxim. I don't always agree with BrianH on my issues but when it comes to Parse, I have been dead on with his ideas. |
Thanks Brian. | |
Ashley 3-Nov-2009 [188] | +1 |
BrianH 3-Nov-2009 [189x3] | Thanks :D |
Seriously, we owe a lot to Peta. PARSE is much better because of Peta's work. A bit of a drive-by though: Came, argued well and helpfully, then disappeared. I look forward to the next time Peta shows up :) | |
We owned general-purpose parsing until Perl 6 started catching up. We have surpassed them now though :) | |
Pekr 3-Nov-2009 [192x2] | Is anyone still using Perl? :-) In the world of PHP, Python, Ruby hype? :-) |
Wonder where Peta is, though .... | |
GiuseppeC 3-Nov-2009 [194x2] | Nice to read you working on the host code together with Carl. Hope in a couple of years I'll be ablet to do this too :-) You are a good group. |
Howevere PARSE is still not complete: REVERS is the only thing I miss. However, If we must judge, 95% of work on PARSE is done and only 5% is missing. | |
Pekr 3-Nov-2009 [196] | REVERSE, OF - those are probably left fro 3.1 or later, because they are more difficult to implement. We should not thing about R3 development being stopped by reaching 3.0 release :-) |
GiuseppeC 3-Nov-2009 [197] | I think so. Carl won't open PARSE rebol code again once it reached this stage. |
BrianH 3-Nov-2009 [198x3] | REVERSE, LIMIT and OF (but renamed I hope) are still on the todo list, and I really want all of those. My biggest pie-in-the-sky requests have been done though (with the exception of USE, which I have a workaround for). |
Back to discussion of priorities, we shouldn't delay release because of those missing operations. | |
It is triage time, my friends. We are heading to beta, so we need to seriously consider what it practical to do quickly, and what needs be put off for a bit. REBOL is going to continue to have reasonably frequent updates - no more waiting years for the next release - so you don't have to act like your favorite proposed feature will never arrive if it doesn't make 3.0. We need to figure out what we need to make a useful beta. | |
Pekr 3-Nov-2009 [201] | Infrastructure first, please. That means - as much complete Core concept-wise, as possible - Tasking, enhanced extensions, Console for Windows, parallel work on View engine, so that 3.1 can come 3-5 month after 3.0, including initial VID3 release, sound. |
BrianH 3-Nov-2009 [202x2] | REBOL 2 will still be here, and despite what some people have been saying it hasn't been abandoned. We have been focusing on R3 lately, but there will be new R2 releases to come. Migrating to R3 won't be an all-or-nothing affair. Gradual migration and mixed projects may be the norm for the short term. We don't want to block our users from uusing the killer features of R3 just because it doesn't do everything R2 does yet. |
This means that we won't be putting off the R3 beta until we reach feature parity with R2. In many ways we have already surpassed R2, but there will be some things missing in this round (VID). If you need those features, keep using R2 for that portion of your project. The new GUI won't be compatible with the old ones anyways, so you might not want to delay starting migration because you may want to rewrite your GUI later. | |
older newer | first last |