Home   Archive   Permalink An Open Letter to Carl and the community Good day Carl;          I have only recently discovered REBOL and love it in every aspect. I am, however well aware of your past innovations and the contributions you have made to computer technology. I would like to take a moment to make a plea to you.          Sir, releasing R3 into the community was most likely a hard decision for you but an admiral one indeed. I have read many different topics and opinions on the state and fate of the Rebol project both open source R3, version 2 and RT in general. Regardless to any of that Let's talk about a few things.          Now, not being to critical and having a new understanding that you have taken employment with Roku, in regards to my purchase of Rebol Version 2 Command SDK last week and not receiving any response to that purchase in the form of product delivery, I believe it is no disillusion that you may not be behind the open source project or RT in general as much as you may want to be if even you still have that desire.          As I look around the Rebol Community it is painfully obvious that it is a fragmented one and on the surface it would seem as though there is no leadership and that the community put that trust in your hands and was somewhat dependent on you for such. Now that your time is being spent elsewhere which is understandable the community has no clear focus. I would like to see that change and so would many of the current members as I have read in many places. However Sir, in order for that to happen I believe we need to know exactly where you stand so there is no guessing game or rumors flying around. We need your blessing to move forward to make this a viable community project. Here is my suggestions Sir understand I come to you to make a plea on behalf of the Rebol Community. It has potential no matter what has happened during it's lifetime.          Proposed Workflow          1. There are some members of the community that have a good handle on the source and can contribute and pickup where things are but we must get organized before we lose their attention. In this I propose you address the community and let us know where you stand as the author of this great project and if you have no time for this we understand but we need your blessings and the knowledge that your not a active participant amongst other things to make this happen. Seems as though the community is patiently waiting for you to return, that is actually hurting this movement more then anything.          2. We need to whip Rebol's home up to shape by getting organized and I propose to finance out my own pocket the tools we need to do so including,          A. The formation of a proper entity structured as a non-profit called The YouEnvision Foundation which can be the steward of the source and provide a platform for those who wish to be apart to help make decisions and keep the codebase adaptive to today's trends and technological advances, The Rebol Project will be one of several projects shepherded by the YouEnvision Foundation which is why I don't propose using Rebol in the name. Think of it like the Apache Software Foundation because that is actually the same modal that it shall follow. Why? Because there are several of open source projects out here that have potential but have been abandoned because the founders just didn't have the knowledge, resources, marketing skills or desire to drive the effort home. I intend to try and revive some of these efforts starting with Rebol if you will let me rally the community.          B. Not knowing all the internals of the community and who the major players are other then yourself and a few very vocal supportors , some of what i will suggest may indeed already be. Next up would be the Rebol domains I suggest maybe you can release the rebel domains to the community if your in control of them so we can use those domains and also assume financial responsibility for them.          C. Come up with a new web strategy including new sites, project management tools, private SCM, Private Wiki's to allow core developers a internal intranet platform to work from. Project sources will be synced to public ones at github, sourceforge, bitbucket etc for community non-core developers access. But core developers typically will need more tools to collaborate more effective then any of the SCM companies provide like Agile workflows, Kanban Boards, Scrum, Confluence, Build Farms a rich social coding experiance etc., and notwithstanding other tools to maintain a project of this scope.          D. let the main players decide how they are going to get things done (GTD) using the tools provide to them by the foundation to which they are apart of helping to guide the process using a democratic process.          E. Now I'm sure this is going to be a hard sell but, Sir please release the source for Rebol Version 2 and all it's SDK's and specifications like the /IOS, /View, /Core /Command, /SDK documents and Rebcode in short give us something to work with please. By doing this the community can keep Rebol alive and valuable for years to come, we can also insure that past purchasers of everything you did prior to R3 can keep their system running and those who actually purchased a license from you that promised them access to the source should you decide to do something else or RT goes dark will be able to collect on that license from the community. One of the main reasons I ask for this is because you have given us a platform however it is a rewrite from the ground up and is not stable like version 2 is and therefore cannot provide the same benefits to those who actually depend on using Rebol. By Open Sourcing version 2 and all it's components we can begin our work from a stable platform while working on bringing R3 to a stable release while back porting any new features that can fit in the version 2 tree without introducing a break in backwards compatibility for those using it in production environments. Access to the source also provides the core team with a blueprint to getting R3 stable as there is no better documentation then the last stable codebase that already achieved production strength not to mention some of the features have not made it to R3 in any stable capacity. Sir, if indeed you have moved on this would be the right thing to do for the continued presence of Rebol, please don't just let this die and be forgotten release the source so we can launch a full blown open source initiative for the Rebol Project.          Bottom line sir is I will do what i can to rally members of the community and help them to help themselves by making available my expertise in business to guide them to being able to do what they want to do. I have been in business for over 25 years and believe that I can offer the knowledge and tools that the community needs to succeed if they want it. They will still need to step up and also find a leader within them my intention is to consult them to be leaders through mentorship.          There are plenty of other things we would need to do as a community but I think you get my point. Now, hopefully Hostile Fork can get you to send me my license for version 2 command sdk and also maybe, just maybe you can see what good my plea can actually do if you embrace it. Let us revive this effort, let us maintain the source for both trees R2 and R3, let us embrace the new efforts such as Red and try and unite all Rebol like technologies rather then be a splintered effort. Please Sir don't just let this die off we understand and respect your decisions to live life please repeat our love for Rebol and allow us to keep your legend and work alive.          Thanks please contact me if this interest you at all I pray it does because this is a great project and deserves to be set free rather then being slowly choked into nonexistence for whatever the reason. no offense intended. I have already begun to take some of the steps needed to help the community get it done the youenvision domains have been acquired, i will be deploying a openstack cloud on an Unbuntu, VMWare ESX and ZEN stack ontop of Apple hardware so we can legally pinup Mac OSX virtual machines in the build farm. Apple hardware can run all OS's however all other hardware can't legally run OSX. I will give the community 100% access to this cloud for development and testing purposes also, the domains and all the sites (i,e rebol.com, .net, .org, etc) may be hosted here on dedicated VM's so they don't have to worry about any of that.          I got the time, money and desire to help make this a reality what do you say Carl can we make this happen?          Patrick Stewart mrpastewart a.t. youenvision dot org posted by:   Patrick Stewart     22-Sep-2014/22:39:26-7:00 Hello Patrick,      I gave a talk at the Recode conference in Montreal about 6 months after the open-sourcing of Rebol 3 that was titled "E Rebolus Unum". It may be of interest to you to read the slides:      http://metaeducation.com/media/shared/rebol/e-rebolus-unum.pdf      (Note: Although I complain about /ONLY there, in the time since I actually have decided on a philosophy of /ONLY that I believe makes sense. In fact it was I who added IF/ONLY such that IF/ONLY TRUE [PRINT "HELLO"] will not evaluate the block, and just return [PRINT "HELLO"]. I could explain what that new philosophy of /ONLY is... but it's not really on topic of what you were talking about.)      There has been no shortage of requests on Carl to do various things. To my mind the most important one is delegation of community management for the GitHub rebol/rebol repository. Without there being a trusted core of people that are able to do integrations there, it appears to be dead--right now that is where someone would look to get a "pulse" and it doesn't appear that there is one. Establishing trust so that others can make changes on a public experimental branch is critical.      Open sourcing Rebol 2 components is something that there are rumors he has legal/contractual reasons he cannot do. We don't know how much of that is his reliance on code he didn't write and doesn't have a license to distribute. We also don't know how much of that involves formal or informal arrangements with investors and partners that Rebol Technologies had was active and employing people.      Those are the "known unknowns". The "known known" is that he considers Rebol 3 to be a coding and architectural "cleanup". He is not interested in turning back the clock to try and figure out how to publish Rebol 2 so the rest of the world can build and understand it. If you've ever open sourced a previously closed-source codebase, you may know the feeling; it takes a lot of time before putting something public like that with your name on it.      It would be nice in theory if people could borrow bits from Rebol 2 and patch them onto Rebol 3...if people promised they wouldn't go off forking and patching Rebol 2 as a project in its own right. But the reality is that it would just create another point of divergence; and Rebol 2's lack of Unicode is yet another reason it would be an albatross around the neck. So people like me have tried to keep the focus on one split: the one between Rebol and Red.      We'd like Rebol 3 and Red to be compatible where possible (for instance at the LOAD source level, and base language). Then Rebol would build on an ANSI-C toolchain, Red would be built on Rebol for some time...and become self-hosting when the time is right. Both would have their uses.      Red development isn't standing still by any stretch. If you haven't kept up with that project, I suggest checking out the introduction and video here:      http://www.red-lang.org/p/contributions.html      So what most of the user community has focused on is thinking through the common design areas to Rebol and Red; getting a good Q&A presence on StackOverflow/etc. Also working on various points of evangelism.      We've been very close to getting an arrangement with Carl on delegation of integration duties on the GitHub master...and that is really the most important thing to keep bending his ear about at the moment! posted by:   Hostile Fork     23-Sep-2014/0:13:17-7:00 thanks for the reply. I get it and have checked out Red and find it interesting the direction Red has taken vs Rebol. I will dig into your slides.      And out of curiosity      "Patrick Stewart's email address as "mrpastewart" is rather humorous. I wrote my easily-predictable response on the forum. I should replace myself with a HostileForkBot"      And exactly why is it humorous to you?      and why wouldn't I want to pay for a copy of the SDK in 2014. For me, learning is my goal and supporting the project. I am willing to pay because I want to learn and starting from version 2 and it's SDK just seemed like the right place to begin. And i have read in some places that I should start with version 2 until version 3 is up to par if I wanted to use it in any kind of production capacity I believe i seen where Nick actually suggested that several times in the forums.      So am I missing something here? posted by:   Patrick Stewart     23-Sep-2014/0:36:23-7:00 oh lol duh i get it about the email. I was just trying to leave some way for others to reach out to me without getting spammed out hahahaha hope i don't get spammed out. posted by:   mrpastewart     23-Sep-2014/0:46:13-7:00 Hi Patrick,      (I'll admit I still don't know if the right way to pass your test is to reverse the "obvious" mistake letters or not. To be safe I guess one should cc: both?)      Time, money, and energy are certainly welcome and needed to get projects going! I'd say that right now Red has more momentum and machinery in place to make use of those resources. Hopefully the video gets you excited about it. Even though Red is bleeding edge, it is being developed every day:      https://github.com/red/red/graphs/contributors      And most importantly :-) Both projects have great logos to work with...      http://i.stack.imgur.com/nNgAY.png      But the politics of Rebol and appealing to Carl is something people who've been around for a while have a lot of experience with (some, even a decade-and-a-half). Feeling held up is why some say Red was a "declaration of independence" - it was also announced prior to the open sourcing of Rebol 3.      Now that Rebol 3 is open source, things are getting more on the same page. Just with the exception that fragmentation is harmful, so a not-seemingly-dead Rebol central repository on GitHub is a good thing. We should canonize the leadership and have people who represent understandings of both Rebol and Red doing integrations there.      You might find some who would be responsive to a petition to try and get Rebol 2 open-sourced. I can't tell you not to ask. But I can tell you that those going down this line of pursuit in the past have been turned down fairly definitively. I'll also tell you that there is probably a better outcome achievable with a simpler request (and I'll re-iterate has seemed quite close to being granted.)      Anyway...happy to see you on StackOverflow! Those initial 20 points are pretty easy to get, although SO is very "rules-based". It can't be used like a forum for discussion.      A good safe way to aim that your first question isn't going to get voted down would be to make sure your post contains a *short* and *focused* code sample that isn't doing what you want, or whose behavior you don't understand. If there's no code, you start getting into questions that are subjective. ("What's a good book about Rebol?" etc.) posted by:   Hostile Fork     23-Sep-2014/3:43:07-7:00 Oh, and on the name...if still not clear, it jumps off the page to me as:      Mr. Paste Wart      ...where I was assuming the correct name would be Mr. Pat Stewart, with a missing T. But on further inspection...if your middle name starts with an A then perhaps it should be:      Mr. P. A. Stewart      So maybe it is correct. But "That's MISTER Paste Wart, to you!' makes me chuckle. :-) posted by:   Hostile Fork     23-Sep-2014/6:07:56-7:00 Lol ok I never ever looked at it like that but yes it is Mr P A Stewart with A being my middle initial. Hahahaha might have to change that. posted by:   Patrick Stewart     23-Sep-2014/8:14:47-7:00 Ok, so even though I understand the politics portion of this and appealing to carl to bless the communities efforts on moving forward may I ask an obvious question here. Understand I am not trying to start anything but,      What exactly is stopping the community from just forking the source and getting it's act together?      I mean R3 was released under the Apache OSS license which would certainly permit this. Think, "OpenOffice and Libre Office"      Outside of Carl being able to demand that you not use the name Rebol or any of RT's trademarks why is the community so dependent on him to the point that the project has took a nose dive.      Why not reduce the splinter by just forking the R3 project into the Red project since it is used to bootstrap Red still. Rename it if you have to and everybody jump behind the Red project working on both until Red can bootstrap itself and become self hosting.      Doing this will bring both teams together and seeing how you made Red compatible with the R3 interpretor this would be a wise decision and would bring the existing community back together in one place.      Could R3 not be renamed to fit within the scope of the Red project for what it is being used for? I mean as far as domains and all that new ones can be acquired that represent the scope of everything going on.      I have seen a few forks but each takes it's own direction so I'm just curious. posted by:   Patrick Stewart     23-Sep-2014/8:51:36-7:00 Or better yet, why not fork the R3 project into the Red Project and then try and reunite all the communities together meaning the R3Bazzar, Artronix, Shapphire, Red, R3 teams if possible that would put a good bit of steam in the community at least I think so. posted by:   Patrick Stewart     23-Sep-2014/9:02:29-7:00 Perhaps the R3 project should be forked. But consensus is and was that first place to get Rebol from should be the official source it came from. The last thing the community wants is a distribution diversity like there is for Linux distro's. With the Atronix and Saphirion it is already now getting complicated and as the user base is so small as it is, there is no right of existence for that many sourcebases. So it became the stand-off we face today where Carl/RT has been given time and opportunity to maintain the R3 open source. R2 is no longer being developed, but it is the standard for Red because it is the only available Rebol that is stable enough for development of Red. With Red improving on R2 where needed and wanted. Bringing all together will be undoable imo. Perhaps after Red and R3 are finished in a new R4 effort, but that will most certainly be left to the next generation. posted by:   Arnold     23-Sep-2014/9:23:38-7:00 "...drive the effort home." Yes, well said. We have R2, which has a number of documentation documents that mention how things will be explained in some future documentation, we have R3 which is a cleanup of R3 and in development, we have Red which is in development, we have Atronix and Saphirion R3 versions which seem to be not totally documented. Nothing has been driven home.      I myself would not mind if there were several versions of REBOL or a REBOL-like product, if one of them were "driven home," that is, was complete, had good documentation, could be counted on to remain in existence, and could be counted on to keep up with new operating systems and have bugs fixed.          I do agree that it would be nice if Carl could say something along the lines of, "I am tired of REBOL and now that it has been launched as open source I find myself losing interest, so you're on your own, and for reasons I am not allowed to discuss the R2 source never will be available to anyone," or whatever the truth of the matter really is. posted by:   Steven White     23-Sep-2014/11:02:29-7:00 A few months ago, I was talking with Atronix about the need for a visible and active project leader to spearhead moving Rebol3 forward. I suggested that someone at Atronix be this leader, and they suggested that I be that leader. I'd love to, but I wouldn't have the time to properly devote to it.      In any case, I'm totally for moving Rebol3 forward, and if that means that the community decides that a different Github repo should be the community repo, I'd be behind that. Right now, I'd suggest that Atronix or Saphirion's repo is probably the best choice to fork from into a community-centric repo. posted by:   Bo     23-Sep-2014/19:36:13-7:00 I don't expect R2 source to be released. There was so much discussion about this in the past, and it seems there's some sort of encumbrance on R2 - perhaps some licence issue, an agreement with investors, or maybe Carl just simply wanted to move forward with R3 if Rebol was to progress at all - no one seems to know for sure. I am curious about the escrow account that I'd read about in the past. Did anyone have a contract in which the code was actually put into escrow, and what were the terms of that agreement? From my point of view, I feel that Carl has relieved himself of responsibility by opening the source to R3 and R3-GUI. It's up to the community to use and improve what he delivered, or for some business savvy entity to take it up and develop it for their own benefit. I suspect that a significant financial investment could certainly bring R3 up to speed quickly. Cyphre has said he could likely complete a Javascript port in a few months. Shixen and others may certainly be capable of helping. Perhaps they would be interested in the work if they were being paid appropriately for their time? The knowledge and the skill to perform the technical work of completing ports to platforms such as Android and JS is certainly availa. Cyphre is currently needed for the GUI stuff - he seems to be the only one capable in the community right now, but enough money could attract a new dedicated team of developers - it's just a matter of how much it would cost to hire capable developers to get up to speed and then to complete the required work. It's just money that's required. The same goes for getting people to manage community resources, marketing activities, etc. If there's enough money to *pay developers full time working wages, all of that is certainly possible, and right away even. There's just currently no *money in doing any of that - no investor has seen any opportunity related to continuing Rebol development or support.      If you want to build community, and make Rebol relevant again, get a Javascript port done, complete with R3-GUI, and ALL of R2's bells and whistles, so that Rebol can be used in the browser, on mobile platforms, and anywhere else that Javascript dominates for the near future. Get a complete release done for Android, also with ALL of R2's bells and whistles, and get it into the Play Store. Get a Mac port completed. Get all those ports documented, and keep them in sync, in one place. Put a nice web site together where everybody can communicate and get everything they need. That would bring Rebol back to life. There's just a lot of real development work which needs to be done on ports, before any of the organization, marketing, etc. can be begun. And no one yet has found the need to finance that development work (or provide it for free, for there own purposes). A language-compatible R2 version (with R3 running under the hood), would probably be helpful too (a great working proof of concept for R2 VID was started by Marco with vid1r3.r3 - language compatibility is certainly possible). Carl isn't needed to make any of this happen - just lots of money :) posted by:   Nick     23-Sep-2014/21:34:43-7:00 One of the obvious but not so obvious things the community seems to be missing is that Carl/RT has already granted the community permission to proceed. By releasing the R3 under the Apache License permission has been granted. Understanding this license allows for derivative works (ie a fork) and distribution of said work in binary or source form. All that is required by law is respect Carl/RT work and copyrights including possible trademarks.      Carl has already empowered the community to continue this work. Seems the community is stuck on semantics rather then focus. Would it be nice to have the Rebol domains? Yes. Would I even be nice to maybe have the source for R2? Yes. But in reality outside these two things nothing is stopping anybody from stepping up to the plate and moving this project forward permission has already been granted within the text of the Apache license. In my opinion the community is waiting unnecessarily for arbitrary things. Pick up the pieces rename the project to OpenRebol or RebolX both domains for this are available and clear I checked yesterday rebrand and move on. If Carl sees the community take responsibility rather then sitting around acting like Carl has to be involved in everything he might just surprise you and provide access to other things you never no. If I was Carl I wouldn't give this community nothing because they have not proved that there is one leader amongst them who will step up and actually do anything without him seemingly having to hold the communities hand. I can search the web and see all kind of discussion on how some didn't like the amount of control Carl introduced the project with in the first place. Regulating the master branch with authoritative scope, deleting the wiki without any discussions with the community, disappearing without regards to you or the project. All which was within his rights because you have him the power to do so. Stop sitting around waiting for a miracle on github street. I don't belive it's going to happen anytime soon and by the time it does this project will be a historic venue to the world otherwise it will be what the world said many times "a hobby project" yesterday I made a offer to assist with infrastructure and finances to pull this project together but rather then the community recognize and opportunity and step up to ENGAGE me in my offer ( said in my captain Picard voice" I watched thr SO feeds as some made fun of my name, some welcomed me, some wondered if I was none other then Sir Patrick Stewart you know, the famous one, others voice criticals that Carl would never respond not would he work with a newcomer or foreigner. Or things like it's a good ideal but maybe someone closer to Carl could take it and run with it may have a better chance if it happening, really if u had a chance it would already be happening lol bottom line is nobody actually said hey this guy is offering us some help to get this community together lets talk to him and see what he can help us with. I see now why this is not working. And for the record open source is not all about money it's a bout dedication money comes later after you prove your project provides value in the interim you as developers have to have a passion for the project enough to donate the time needed to get it where money can be realized. And in a project money comes in many forms sometimes is actual cash, sometimes it's hardware donations, sometimes its a developer who is assigned to the group by a company using the product and on and on bottomline is money fell in this communities lap yesterday and you balked at it rather then embrace and again ENGAGE me in any worthy dialog. Lol      posted by:   Patrick Stewart     24-Sep-2014/12:08:29-7:00 Patrick,      I think you've generally agreed with what I mentioned above. Yes, R3 was released with Apache 2 license, so Carl isn't needed. Yes, anyone can pick any domain and move on with their own product. No one here has found the need. If you're interested, I believe the way to engage would be to hire Cyphre to complete more of the Android port, and more important, complete JS and other platform ports. I'd be happy to get involved in making that happen, marketing, working on documentation, etc. I'm not calling for others to do it - just responding to your welcome interest. posted by:   Nick     24-Sep-2014/13:26:20-7:00 Patrick, Nick and I have donated a fair amount of money to help move Rebol3 along, among others. I understand a bit of your frustration about the lack of motion. I myself also feel that frustration sometimes. Normally, the way I deal with that frustration is to do something myself to help it move along, whether or not anyone else offers to help me. Because I don't have any time (I have way too many projects on my plate, many of them Rebol3 and Red related), sometimes I donate money to help others make things happen.      Do you know why Rebol3 has serial? I needed it for a project and I asked for help from the community, and they implemented it. I and others tested it, and now we have a working serial implementation.      Do you know why Windows drivers can be written in Red? Because I needed it for a project and I helped fund it's development.      My advice to you is if you think it would be a good idea to start a community fork of OpenRebol or RebolX, get feedback from the community (if you want), buy the domains, and fork the code. However, I think someone already forked the Github code to make a community repo.      What we really need are a couple of people who have the time and ability to move the Rebol3 project development along, especially coding. I personally would love to see more and better documentation, especially on things like R3-GUI and networking. posted by:   Bo     24-Sep-2014/13:50:21-7:00 I agree with both of you problem is I'm trying to help where I can im sure both of you will agree that the community first needs the tools to collaborate in an organized open fashion. I'm not advocating forking persay but how else can the community gain control over project scope 100 percent without forking the codebase in to a truly community repo?? Can I finace bounties for stories to be completed in an agile manner? Yes. Can I budget funds for part-time maybe full-time development? Yes. But my initial offer involves getting the community that does exsist United and with infrastructure so that work can progress with the professional presence required and expected of any decent project. I'm talking domains, websites, build farms, cloud infrastructure for testing, agile planning tools and project management tools. Once we can agree to give the community a home for those who want to be involved or consider themselves core developers then we can look at financing development task. Does this not appeal to anyone? Does it not make sense? If I'm gonna spend money I want to at least see genuine effort and professional organization from the community. So I'm making an offer of assistance any takers? posted by:   Patrick Stewart     24-Sep-2014/14:13:33-7:00 What I'm saying loud and clear is I hear we need this and really need that. Let me ask this, how do u expect to attract people who will do these things being unorganized with out a mission statement or professional presence? posted by:   Patrick Stewart     24-Sep-2014/14:21:54-7:00 it's not worth pouring money into REBOL. it is a dead horse. the few people still around don't have the ability to move it forward. they can fix a bug here and there, but that's not enough skills to move it forward.      better support RED development. THERE IS A LEADER, and a team who are actively developing RED, and they did not wait for rebol to become open source, to break away from Carl's grip.           posted by:   xxx     24-Sep-2014/22:27:52-7:00 This is an interesting thread.          Nick: " Cyphre has said he could likely complete a Javascript port in a few months... If you want to build community, and make Rebol relevant again, get a Javascript port done, complete with R3-GUI, and ALL of R2's bells and whistles, so that Rebol can be used in the browser, on mobile platforms, and anywhere else that Javascript dominates for the near future."      Going off onto the other things which could be done beyond that is too big a chunk at this point. (1) Is there agreement this would be the most useful first target (making it an alternative to coffeescript....would be an interesting contest)?      (2) Other than R3-GUI support, which is obviously critical for a web client development language, how much is missing in R3 vs. R2 functionality?      (3) Would you please approach Cyphre and ask if (a) he is serious/certain and (b) how much it would cost?      A "few months" of development time for only one developer? Really? Seems like the community might raise enough from recycling beer bottles to cover that! :-/ posted by:   Steve Jr     24-Sep-2014/22:37:59-7:00 I'd be willing to donate to a JavaScript port of Rebol3. posted by:   Bo     24-Sep-2014/23:01:47-7:00 Patrick, so what do you want the community to help with first. Let's take it one step at a time. posted by:   Bo     24-Sep-2014/23:02:39-7:00 Ok, First off Nick, I appreciate your offer to help with marketing, working on documentation, etc. and Yes it would be appreciated I have seen most of your books and tutorials you are the man for sure.      XXX, While the Rebol community is currently stagnated I disagree that it's a dead horse and most certainly is worthy of some attention let's be respectful in saying Carl created something magnificent it is worthy indeed. In my opinion if there is even the slightest interest it can be revived. Consulting with Nick on a good marketing strategy can indeed put some spunk in this mission. Marketing is the key to reviving Rebol once we have a solid mission statement and project blueprint. One other thing that can help push Rebol is for the team to develop a reference implementation for consumption. For example: If we created a ERP using Rebol as a Reference Implementation on what Rebol can do that in itself is a consumable product that can get SMB's using the project.      Bo, The very first thing I would like to get from the community is a decision on how they would like to proceed. I would like for those who would be participating to identify themselves so we know who's who going forward and can gauge participation moving forward. For me to do some of the things financially that I will do, I need to see at least 4 community members who would like to become core developers. I would need to see at least 1 community member who would handle documentation. I would like to see 1 community member responsible for maintaining the build farm. I would need to see at least 1 community member who would quality control public "stable" release drops. I would like to see 1 community member responsible for overall project management. And myself and my assistant will participate with the community as providers, consultants and administrators. SO in total I need 8 members from the community in the specified capacities.      Once we have these key players intact any other community members will be free to join as contributors, users or whatever their role is either directly or indirectly.      we need to come to grips that we may need to establish an "OFFICIAL" community fork and what it's going to be called some suggestions trying fall in line with other projects that have had to break away would include OpenRebol, RebolX, FreeRebol etc Please throw all concepts in the hat and we can vote on one. Understand this is necessary until carl donates the Rebol TLD's to the community and we should hope that happens but until then the community needs it's own home. At such time that carl decides to donate the Rebol domains If he ever does a simple DNS record can point them to existing infrastructure overnight.      We need to talk branding, If the current branding is the communities then if we choose another name to function under we may need to modify the branding to reflect that change. If their are designers inside the Rebol community stand up and be counted lend us your knowledge, if not I have designers available to assist.      Once we can get through these very basics of getting the community aligned I would like to empower the community by providing the following:      1. Atlassian Starter Suite for the Core team members including, Jira, Stash, Confluence, Bamboo, Fisheye, Jira Agile, Confluence Team Calendars, Jira Service Desk, Jira Capture and a few other Atlassian tools. Understand this will be online available to all core team members in a similar fashion. ( note the domain is for illustration only)      www.openrebol.com = basic pointer site that provides links to the other project and community sites. Can host RSS feeds that pull from the developers ques to provide updated status of the project. If we can revive interest in the project and create a reference implementation that can be used in SMB and enterprise business we can make that available at the .com as a product that can generate a revenue stream to feed the core developers and their support team i.e documenters, builders, release managers.      www.openrebol.net = this is the network domain and will be the home of all project tiers. openrebol.org will be pointed to this domain but this is where it all happens. We will install a sharepoint style application here where all members of the community can have accounts and workspaces. this site will have a public facing internet a secure intranet and as many workspaces as needed. Each workspace is capable of being served by DNS entries like xxx.openrebol.net in a multisite configuration.              1. issues.openrebol.net = core developers jira instance         2. wiki.openrebol.net = core developers confluence instance         3. git.openrebol.net = core developers private github ( actually more like bitbucket)         4. sso.openrebol.net = single sign on crowd server and OAuth Server         5. review.openrebol.net = repo viewer and code review tools         6. build.openrebol.net = bamboo build servers in the cloud/continuous integration         7. office.openrebol.net = here we will launch an Office365/Google Doc type application for the work side of things.      Understand that these domains are for a mix of community and developer or core team only situations or use. for example any team member will be able to use the systems located at the www TLD and the office subdomain but all other tools are for the internal work of the core team only.      the source code from the private repositories will be synced with public ones on github, sourceforge and any other FOSS where the community wishes to push the releases and source. understand this is good for marketing as the project becomes visible in many places to many users and other developers. non-core members may view any public information at the wiki, git and jira instances and will be able to file issues from multiple locations. However non-core members have a home here too located at the RDN or rebol developers network as follows.              1. rdn.openrebol.net = community site for non-core developers, contributors, potential users         2. trac.openrebol.net = a community trac instance that holds mirrors of the stable tree and any community branches or forks             that do not belong to the core team. Non-core members can raise tickets, use wiki's pull, push and commit             community contributions. these task can all be merged back into the mainline at git.openrebol.net after review and acceptance                 into the mainline.         3. Other community sites as identified by the community.      The system by default is agile so any trello cards can be pulled into the scrum boards or kanban system inside Jira. The system is highly optimized and connected for enterprise level project scope. I'm looking for the real dedicated from the Rebol/Red communities and will consider adding additional licenses to the suite as genuine interest to join the core team is displayed. Atlassian products are not cheap so we don't want to have licenses that are not going to be used by a dedicated member just siting around.      This system will be deployed in a cloud based on the OpenStack system developed by Rackspace and NASA on dedicated MacMini Servers located in Phoenix, AZ and Milwaukee, WI. The Servers will consist of a mix of bare metal VMWare ESX and Zen Hypervisors controlled by the OpenStack system housed on Ubuntu Servers also installed on MacMini Servers. We will deploy a few OSX Server installations to provide DNS, DHCP and network services to the grid. By using MacMini's we can spin up VM's for any OS supported on Intel hardware including OSX, Linux, Windows, BSD and many other OS's. The main point in using Mac Hardware is Apple's SMC instruction and licensing that prohibits launching OSX VM's on non-apple hardware. By using authentic hardware we can legally add OSX Servers to the Build farm for OSX builds. We may add Additional Servers in Atlanta, GA and also partner with VPS.Net accessing their API to spin up resources in their global datacenter as needed. I'am setting the stage for the team to be able to generate revenue streams to support the mission as well. By deploying this cloud it provides an opportunity for the community to sell cloud services that are AWS compatible to the general public as a way to feed our team so they can get the work done putting money in their pockets.      We can also put in place a bounty system where dollar amounts can be attached to feature request (i.e porting to javascript) which the community can support to get that feature implemented. Myself as well as other community members will also most likely donate funds to the developers to make things happen as well without regard to bounties or additional revenue streams.      Once we achieve a certain state and have clear defined goals we can also launch a kickstarter campaign. This will surely come later and most certainly after the reference implementation is introduced to the world.      It's getting late for me I'am currently out servicing my customers in South Carolina, then off to Boston, MA. I believe this is enough to chew on for now that will hopefully get the ball rolling. Please this is just an ideal any and all debates, changes, ideals are welcomed for integration into this offer. It's not about me it's about Rebol and the community so please help me to get this right for all of us. I'm a serial entrepreneur currently running a 3PL logistics entity contracted to one of the world largest carriers that has much to offer the community. we can take it slow and progress into some very powerful venues if you give me a chance.      Also, I read Hostileforks slides he presented in Montreal      So Bo, Nick and Community I present something, a plan of action to you we can hash out all the facts and details together I only am trying to put something on the table. Let's work it out and make it happen. Understanding this includes Rebol and Red communities as it's obvious that as previously said Red will be the natural successor to any legacy Rebol system including R3. Their contribution is important and also must be supported.      Thanks      Patrick Stewart                          posted by:   Patrick Stewart     25-Sep-2014/1:10:21-7:00 Patrick, do not misunderstand this. All Patrick Stewarts are evenly welcome to join this community. Even if their name is not Patrick Stewart.      Thing is though your interest and willingness to invest time and money into further development of these beautiful languages is for real, there is always the thing that "when something sounds to to good to be true, it probably is".      So please understand the hesitation and take little steps at a time. posted by:   Arnold     25-Sep-2014/3:56:36-7:00 Arnold, no misunderstanding taken, to be clear i was surely born Patrick Stewart so have no doubts that is my real name. I do believe my steps are very small in that I only present a plan of action that is by no means concrete but simply somebody stepping up putting something on the table for community consumption. These things I have talked about are only baseline targets that can get things in a organized flow then the real work begins. First step to any professional organization must be presence, tools and concept. This is all I am talking about here.      Now i can show you better then I can tell you how real this offer is but if I do that then it would require me to sidestep the communities input with the hopes that If iI build it they will come, which is wasteful when it comes to spending money if things might change. Yeah not doing that as I believe the better course of action is to solicit community participation so all parties involved are apart of the founding process and voices get heard. I'm not a one man band as is no successful venture      If I wanted that I could just fork the code and hire some developers to track your request and implement features without involving anybody from the current community to which I am more then capable of doing. But that in my opinion would be disrespectful to those of you that have paid your dues, besides, multiple minds always kick the ass of one, so I choose not to however, don't be mistaken if the community studies long it studies wrong , meaning if I get bored going back and forth trying to motivate the community or no progress is being made I may just do that to satisfy everyones curiosity and skepticism's.      This is not some case of a forum troll playing games, this is not a spam bot posting nonsense, i am real, my offers are real, my intentions are real, and i have identified myself for reals.      Call my bluff, and see what happens,what do you got to lose i mean after all I am not asking the community for anything I come offering something to empower the community. posted by:   Patrick Stewart     25-Sep-2014/4:47:15-7:00 The main issue I see at this time is that pull requests are not merged into the root repository created by Carl. Patrick: I don't think the REBOL community misses an infrastructure. We all ended on github and this might just be the right place to merge all individual efforts whether it is code, test or documentation. Again what we miss, is someone to review/merge the PRs. posted by:   GregP     25-Sep-2014/5:05:42-7:00 Hi Patrick,      You'll find a lot of shared sentiment that there needs to be organization. No one is more empathetic than I. But here are some things to know...      Carl agreed to the plan of keeping rebol.com to himself, and giving rebol.org and rebol.net to the community. That would presumably include handing over the responsibility for paying for the domain names as well as giving them over to a community-managed account. But we return to the same issue of what account is the "Rebol Foundation" and who administrates it. This does not change if you call it "openrebol.net" (and it's a longer name also).      There have been efforts to create new URL schemes that would be long-lasting and serve as (for instance) the new help service. For instance, a test site for that is here:      http://help.rebol.info/append      I myself despise HTML/CSS/JavaScript...despite knowing a fair amount about all three. I'll only work with it if I'm forced to. But resident CSS expert Christopher Ross-Gill has designed a CSS dialect called "StyleTalk" which he uses:      https://github.com/rgchris/StyleTalk      It's incorporated into Rebolek's "Low Entropy Templating System", which integrates with Twitter Bootstrap:      http://lest.iluminat.cz/      Building a stronger web presence for Rebol faces a challenge, because the volunteers involved do not want to use junky tools to build it as a means-to-an-end. If the Rebol community were a corporation trying to sell a product, you should fire all of these people immediately. Their tinkering is holding up the PR machine. But it's not a corporation at this point. The only people being paid are those working for Saphirion and Atronix--and they're not being paid to make Rebol community websites. In the absence of a paid incentive we work on whatever things we enjoy doing (for instance, draw icons) and we like our tinkering because we are going deeper into a design space.      So the demographics of the group you are walking into is people who solve their own problems with Rebol and find it very handy and pleasing. It's a swiss-army knife that we also happen to enjoy chatting about...and trying to find ways to teach others to enjoy its unique properties. As we wait for Red, we hammer over questions of naming and design that affect both languages. To pick a random one: should FIND of a CHAR! in a BITSET! be case-insensitive?      >> find "abc" #"B" == "bc"      >> find/case "abc" #"B" == none      >> find charset [#"a" - #"c"] #"B" == none ;-- I consider this to be a bug      >> find/case charset [#"a" - #"c"] #"B" == none      You might think that people would easily agree on whether that is a bug or not, but it's not as simple as it seems. (Carl and Andreas consider it a bug. Kaj and Maxim consider it a feature they can use to wedge case-sensitive behavior into a case-insensitive parse).      Are we wasting time to talk about it? Well...the project is a long meditation on Quality within a certain design space; it has something in common with Haskell in that spirit, while having totally different goals. When I first met Carl at a party and was trying to stress the importance of why he should open source Rebol, he said he wasn't keeping it closed for reasons of finance or secrecy. It was because he "didn't want people messing up [his] art".      Red wants to take all the best ideas and findings, but has more directed priorities. Nenad just used Blogger for the red-lang site to get it over with and get to work. Rather than using his own custom bug database written in Rebol (that Rebol still uses), he adopted GitHub issues. While intrinsically a cross-platform vision, he's staying focused on Android...and trying to not get distracted with reinventing scroll bars from the ground up so they work on every desktop platform.      Nenad moved to China, where Red is sponsored by InnovationWorks...and both he and Qtxie work on the project full time:      http://www.red-lang.org/2014/01/year-of-horse.html      Regardless, I don't think either existing community can very effectively use the resources you list (Jira, Stash, Confluence, Bamboo, Fisheye, Jira Agile, Confluence Team Calendars, Jira Service Desk, Jira Capture). The scale simply isn't there.      If you have money to spend, and influence to peddle, I'd suggest looking further into Red and its implications. I'm sure Nenad would appreciate a U.S. evangelist who is business-savvy...who can arrange meetings and repeat his demos; if you find that fits your bill. He's going to be presenting at a large Chinese mobile conference soon, creating a deadline for a showy demo of version 0.5.0.      My "Rebol plan" is still the one in the slide deck; although momentum has sadly been lost since then. I don't think it's because the plan wasn't good enough; I think there are just some realities of the landscape. Most Rebol users were not experienced C programmers, and Rebol is written in C. That limits people's ability to be involved in improving the source, and those improvements coming from people who do know C (like me) haven't been integrated, which does not incentivize spending any more time hacking on it.      Hence my bias to say just to stay the course with Red; and if interest flows back into Rebol because of Red's success...so it goes. We could get a little shot in the arm if Carl goes through with delegating integration on GitHub so things can get flowing and see what happens there.      Other than that, "nobody here but us chickens" -- as the saying goes. :-) posted by:   Hostile Fork     25-Sep-2014/6:26:35-7:00 > If I wanted that I could just fork the code and hire > some developers to track your request and implement > features without involving anybody from the current > community to which I am more then capable of doing.      You may already be aware that there are two companies (that we know of) working on Rebol with an independent agenda:      http://atronixengineering.com/downloads.html      http://development.saphirion.com/rebol/saphir/      Of the two, Atronix is the more public. Their commits and code are open source. The only really "proprietary" system component they hold back is a driver implementing industrial automation protocols.      Saphirion holds its cards to its chest a bit more. They have not--to date--released the source for building the Android app. (Note that we do have an NDK build that runs on Android at the command line, however.) They did release a version of their /core and /view at one point in time, but have not been making their changes public since :      https://github.com/saphirion/saphir      But they collaborate with Atronix on the GUI work. So presumably some of the changes they've made in the meantime are integrated into Shixin Zeng of Atronix's repository:      https://github.com/zsx/r3      Our hope in consensus building is to try and outline what makes it into the community build. Currently there is no GUI code in the main Rebol repository.      That's sort of the lay of the land with that. If you are focused on the business angle of Rebol application, then you might get in touch with Robert of Saphirion.      http://development.saphirion.com/ posted by:   Hostile Fork     25-Sep-2014/7:06:26-7:00 Speaking as a person who likes to use REBOL but is not qualified to help its development, I can say what I would like to see. I would like to see REBOL 3 have some name that would identify it. REBOL is the obvious choice, but REBOL3, openrebol, etc. would be fine with me. Then, I would like to be able to go to the web site for that language and download the interpreter in one file, just like R2, and use it. In addition, I would like to be able to purchase through that site a PDF of a good reference manual for some appropriate price, maybe $19.99. Finally, I would like to know that the REBOL interpreter would be updated as needed for new operating systems or bug fixes.      I wrote a demo application at work in REBOL, but it was not adopted because all I was able to say about the programming tool I used was that hardly anyone else uses it, it is unsupported, there is no development taking place on it, and it is not even known if it will continue to exist in the future.          As to how to accomplish the above, it appears to me that it is a good example of how the most difficult problems to solve are not the technical ones, but the political ones.          Not wanting to whine without offering a solution, here is an idea. Yes, I fully realize this is quite short implementation details.      1. Pick a name. 2. Make a web site. 3. Obtain a version of REBOL. Here it gets political. Is either the Saphirion or Atronix version considered to be the de-facto official version? Are they complete enough to be similar to R2 in usefulness? Would either organization allow copies of their versions to be on the new official REBOL3 site?     4. Find some community members who are willing to "reverse-engineer" the documentation. In other words, use R3 and R3-GUI, scrounge up all existing documentation, sample scripts, whatever, experiment to fill in any missing details, and produce that twenty-dollar PDF of documentation. Nick seems to be the premier REBOL documenter, but I would be willing to help in that area.          To head off the obvious criticism, I do realize that a person can download and use the Saphirion version, I do realize that Nick has produced gobs of documentation, and so on. My point is, a person wanting to use REBOL has to seek out those things. For a person like me, there should be one place to go.                posted by:   Steven White     25-Sep-2014/10:03:29-7:00 All good points. I agree with HostileFork that we enjoy "eating our own dogfood" (aka using tools we created instead of off-the-shelf products). I agree with Steven White that it would be great to have a single site for executables, documentation, etc. I agree with Patrick Stewart that we need someone to jumpstart the community development again, especially if that meant some lucky developer(s) could be paid to improve and implement features.      In my opinion, the Atronix version is the one to use as it is available and Shixin shows up on the forums from time to time. posted by:   Bo     25-Sep-2014/16:48:35-7:00 BTW, the potential for PAStewart's positive energy and resources for the community leave me hopeful that some more positive forward motion will occur soon and will provide a rallying point for those of us that believe in the Rebol/Red ecosystem of languages. posted by:   Bo     25-Sep-2014/16:55:59-7:00 I agree with key points made by Brian (HostileFork) and Nick. And seeing Patrick's enthusiasm and support is very exciting. One of our challenges is building trust in the community. How do we get people to contribute? They have to feel they and their work are valued and useful. Having a flag to rally around really helps as well. We are a small group, and if we have 3 or 4 flags, it divides us (even if not intentionally). A leader, resources, and getting organized...that would go a long way.      Commercially, it's time for me to move away from R2. And I want R3, Red, and Topaz (like Nick, I think a JS port would be useful; I can't avoid JS any longer it seems) to be viable options (Boron, World, and others are welcome as well of course). As I've said in the community before, my value lies in certain areas, and I want to contribute where I can.      posted by:   Gregg Irwin     25-Sep-2014/18:59:19-7:00 Patrick,      It sounds like you have the ability and the means to complete every aspect of an "OpenRebol" project. If you provide the leadership, I think that you'll find support among whatever community is currently active. But I think for a project of that scope, you'll need to enlist more than those who are currently available in the community. Of course you can save yourself a tremendous amount of effort, time, and money if you get the few technically knowledgeable developers currently intimately familiar with the R3 code base (Cyphre, Shixen, perhaps Hostile Fork, and maybe a handful of others) to help organize and perform the porting work, but I think that what you envision needs more people than those who are actively working on/with R3. As Fork pointed out, your methodology and tools may not be familiar to those who are currently involved. But more important, the goal of creating a tool which can be relevant and useful to a larger community, necessarily requires attracting more actively involved developers. I don't think you'll even find your 4 core developers among the current crowd.      So, what should come first to attract a new community? The marketing materials, the support infrastructure, the documentation, the code and executables, etc.? From my point of view, it seems that nothing will attract interest more than a functioning tool. Once an "OpenRebol" product exists (I think OpenRebol is a fine name), then some formal infrastructure to support it can be built, and then people can be let to know that it exists. I think getting Cyphre involved is critical, if you want any part of the effort to gain an initial foot hold. A relatively small investment in his time would do more good to get things moving, than anything else which anyone could do right now. I don't know what all your eventual goals may be. Perhaps you hope to see Rebol evolve to become the primary development tool to power your own commercial interests. Perhaps you see a market for the commercial support of a successful platform. Perhaps you're interests are strictly altruistic, artistic, or otherwise devoid of other financial motivations. But if you want to see any such goals achieved, I think the fastest way there is to get Cyphre (+ Shixen and/or whoever else is currently capable of helping) to provide you some basically completely functional products - tools which others can immediately see the usefulness of, and put to use on modern platforms, then you may as well start from scratch with a team of hired developers. You seem to have the means and ability to do that. I think in this case, you need to build something before anyone will come. If you do that, I think you'll find the support of not only existing community members, but also a wider audience. Make something which is truly powerful and clearly better in many ways than other tools, and you'll find plenty of developers willing to give it a try. With R3, you're really most of the way there. It just needs to get completed and ported to the right environments, with all the bells and whistles. As far as I can tell, Cyphre is the only one here capable of bringing it the rest of the way, very quickly - I think he just needs to be approached and payed well enough to clear his work schedule to actually do that work. He can pave the way for other developers to get involved. Build a product first and you will attract the interest needed for success. Make the mistake of building the infrastructure first, and you'll just watch people hope for others to do the work. If Cyphre isn't available, then bit the bullet at get together a team of fresh developers to learn the code base, pay to get critical ports done, and you'll see people get involved, because they'll have a tool they can use, and they'll want/need to see more progress. I don't think it's necessary to put together a methodology or infrastructure for that first phase. Just pay a few guys to do the work. Cyphre did the Android port in a matter of weeks of dedicated work. Once a pile of useful ports are done, then you'll have something real to organize, web sites to build, marketing to do, and people motivated to take part in that organization - not just from the existing community, but from anywhere else you can find like-minded developers. Get past that first phase and you'll have something to work on.      To be clear, I don't think you need anyone else's approval. Set up whatever methodology, tooling, and infrastructure you feel is most effective. You clearly have your own preferences. If you create a project which is successful, you can organize it however you feel is best. If others feel that the project is worth while, they'll do what they need to get involved and make it work. But nothing will happen until that first step of getting ports done for critical modern platforms is completed. posted by:   Nick     25-Sep-2014/23:03:39-7:00 Instead of Topaz: an asm.js backend for Red is the way forward. And a finished emscripten build of Rebol.      (We actually had an emscripten build of Rebol, but it seemed no one was all that interested in it.) posted by:   Hostile Fork     25-Sep-2014/23:52:12-7:00 Nick      I agree with everything you and the others are saying here but one thing that I was also thinking and Hostilefork said it to is that and I quote      "Most Rebol users were not experienced C programmers, and Rebol is written in C. That limits people's ability to be involved in improving the source, and those improvements coming from people who do know C (like me) haven't been integrated, which does not incentivize spending any more time hacking on it. "      this brings me to a question... would it make sense to pay to port Rebol to another language so more people could get involved with developing I mean Hostilefork has a very valid point. Doings so could also make it easy for some of the other critical things you mention about modern systems to happen.      for example and this is just an example, GNOMe project has Vala which is close to the C family (i,e Java, C#, C, C+++) but makes writing code that still compiles down to native C doable for those who don't know or want to write in ANSI C. Also what about a port to Haxe, if we ported Rebol to Haxe we would get up to modern real quick as Haxe compiles down to many targets including C++, Java, Javascript, PHP, C# and a few others. I don't see where it compiles to C but I would imagine if we created a Vala target for it then it would indeed as Vala compiles to C. If we can port Rebol to Haxe wouldn't we mitigate some of the modern issues by default while also being able to deploy Rebol in many different environments and platforms. Have a certain project in mind only requires the right target to be used and bam. Just a ideal seems like since it at minimum compiles to javascript that concentrating on porting to Haxe will solve several issues. Am I wrong in this thought process? I mean that is even if it's possible. posted by:   Patrick Stewart     25-Sep-2014/23:58:12-7:00 Well ok Hostilefork, doesn't emscripten compile down to javascript? that's my understanding so if everyone is asking for javascript and you have an emscripten build whats the problem??? posted by:   Patrick Stewart     26-Sep-2014/0:04:46-7:00 Patrick,      I once proposed a minimal Qt-based C++ implementation of Rebol; which could just take the Unicode services and cross-platform GUI for granted. The executable would be fatter than the Rebol crwd would care for, but it would be easy to write *if* there was a clear spec. I called the proposal "freebol":      http://freebol.org/      (It might interest you that Douglas Crockford, one-time Rebol fan and creator of JSON and JSLint, had his own aspirations to make a port called "freeball". But he decided to take what he could from Rebol and put his bets on a more vibrant target...the evolving HTML/CSS/JS ecosystem...as gnarly as it was by comparison. He's famous, while Rebol loyalists have toiled in obscurity. Draw what conclusions you wish from that!)      That was all long before Rebol was open source, and when Red was not an obvious front-runner as being a viable and serious project. Also, I thought the byte count of the Rebol executable was a very tangential point to the mission. But times have changed, and so has my perception about what the mission is.      The main block for an emscripten build is that no one knows quite what to do with it. You have a Rebol binary in a browser...now what? We can do something like:      http://repl.it/languages      But it's a bit heavy to send something the size of a YouTube video over to someone's browser, just so your webpage can run a PARSE (or whatever). I thought the best application would be for interactive tutorials.      It's quite possible to re-implement Rebol in other languages. But why would you? Any effort that would be spent trying to re-implement Rebol in another language is better invested in getting Red to market faster. If you are compelled by the coolness of Rebol, do your homework and see if you're not sold on Red. If you want to talk about a project that you could inspire and hire for, that's the ticket.      Please do watch the Red video start to finish. Twice!      https://www.youtube.com/watch?v=H4kMlOkN894 posted by:   Hostile Fork     26-Sep-2014/0:33:48-7:00 Porting to something other than C makes sense if you want to attract a new audience, or if details are hidden. If you want existing community support, remember that what draws a lot of people to REBOL is simplicity. As a user, give me a blessed binary without dependencies and I'm thrilled. Haxe may work for that, or leveraging the existing R3 source may be better. I can't say. It seems like R3 just needs to have some holes filled and some pieces added. I don't know what all is missing, but finding out is something I can help with.      Red/System is another option, but with a longer timeline as it's so young. As one of the converted, I would be much more inclined to work in that than Haxe, et al.      I still believe in having a minimal native core and building as much at the mezz level as possible. Let REBOLers work in the language they love, let them contribute, and they will come. Something like that. ;) posted by:   Gregg Irwin     26-Sep-2014/0:54:28-7:00 When I started to learn REBOL I was attracted by the fact it was a high semantic level language allowing me to produce more things than if I was doing the same thing in C, AND I was also attracted by its availability in multiple platforms. When the R3 project came out, I didn't jump in because I had other REBOL projects I wanted to work. Building R3 in C was clearly another story and yes, it reduces the scope of available REBOL contributors. Now, there is no way I want R3 rewritten in something else than C. C is the best option. Even if we love "drinking our own wine" I think github is our best option for now to centralized all contributions. BUT we need to make a github organization (https://github.com/blog/674-introducing-organizations). This organization model avoid having only one focal point that should always (=burden) be available. If a few of us could manage/administrate this central point, this would avoid any bottleneck situation like we face now. Could we just try this? posted by:   GregP     26-Sep-2014/3:50:04-7:00 Started https://github.com/openrebol and sent some invitations for additional owners.      At this point of time, we don't necessary need another website as github can handle static webpages, wiki and code repository. Anything great you contributed for REBOL could be centralized here and anyone could PR as well. It is multiple owners, meaning it belongs to nobody, only a common objective to move REBOL forward. posted by:   GregP     26-Sep-2014/6:07:16-7:00 I will point out that one thing an OpenRebol can't take with it is the Rebol logo I've made.      (It's one piece of de-fragmenting influence...)      The "Freebol" name, domain, and logo I have delegated to Andreas.      http://freebol.org/      So if anyone is interested in that, they can speak with him. posted by:   Hostile Fork     26-Sep-2014/7:06:38-7:00 Are you referring to this logo? http://www.rebol.net/w/images/a/a6/Rebol-3d-160x160.png Is it possible to clarify under what license fall this logo? posted by:   GregP     26-Sep-2014/7:27:06-7:00 @Hostile Fork, boy, you know how to create your own work! New logo needed for a Rebol related project! posted by:   Arnold     26-Sep-2014/8:03:57-7:00 In the absence of a formal statement of license, graphics default to All Rights Reserved by the creator (unless otherwise specified). Of course we've let people put the logo around and about without complaint so I should be more specific about what the otherwise specified is.      The one thing I've said that it's "whoever is protecting Rebol's trademark" that gets to say how the logo is used. Technically that would be Carl, not me.      (So really what I'm expressing with my statement there is that if you fork Rebol...I will write Carl and ask "Please tell them not to use that logo.")      We've been lax about it so far. But I have tried to write up a bit more explicit legalese for the Red logos:      https://github.com/red/branding/blob/master/LICENSE      For understanding of the general intent behind it, compare with other popular branding terms in the greater open source community:      http://www-archive.mozilla.org/foundation/identity-guidelines/firefox.html      https://creativecommons.org/policies      https://github.com/logos      It's always been all right to fork Rebol's source. But you can't call it Rebol. Not that anyone today has the money and attention to file any lawsuits over it...it would have to be someone big enough that lawyers would be willing to work for free to sue, if they can have a cut of the proceeds. :-) But despite the lack of likelihood of anyone making a federal case out of it, we can still ask nicely...and stay on best terms by respecting the nice asking.      The actual leverage is not in copyright court. It's having the paper trail and precedent set. That way, if someone puts a forked version in an app stores and tries to use the logo design, then there is some leverage to point the app store to saying people aren't supposed to be doing that.      For a motivating case of why it's worth worrying about this:      http://www.theverge.com/2014/8/27/6076381/microsoft-windows-store-fake-apps-crackdown      That's why I'm bringing it up early.      Of course, it's nice to use the logo to help promote Rebol as the community understands it (in Bo's articles in Odroid magazine, for instance...or on the RebolBot). If you're not forking the codebase and just advertising, I'm not suggesting getting on anyone's case.      But if someone is going to take their own direction with the code they need another name and logo (Saphir, etc.) posted by:   Hostile Fork     26-Sep-2014/8:04:50-7:00 GregP,    And that is what happens when you don't wait for a community consensus on what is going to happen and Just how it's going to happen. While I can appreciate your enthusiasm and desire to set the stage, conversation in this thread were not done to the point you need to start another repo called OpenRebol. In the first place that name was used as an example and was clearly stated that is was so nobody here actually had agreed that if we did fork the project what it would be called. Kinda jumping the gun some. And soon as ya did that next thing ya know is folks is gonna be like hey buddy ya can't have that and no you can't do this. Gotta play the game right and the right way is for the dialog that was happening to continue till those who are engaged in this topic besides just yourself come to some terms.      Just saying, this is a delicate matter folks have invested money, time and energy into things regarding rebol now like Hostilefork said might not get sued for it but unethics can sure piss folks off and in the FOSS world u piss folks off u get black balled right out the gate. We don't want that at all so even though I'm being stern in my attempts to find out what direction the community is willing to take, and how we maybe can get there I'm not advocating stepping on anybody's toes like that. We need the community in the interim and indeed in the long run if any fork or branch of Rebol is to survive period. I'm trying to do what works for the community and a lot of good stuff is beings brought up in this thread and I am trying to walk down everything being said and investigate every link being presented myself so I understand what I'm being told I'm the conversations that are directed at me. Let's not wait to long to decide but let's not also move without some sort of pulse from the community either.      Just saying . posted by:   Patrick Stewart     26-Sep-2014/12:40:03-7:00 People to who the name and logo matters are welcomed to talk and the name and logo can be adjusted accordingly. I personally like the idea a repo like this can be maintained by some well known and long time Rebolers. I don't mind excluding myself from this group as I can always contribute to it by PR. What I find interesting is that nobody has to be full time on it to continuously manage it. Now, if we're unable to collaborate to the same repo, we'll continue to google things, watch inside AltMe, SO, ... posted by:   GregP     26-Sep-2014/15:29:29-7:00 There is mainstream C compiler support on just about every platform. In that way, it is perhaps the most portable of all languages, and there are millions of deeply experienced developers using it, so I don't think porting to another language would be helpful from that point of view. Porting it to Java could be a real winning marketing strategy down the road, but I wouldn't do that now (there's a huge existing Java community, but needing to learn the Java ecosystem, just to implement Rebol, would keep the rest of the world away). Working on a Haxe port seems more like the type of thing which might be done by hobbyists if some Rebol flavor were to ever become popular (Haxe is based on Actionscript - I don't even know how R3-GUI for example, would be implemented). Rebol was conceived in C and already exists as mature C source code, and as Cyphre has demonstrated on Android, mainstream build tools should be able to handle the port without any major problems, on just about any platform. Andreas has already worked a bit on an Emscripten build, and Cyphre has chimed in about the potential for building with that tool chain, using WebGL, etc. I wouldn't even think about approaching a source code port until there are some well established native (compiled C) builds.      There seems to be some confusion about what's meant by porting to JS. The idea is to port the entire interpreter, with R3-GUI (+), to Javascript, so that it and any R3 script can be included and run in any web page in any major browser. Because web _is_ now the default cross platform deployment environment, that makes Rebol apps immediately accessible on every major, and new (and future) platform, and in most cases, there are simple packaging mechanisms to make 'web apps' appear to be native apps, complete with very good performance.      posted by:   Nick     26-Sep-2014/20:11:19-7:00 Nick, Actually      Haxe is more of a high level strictly typed object orientated programming language that represents the core language of a cross-compiling toolkit. It is not ActionScript it only try's to follow ECMAScript standards which includes Javascript, JScript and ActionScript. Haxe is an object orientated expressive language designed for the project with a feel of Java, Actionscript 3 and C# which would make it more then capable of producing a Rebol interpreter that can compile in many different flavors because it compiles down to actionscript and C++ and Javascript and C# etc. it's a way of writing in one language but spitting out binaries for multiple systems or targets. Think cross compilation Actually it would be no different then it is now per say, the system would just be written in a expressive preprocessor language but the resulting binary would still be a native C binary. Only difference here is you can compile to multiple targets including javascript. Haxe represents exactly what Red is trying to do with Rebol in creating a Full Stack Development toolkit that targets a cross compilation schema as Red is trying to do the same thing with C#, Java and Objective-C bridges only Rebol is the main language instead of Haxe.      So in reality rewriting the Rebol interpreter in Haxe would allow Rebol to be compiled in C, C++, Java, Javascript and C# So indeed a port would have massive benefits in this regards      1. It's a write once, compile everywhere, run everywhere scenario. 2. It would attract those who may be interested in a project like this who cannot write in ANSI C. 3. you can target iOS, Android, Web and Desktop using cross compilation targets all from one codebase.      The end result if care was taken to write optimized code in Haxe the same as it is in C would result in a optimized C binary or Javascript implementation. which would in my opinion yield the results that the community is looking for. And trust me when I tell you Haxe and Red share the same concept in that Red has goals of targeting the JVM for android, Objective-C for iOS and the CLR/.NET Runtime same concept all in all just from the Rebol perspective for certain objectives where Haxe is focused on being a cross platform toolkit to enable write once, compile everywhere, run everywhere.      SO i think your missing the point, which is a Haxe port would instantly allow the Rebol Interpreter to be cross-compiled into Javascript for Web, C for Desktop, Java for Android, C# for the CLR/Rebol.NET, ActionScript for Games and so on Haxe provides 9 different targets for cross compilation. I can't see this as a bad thing if it was to happen. It puts the Rebol way of doing things in 9 different targets with unprecedented cross platform specifications.      And to be honest your saying a port to Javascript is needed however Haxe is following ECMAScript standard to which javascript is a part of for the power Haxe provides over Javascript and because it can compile to javascript I would pay for a port to Haxe before I would for javascript alone it would accomplish the same thing your wanting but open up other platforms as well.      Just Saying posted by:   Patrick Stewart     26-Sep-2014/23:58:35-7:00 Nick      You said "There seems to be some confusion about what's meant by porting to JS. The idea is to port the entire interpreter, with R3-GUI (+), to Javascript, so that it and any R3 script can be included and run in any web page in any major browser. Because web _is_ now the default cross platform deployment environment, that makes Rebol apps immediately accessible on every major, and new (and future) platform, and in most cases, there are simple packaging mechanisms to make 'web apps' appear to be native apps, complete with very good performance. "      To be clear there is no confusion on my part, I just feel if your going to put in the effort port the interpreter to javascript then port it to Haxe instead and gain 9 more targets including the web_is_now javascript. posted by:   Patrick Stewart     27-Sep-2014/0:11:11-7:00 GregP      No need to remove yourself from anything my friend, it's just that in case you haven't noticed this community is wounded and very touchy about it so Seeing how I'm the one who sparked this debate I want to keep it highly respectful and explore all options before I make any decisions on what I'm gonna do next. I'm gonna do something that's for sure. But, I don't want to step on anyones toes nor do I want my toes stepped on.      @Hostilefork I gotta admit I do like what Red has put on the table thanks for that link to the video it has my mind spinning.      Does anyone actually have a blueprint on where the state of Rebol lies at this current moment? posted by:   Patrick Stewart     27-Sep-2014/0:32:15-7:00 @Hostilefork      Question Freebol is a nice name and u already had the vision (i read your presentation it was spot on) how come you haven't just pushed the community to freebol and moved on. Just curious can freebol not be the new community home? posted by:   Patrick Stewart     27-Sep-2014/0:38:17-7:00 Some information about the state of Rebol as I understand it:      Most of the public development work on the C codebase has been done by Shixin Zeng at Atronix. If you are curious about the kind of changes that have been going on, you can read about them in this list:      https://github.com/zsx/r3/commits/atronix      Important to Atronix is having Rebol3 be open source so they can fix bugs when they are blocked by one in a project. So there's a lot of that. Beyond bugfixes--a major change there was their implementation of the GUI for Linux. Previously it only existed for Windows. Running on Linux was a business priority for Atronix...and they did the work in cooperation with Saphirion.      Another bigger change was the integration of the Foreign Function Interface (FFI). This allows Rebol to call functions in DLLs that have not been specifically written as Rebol extensions. (This is more similar to Red's #import functionality.) It means you can link Rebol up with off-the-shelf C libraries from within Rebol...with no C compiler needed.      Rebol's GUI approach has historically been "get a bitmap buffer per-platform and draw a non-native GUI that looks the same per platform". I've criticized the result as being the "80s cash register look"; and unlikely to please modern users. It also involves a lot of work to reinvent the wheel and please almost no one for it.      The underlying graphics abstraction layer used to generate a bitmap buffer and draw lines / shapes / text has been "Anti-Grain Geometry" (AGG). Anti-Grain Geometry development has not been advancing. There have been murmurs of switching to OpenGL but I do not know if anyone has formally pursued that.      Newcomer programmer Giulio Lunati has been involved in doing some things with Rebol on Android. That includes having made an NDK command line build and integrating with the Scripting Layer For Android. Using this layer he has been able to get native-looking UIs with Rebol; although anyone running SL4A has to deal a bit with potential security risks introduced. (An application using SL4A is effectively operating using SL4A's permission settings, not its own.)      Carl has stated that his own interests in Rebol are driven by embedded programming, and desktop GUIs are not that interesting to him. The opinion of how important the GUI is depends on who you ask. But non-native-looking desktop UIs are really a very small niche at this point; when native desktop UIs are themselves less relevant. Those who aren't holding to nostalgia agree that embedded infrastructure and messaging--plus native mobile UI--is where emphasis should be.      Red is bootstrapped to Rebol2. I made a fair stab at porting it to Rebol3 shortly after the open sourcing...and learned things in the process. Found and fixed some Rebol3 bugs and raised issues about things that had changed. The design and legibility of the language is the part I find most interesting; like solving a puzzle. So I keep myself occupied thinking about that.      One of the big cultural accomplishments to point to is having built up a public community on StackOverflow, and pulled people out of the AltME bubble. Awareness of Red was raised in an open source advertising campaign, so more people have heard of it now:      http://meta.stackoverflow.com/questions/251196/open-source-advertising-sidebar-1h-2014/251208#251208      I made an advertisement for Rebol, however I have not been willing to put it up. Because those campaigns are to recruit developers on the projects, and when changes are not being integrated there's no real way to accept contributions. I'm not comfortable telling people to come join the Rebol dev effort; although I'd suggest that people look at the language for its "interestingness".      One major issue of fragmentation is that Rebol's core, Saphirion, and Atronix all use different build systems. The core wants to stay lean and only depend on classic "makefiles"; and rather than maintain them by hand, they are produced by make.r. CMake offers advantages in being able to automatically generate IDE workspaces (such as visual studio projects) as well as find where graphics libraries are on your system, so Saphirion uses that. Atronix uses handmade makefiles, I seem to recall?      If the repositories are to be integrated successfully, there needs to be a Rebol-based way of generating any of these make targets. Requiring CMake to build the GUI wouldn't be a problem, but you should be able to build the core with just the old-school make.      It's worth it to keep the Rebol name. Carl has expressed willingness to do what needs to be done in terms of handing over the reigns for the master branch on GitHub, it's just being done slowly. While impatience can be a virtue, in a way I think we may have had our time saved from doing too much hacking on a C codebase...instead being able to focus on design issues and methodologies that will be more relevant to the future. posted by:   Hostile Fork     27-Sep-2014/2:54:25-7:00 Great summary Brian. Thanks for doing that. posted by:   Gregg Irwin     27-Sep-2014/4:39:16-7:00 Hi Patrick,      Red's leader speaking. Nice to still see newcomers feeling the "Rebol" fire burning inside of them. :-)      I can understand your feeling and frustration for the state of Rebol, as I went through that a few years ago, before deciding that I should do something about it.      Red was initially created to provide a future for a Rebol-like technology, while at the same time, trying to extend its potential in many areas (like system programming). Red is a serious project, as shown by its ~3500 commits so far, 17 releases and close to 20 code contributors overall. We are committed to make Red a success, whatever it takes. If you want your actions to matter in the future, consider also investing in Red project.      Red is aiming further than Haxe, thanks to Red/System DSL, we can program on top of the hardware directly and write an operating system or device drivers (as mentioned above by Bo). Red favors running on the hardware directly than on top of a VM. Also, we prefer runtime bridging approach rather than compiling to another language. Though, in some cases, this won't be enough and having JS/JVM/CLR backends would help us pass through some barriers. In such case, most probably, a direct compilation to the target would give us better results than going through another language that has very different semantics.      About the Apple hardware you would like to provide to the community, that would be really helpful for Red project right now, as we really need a reliable OSX system online for our automated building system.      -- Nenad nr (at) red-lang dot org posted by:   Nenad Rakocevic     27-Sep-2014/5:14:36-7:00 Patrick,      I'm quite familiar with Haxe. Google "haxe" and see the listing immediately following their home page and Wikipedia entries (or search "learn haxe" and look at the first result). I wrote that years ago before NME and OpenFL existed. Haxe is a great design, which has found success in game programming for mobile platforms. The libraries and build tools which have taken root in the Haxe crowd are those which allow Actionscript developers to use their skills to cross-compile applications for iProducts, Android, and Flash. If you look at the Haxe API a little more deeply and take part in the community a bit more beyond the top level description of the language, you'll see that native support for Actionscript is where Haxe really shines. Since Flash has lost the war to HTML5 on the web, no longer has native support on Android, and never had native support on iProducts, it was a boon to Actionscript game developers, because libraries like Neash and build tools like NME (OpenFL) provided a viable solution to immediately produce native executables for those popular platforms.      Nicolas Cannasse is brilliantly talented, and there appears to be some fantastic talent in the Haxe community, and Haxe is a really cool tool. There's just absolutely no reason to rewrite Rebol in it, and plenty of reasons not to. First, Haxe's community is small, and the documentation is notoriously sparse. You will immediately limit your pool of developers to a tiny group, and if you run into trouble with development, your team is on their own figuring out solutions. (I'd say that if you could enlist Nicolas to complete all the porting, then go for it). Second, although Haxe appears to have good performance, it's nothing like writing in C. Writing a language interpreter with a trans compiling language toolkit sounds like a nice short cut, but you have no control over the output source code, and that would likely lead to so much manual rewriting of the generated code, that you might as well write the generated code in the native target language. Not to mention that Rebol is already written in the best performing, best supported, best documented, etc. language for the job. Haxe is meant for what it is currently used for, and it succeeds well for mobile game developers, but I don't think it should even be considered for this project.      Rebol source code doesn't need to be ported to another language. That's not the problem. It just needs to be completed and some binaries need to be published for modern platforms (web, iProducts, Android, etc.). That's a relatively small amount of work which a few dedicated developers could complete in a matter of months. When that work is done, the final products need to be documented, and then promoted. Do that and the project will be successful. posted by:   Nick     27-Sep-2014/5:58:26-7:00 Nenad posted his response above while I was writing. To be clear, I fully support the Red effort. Doc is brilliantly talented, and he's dedicated his life to making Red happen. Red will have far more reach than Rebol could have ever hoped for - it's a much more ambitious project than Carl had imagined with Rebol. Hiring developers to help Nenad is a direction that I would support whole heartedly, even if it meant having to wait longer for a finished product.      BTW, if you're still thinking of re-writing Rebol from the ground up in some other source language, take a look at how much work has gone into Doc's efforts. posted by:   Nick     27-Sep-2014/6:07:55-7:00 Patrick,      Years ago, when the R2 browser plugins were being developed, I suggested that Rebol source get ported to Actionscript, so that Rebol could be used in Flash (similar to the way, for example, that Closure is used in the Java environment). That's just not needed here. One thing to be aware of is that Rebol was designed, perhaps more than any other language, to compile easily on any platform. That's one of the reasons that early versions of it were available for virtually every major platform of the time (40+). Even the graphics and GUI engines were designed to be portable. They originally targeted the AGG back end, but again, Cyphre and Shixen have shown that ports to other graphic renderers can be accomplished relatively easily. Using a stage and timeline based graphic development environment to create a renderer for an already mature and proven graphic system, along with a trans-compiler based written OCaml, whose API is written to support Actionscript, is just so many levels of unneeded mess, that it just misses the boat completely. Rebol's source code is mature, and it's in the most supported and best performing, most popular language available for the task. Looking away from that just represents years of unneeded and troublesome work. posted by:   Nick     27-Sep-2014/9:10:35-7:00 Nick      Ok now I'm confused. Earlier you said this      "You said "There seems to be some confusion about what's meant by porting to JS. The idea is to port the entire interpreter, with R3-GUI (+), to Javascript, "      Question? Is not porting the entire interpreter to JS rewriting/porting the Rebol interpreter in another language?      I believe that's exactly what your saying and if so all i am saying is port it to Haxe instead of javascript where you have more compiling targets. Seems to me its semantics cause then you also said.      "Rebol source code doesn't need to be ported to another language."      Well does it or not? cause you said it needs to be rewritten/ported to JS which is another language and then you said it doesn't. I'm confused.      All I'm saying and understand I'm saying this cause you clearly said that the rebol interpreter needs to be ported to JS which means rewritten by all accounts so my statements was going on your clear indication that there would be a rewrite in JS to target the web soooo if ya have to rewrite rebol in JS why not do it in Haxe and gain more target options?      I ain't gonna lie I'm confused now cause your saying it has to be ported to another language yet your saying it shouldn't be.      Help me understand...      Lot's to read I will respond back later after I read all the new post.      posted by:   Patrick Stewart     27-Sep-2014/10:08:05-7:00 It is possible to "transpile" Rebol as what as known as an "emscripten" build:      http://en.wikipedia.org/wiki/Emscripten      This basically runs the C sources through the Clang compiler, and then gives you a big fat JavaScript "binary". You can see people taking C and C++ programs and building things with it with, even heavy loads like building the "Quake" game and running it in an HTML canvas.      More relevantly, you can see some emscripten versions of other interpreters here:      http://repl.it/languages      We have been able to do this for Rebol; it's ANSI C and a good candidate. However some technical glitches were preventing us from getting a working interactive console in the browser. These issues may be close to being fixed.      There are some catches with the method. Whenever an emscripten build hits a system function they haven't built a handler for, it just gives you a runtime error. When we first started the build of Rebol, it had a few interesting features (like being able to work with a bundled "fake" filesystem)...now it seems they have added things like sockets.      Anyway, this provides you with a stateful Rebol interpreter inside a browser. You embed the script, wait a bit for a (cacheable) download (half a megabyte might seem like a lot for a JavaScript file, but people download pictures that big these days all the time). Then you can pass it strings of programs to evaluate and it will pass you the results back; or you can rig up some kind of callbacks.      I don't know what uses people would find for this besides interactive tutorials. But having it puts the burden of proof on those saying Rebol needs to be in the browser to show what it is they want to do when they have it.      That is the only sensible "porting" of Rebol to another language I can imagine. Adding more target platforms and packagers to Red would be a wiser investment of time. There is already ARM and x86 code generation, with packaging as Program Executable (Windows EXE), Mach-O (OS/X), ELF (Linux)...all the way to APK (Android). If there were an ASM.JS target then that would open some other possibilities:      http://asmjs.org/      No need to build either Rebol or Red to Haxe for the reasons Nick has outlined (and as noted he does have Google hit #1 for "learn haxe" on Google). posted by:   Hostile Fork     27-Sep-2014/11:04:23-7:00 As i see it, the only momentum now is just at the side of RED. There are propositions for Rebol3 here and there, but they are fragmented and not incorporated into the official repository. So if you are willing and able to support one fork, i suggest to stay with RED, as this seems to be only really advancing and open to every one. posted by:   sqlab     27-Sep-2014/11:08:18-7:00 As i see it, the only momentum now is just at the side of RED. There are propositions for Rebol3 here and there, but they are fragmented and not incorporated into the official repository. So if you are willing and able to support one fork, i suggest to stay with RED, as this seems to be only really advancing and open to every one. posted by:   sqlab     27-Sep-2014/11:08:33-7:00 Patrick,      I can see how that may be confusing. Fork covered it well. Just to clarify, I didn't mean to port the source code to JS, but the actual executable interpreter, so that it runs in the browser. That would allow us to run complete Rebol applications in any modern browser (i.e., directly on any web page), or to create what appear to be native apps on any new or future platform which supports 'web apps' (basically all current and new OSs, desktop and mobile). This is currently perhaps the most common way to build and distribute many types of cross platform applications.      Think of JS as being similar to machine language - it's sort of the machine language of the browser (and it does perform quickly). The whole Emscripten tool chain lets you compile C code to Javascript, just as a native compiler converts C code to native machine code, so that the compiled application runs in a modern browser (no plugin required). As Fork said, because the compiled Rebol interpreter is so small, you could include the Rebol interpreter right in your web page (as a JS file), along with your scripts, and voila, run your R3 app directly on a web page. This would allow us to run Rebol apps anywhere there is a browser, and package them into stand alone applications on any platform where a 'web app' packaging mechanism is available.      Doc does plan to add JS as a similar target for Red, but he apparently wants to focus on OS platforms first, and Android appears to be the most important target initially. As I said, I'd love to see him get more support, financially, or in the form of additional developers. Red is just a much more ambitious project, looking to supplant the entire mess of legacy C tools which defines the history of software development, along with the huge complex tool chains which have historically evolved around them. His idea is much more of an industry changer, and I think there's a need for it (Carl predicted there would be, 20 years ago), but Red just isn't done yet. I trust fully that Doc will get it done, in time, and that the project will be successful. When Red does become mature, there may not be any need for Rebol whatsoever - it just simply doesn't exist in a form that is fully usable by most developers, yet. Rebol does exist in a relatively usable form, it's mature in many ways, and it's just sitting there waiting to be ported to some modern platforms. You can make the decision to support whichever project suits your needs and your timing. Supporting Rebol gives you an especially productive tool to put to use in the near future - and helps the Red cause, if it attracts a larger community who would most likely eventually support Red. Supporting Red is a bigger investment for the future. I've given a few $thousands to each project, and I'm glad to see that both have some life. No part of my current income relies on software development, so I haven't been pressing much, but I'm glad to have R3 on my Android devices, and I'd like to see it mature more there, and spread out to other modern platforms (web, iProducts, etc.). And of course, I'd love to see Red become a big player. At the moment, I'm just watching and trying to help whenever something important comes up. posted by:   Nick     27-Sep-2014/12:04:12-7:00 From my POV, there's enough talent in the community already, but people are jaded and spend time on other things. If there's an offer of money and resources, I'd suggest funding Nenad's requirement for a stable Mac build system and offering bounties for anything that can be identified as being blocking for a stable Rebol3 final release. posted by:   Graham     27-Sep-2014/17:01:01-7:00 And maybe paying someone to maintain an updated community build so that all the PRs are appropriately treated. The way it looks now, the world thinks Rebol3 is dead, and this drives potential contributors away. posted by:   Graham     27-Sep-2014/17:04:46-7:00 Ok, Fork, Nick I get it now about the JS port totally makes sense to me now. There is a lot of talent and knowledge in this community the information being rendered is pretty intense. Thank you for that it has been very informative.      I think I got a grip on what every bodies saying which would be this:      1. Red is where the futures is at so supporting that project would be wise and recommended .      2. R3 has some things that need to be done to get a stable final release and then it could be used while Red is in continuing development. There are some blocking issues that need to be taken care of and a JS port would put R3 in the browser.      Red Leader, has indicated that they are in need of MacOSX build server and would like to be considered for any investments as well.      Ok one more question. If Carl has not designated the master github repo to the community just where is the community code at? You know the one where the community can actually merge changes?      Who has that repo?      Also, Nenad thanks for joining us, I have been waiting for you. Please tell me the specifications required for your MacOSX Build Server. Also do you have ( I'm sure you do) an ideal where support would be required for specific agendas, task, implementation etc. and if so what would be required?      Nick, what would it take to get this JS issue resolved?      Hostilefork, what would be a somethings you have identified to be a blocking issue that we could move on first?      I like Grahams bounty ideal so lets get some bounties on the table and as GregP said we do need one repository we can all work from, use the wiki's at and so on. My suggestion would be since everyone seems to agree tha Red is the way forward how about Nenad provides a fork of the Rebol master (or one of the current forks that has surpassed the master) at the Red github that we can all work from until Carl releases the main repo. Seems to me that we should all be trying to push Red forward and also get a stable release on R3. I don't see a better place to rally at other then Red.      Also who is running RebolSource and the build farm there? Since we all concur that Red will most likely succeed Rebol shouldn't that build farm be doing CI on both rebo's meaning Red and R3. I think so as the logical releases were R2 (retired) R3 (alpha) Red (Development).      Bottomline from the information presented to me I believe the best place for the community to rally is as the R3 branch of the Red Project as we all see Red as the future also shouldn't we be trying to do as Fork was doing and trying to bring R3 up to stable enough to allow Red to switch from the R2 to R3 branch for bootstrapping until it is completely self hosting. Seems that if we track Red and can get R3 to bootstrap Red in addition to other things that are being said we can get a stable binary out there.      There does not need to be any more forks, new names none of that I believe the R3 community should be working within a Repo provided by Red as the successor to Rebol. So it's pretty much already been defined. If this is acceptable we could bring both teams together enough to support both legacy and future projects and I really don't see any other logical ways to do it. In short the Rebol community and the Red community shares the same goals for the most part and that is to get a stable release of Red on the table but also with the uncertainty of RT and any releases they have made Red should also appreciate any ability it could gain from being able to switch from a closed source interpreter it uses to the R3 open branch if we can get it there. Just my view and the one I will support.      what do you folks think. posted by:   Patrick Stewart     28-Sep-2014/7:30:37-7:00 Just to be clear, I believe that all parties involved with Rebol meaning , Artronix, Saphir, Red and R3 communities at the end of the day will want to see Red prevail. I don't believe for one second that either Artronix or Saphir will put their noses in the air if Red was at stable so my view would be to kill all this fragmentation by lobbing Nenad to actually see the he holds the ingredients to a stable community.      the R3 team needs a community repo and we can't continue to sit around waiting on Carl to uphold any of his promises and to be honest is anyone even able to talk to him? I can tell you that I purchased the R2 SDK for 249.00 over a week ago and have not received any response on my purchase or attempts to communicate with RT and Carl about the purchase, nothing nodda, zip, no email, no license key nothing I have had to escalate it as a claim at Paypal to get my money back. So that says plenty to me cause I damn sure wouldn't turn down 249.00 LOL      Anyway, Red is where we should be in my opinion if Nenad will provide a community master of R3 at the Red-Lang github we can work from there but we need to be sure that we actually want the master master or do we want to pull back one of the other forks?      maybe we can even get Red-Lang.org up to speed on site design and gain some presence there both communities have enough in common to share the same home and also maybe even encourage artronix and saphir to rejoin the communities that should be the focus. People Rebol3 is Red's legacy so indeed it shares a bed with Red but not if you allow Red to mature off an R2 bootstrap at that point R2 is Red's legacy. R3 is not even in the migration path and we need to change this. R2 is at the end of it's lifecycle R3 is floundering and Red is in full development. R3 should be Red's predecessor and have a Lifecycle and support venue even after Red is released until total migration cycles have been realized before R3 has it's end of lifecycle. But as it stands R3 already has it's end of lifecycle before even getting life. Come on people I see a lot of talent and knowledge here lets use it.      It is called Damage Control people and we need to do plenty of that to save this project.      So I propose the following.      1. Get Red to open up a community branch of the R3 codebase for the R3 team. 2. regardless to all this we don't need presence, we don't need sites or tools which is pure nonsense we need to enhance both R3 and Reds presence and toolchain. Hell even Red has basic presence that they control and look they are getting it done and have received some corporate sponsorship too. Rebol3 could find a Presence with Red 3. We need to gather all the documentation that is out there in one place and surely we need to preserve anything that is relevant that is not in our control. I don't care what anybody says about this one thing, Carl/RT are doing what is best for them in their lives you can't put all your eggs in one basket and you can't say for sure that you won't wake up one day and every single Rebol site with all it's information and stuff that they control but that is relevant to the community has went dark and then what? all that information will be lost. 4. We need a real R3 Team leader so who is going to fill them shoes? somebody needs to grab the donkey by the tail here. 5. We need Nick, he has written more about Rebol then anyone including Carl his writing skills are required and needed in both projects if we can get him on board. What he does provides educational Resources for the communities and potential users. 6. We need some serious Damage Control people, things have been allowed to get slightly out of control but all is not lost it can be salvaged if we want it to be. 7. The R3 team needs to get a stable binary out there. we need to identify blocking issues slap some bounties on them, get them done and move forward. Again, I believe one of our goals would be to get R3 able to bootstrap Red you can't go wrong there as the new should be able to bootstrap of the current tree not the legacy branch which we don't even have control over. 8. Any and all resources that are available should be assembled for the movement of both project forward. R3 teams should be attempting to get the code stable while being on hand to support the NextGen release. Red is the X in RebolX and going forward we need to get R3 in the migration path. as it stands now R2 is still the most viable option for any decent work and R3 is in limbo so what do you want to see happen? Should folks be migrating from R2 to Red or should they be migrating from R2 to R3 to Red. we all know the answer to this this but it won't happen if we don't give them an R3 to migrate to. As it stands Red will beat R3 to a stable release and that breaks the cycle of development drastically. 9. All this talk of Rebol like it's just some hobby toy is nonsense and I would say if this is just something for your enjoyment as a pastime then you don't belong in the official community. This is a movement people not a game and those that believe otherwise need to grow up and get serious or get gone. That way of thinking doesn't help anything get done it only holds the project down. 10. Lets get something done!!!!      I'am willing to support both projects under these conditions, I can help with presence, toolchains, bounties, management whatever ( I ain't scared :) ) and just flat out financial support where it may be needed.      Does this not make sense because from where it sit Red is Rebol and Rebol is Red. posted by:   Patrick Stewart     28-Sep-2014/8:46:20-7:00 Oh and make no mistake this is by no means disrespectful to Carl.      The ultimate respect we could ever show carl is to Build off his legacy and let the world feel the power of his baby by moving it forward even beyond the scope of his initial vision. We can preserve and uplift his work and give it a home on the radar in the history books.      Anything we do to further, not hamper or hurt his vision will prove that his concept of Rebol was indeed correct. We already know it is. let the world know. posted by:   Patrick Stewart     28-Sep-2014/9:01:36-7:00 Oh and we need our OWN unblocked place to communicate. all the Altme and SO stuff is nonsense and only segregates the community from potential users. There should be a way for potential adopters to be able to ask questions and things without having to pass some reputation test that almost put me off right from the get go.      Stop trying to be the exception there are already plenty of open source projects out their take lessons from them it has already been tried and tested by doing some homework on other successful projects it is not hard to see what works and what doesn't. posted by:   Patrick Stewart     28-Sep-2014/9:11:02-7:00 > If Carl has not designated the master github repo to the > community just where is the community code at? You know the > one where the community can actually merge changes? Who has > that repo?      Theoretically that is:      https://github.com/rebolsource/r3      But notice that it hasn't been integrating since the last master update. That's because there has been a lot of "wait and see" from people. Rebol usage goes on when people need the tool and/or want to just talk about it. But Rebol development is stalled, and we make some notes on findings in "tickets" on CureCode...or chatter in chat.      I just wrote this one, for instance:      http://curecode.org/rebol3/ticket.rsp?id=2173      The build farm and rebolsource are managed by Andreas Bolka (@earl). He is the most knowledgable person about Rebol internals and history who is active at this time (IMO). There are others who know a lot of the details too...but you don't hear from them much lately on public forums. It's hard to tell if they've gone on to other things and would not participate, or if they are just staying quiet and would return if there was activity.      > Hostilefork, what would be a somethings you have identified to > be a blocking issue that we could move on first?      We've already spoken about unblocking the integrations, which is job one. The solution proposed is for Carl to steward a "stable" branch, while the "master" branch on GitHub is allowed to look lively...even if it means risking integrating something he later feels was a bad idea and wants to back out and/or not integrate into stable. I emailed Carl about this again Saturday morning. Hopefully persistence will pay off and no new names or focal points will be necessary.      Regarding what should be moved on first--I have my opinions. A big one is that if one were to ignore most of Rebol and sell it on the virtues of PARSE, that could be very successful. People continue to use RegEx which is very sad indeed. But Rebol has not taken the "low-hanging-fruit" of even defining classes for characters. I don't want to have to write this in every program:           digit: charset [#"0" - #"9"]      whitespace: charset rejoin [space tab cr lf]      letter-uppercase: charset [#"A" - #"Z"]      letter-lowercase: charset [#"a" - #"z"]      letter: union letter-uppercase letter-lowercase      ;..etc...      We've worked out what seems to be an answer for this, to create charset-generating-and-caching functions and put them in the box. Then allow zero-arity functions to be called from PARSE:           >> parse "abc DeF 123 DECAFBAD" [          3 letter/lowercase          some whitespace          3 letter          some whitespace          3 digit          some whitespace          8 digit/hex/uppercase      ]      == true      Building these for the known (and named) Unicode character classes is very useful, and they'd come in handy just in regular code for FIND as well. It is a bit of a crime that Rebol has not moved forward on this. And Red needs it too. As long as you only allow zero-arity functions, there's no danger of (for instance) `whitespace` being a function that can "eat" the subsequent pieces of the dialect (like a 3 that is intended to indicate a run length of `digit` above). It's a reasonable compromise. I sent a pull request implementing this where it didn't enforce the zero-arity, but I've decided I'm okay with that limitation for the sanity of the dialect.      But that's an example of what *I* consider super high priority. I'm also very focused on getting other "first encounters" right. That includes things like PRINT, building it on COMBINE, and helping not confuse people with the likes of REJOIN from the beginning. See this article:      http://blog.hostilefork.com/combine-alternative-rebol-red-rejoin/      If you talk to others you will hear a lot of opinions. Such as about the anemic console behavior in Rebol3. The stdin/stdout basic IO streaming in C does not provide the ability to control the cursor position or know the screen size, as you can with a "curses" style library...vt100, the Windows console API, ANSI.SYS... or what-have-you. By being written to run its console on the lowest-common-denominator, Rebol3 has displeased some people who were used to in Rebol2 being able to open a block, hit enter, and keep typing...with no command executed until the block is closed. Red uses libreadline to do this:      http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html      I do not personally consider this a big issue since many interpreters for popular languages don't address the issue. But it is important to some people.      Because a lot of people use Rebol for scripting and automation, the simplistic implementation of CALL for invoking and piping other processes has been a barrier for many. Getting a full implementation of that is important.      A key element that has yet to make it into the Rebol mainline is the `https` protocol. This is an important piece. Giulio has separated it out into a pull request, so theoretically the work is done:      https://github.com/rebol/rebol/pull/222/files      It would be easier to go through and label and prioritize things if we could get the rebol/rebol GitHub authority decentralized. Then we would be comfortable getting the issue database imported there out of CureCode, and do some tagging and triage which would go more smoothly.      > I like Grahams bounty ideal so lets get some bounties on the table      Everyone loves bounties and seeing new features happen...if they're not paying for them or writing them!      I think Graham was speaking specifically to you with that remark. As in: "What do *you*--Patrick Stewart--want that you're willing to pay people to do?" (OR what are willing to load up your favorite dev environment and start coding?) There's not a lack of ideas or talent...and people are around (as you can see) to pay attention when questions come up. Rebol questions are answered quite snappily on StackOverflow by users.      There's just a lack of incentive to hack on the tool itself at the moment... posted by:   Hostile Fork     28-Sep-2014/9:47:09-7:00 Red and Rebol are separate projects with separate agendas, and attempts to present a unified front (such as the consideration that "Red is Rebol4") have been met with resistance. Don't expect that to change.      For instance: Nenad isn't going to want a GitHub red/rebol repository. He grudgingly accepts the unavoidable "guilt by association" in terms of people who might think Red is going to be a slow-moving project because of its historical ties to Rebol. He wishes Red's reputation and track record for openness and demoing on-schedule to be seen from a clean slate--to the extent possible.      There are language design criticisms of both projects--which it doesn't help to drag out here--other than to just try and keep asking both of the projects to take the best ideas out of the pool. There may be some irreconcilable differences somewhere. But (for instance) we're pushing back against the Rebol3 decision to change how `pos/0` picks the item before pos instead of `pos/-1`...which is how Rebol2 and Red do it, and is the more natural default. To meet the demands of those who want a zero-based pick there are PICKZ, POKEZ, INDEXZ.      There are naming issues, like whether `length?` should be `length-of` and `index?` should be `index-of`. Because things ending in `?` are best thought of as returning true or false. The compromises can be subtle...such as using `length` and `index-of` due to the prevalence of checking for length. (You don't write `head-of` or `tail-of`...)      So there's no quick answer here based on unifications of Rebol and Red. They will be exchanging DNA via issue tickets, not code or shared GitHub accounts. posted by:   Hostile Fork     28-Sep-2014/10:13:15-7:00 a bit puzzled ... does it make sense for doc to bootstrap with R3 ? his path was to bootstrap with r2 until red is ready to bootstrap with r2.      i.e r2 --> red      now if he has to convert from r2 --> r3 -- > red, is this not going to waste his time ?      besides from what I read here, r3 seems to be incomplete and there are some subtle differences of behaviour. posted by:   XXX     28-Sep-2014/12:37:19-7:00 a bit puzzled ...      does it make sense for doc to bootstrap with R3 ? his path was to bootstrap with r2 until red is ready to bootstrap with red.          i.e r2 --> red          now if he has to convert from r2 --> r3 -- > red, is this not going to waste his time ?          besides... from what I read here, r3 seems to be incomplete and there are some subtle differences in behaviour. will the R3 "bugs", incompleteness, different behaviour also not delay him, if he encounters R3 bugs or incomplete features ?      besides, from what I've also read here, he did not play that much with R3.      and lastly, his goal is trying to get away from Rebol completely and use only red, why prolong his agony, to move from r2 to r3 before moving to red?      just saying..., I'm puzzled...what am I missing here ? posted by:   xxx     28-Sep-2014/12:51:32-7:00 Rebol3 would be complete enough for Red to build on.      3 reasons why it wasnt done that way: a, Doc has experience with R2, not with Rebol3. b, When Red started Rebol3 wasnt ready and its future unclear. c, Once Rebol3 became ready and open sourced Red was already started on R2 and Doc didnt want to invest time into switching. Fork since ported of Red to Rebol3. That wasnt picked up.      Does it make sense to switch Red to Rebol3? Depends on your bets about the future. In favor of Rebol3: is is stable and fixable. It supports more current platforms than R2 (Android). If you bet that Red will soon / 6 months / be ready enough to bootstrap itself then switching will prolly just be a distraction. posted by:   YYY     28-Sep-2014/13:00:21-7:00 If Red becomes wholly dependent on its own code generation too soon, that could tie its hands quite terribly. My opinion is that a mad rush to eliminate the dependency on Rebol will lead to instability.      Better would be to have a codebase that can run in either Rebol3 or Red, and keep things sync'd for a while.      I dug in and identified most of the issues in getting Red to run under Rebol3, with a binary-compatible "hello.red":      https://github.com/red/red/pull/421      Since most development since then has been on the runtime, I imagine few new issues have been introduced.      While it was by no means trivial to get to that point, the reality is that there are only a handful of problems. Yet Doc is not interested in changing his coding habits to accommodate changes in Rebol3 that he doesn't agree with.      For instance, I mentioned the indexing issue. It is possible to gloss over it by having a function so you can write FIRST-BACK POS and have that behave the same as POS/0 in Rebol3, but POS/-1 in Rebol2. But Doc does not want the call sites in the Red codebase where he has written BLOCKOFBLOCKS/-1/-4 being turned into FOURTH-BACK (FIRST-BACK BLOCKOFBLOCKS) for the sake of running under Rebol3.      Simply put, if Red is to run under Rebol3...and Red to take advantage of the benefits (such as running the compiler on Android, or building APKs on HaikuOS, or whatever), then it's going to be mostly Rebol3 that must bend to meet the challenge.      Having seen the various quibbling issues I'd say the most major one, besides the indexing, is that Rebol3 killed HASH!. I think HASH! should be killed *as a type* (why shouldn't I be able to pass an accelerated block to any function taking a block!?) But you should be able to get it as a behavior.      This could be finessed I'm sure, but one solution Doc does not want is to rewrite the Red code to a MAP! interface. He wants a block with hash performance. I think that is good to add to Rebol3...so all you'd have to do would be to have:           blk: make hash! [a 1 b 2]      hint blk [hash-access]      Then just define hash! to be equivalent to block! when running in Rebol3, and make the HINT do the work under the hood. If you're running under Rebol2 leave hash! alone and make HINT a no-op. Leave the rest of the code alone.      It would take these kinds of compromises...as well as getting a Rebol3-based encapper that can bundle the scripts together to give a single executable on all the platforms...to see Red-on-Rebol3 happening.      No steps in that direction have been taken, and I did that porting work *a year and a half ago*. So unless something changes, it won't happen.      But it would be nice if it had happened. Can't fault me for trying. posted by:   Hostile Fork     28-Sep-2014/13:24:59-7:00 @Fork      "Red and Rebol are separate projects with separate agendas, and attempts to present a unified front (such as the consideration that "Red is Rebol4") have been met with resistance. Don't expect that to change. "      True, but the one agenda that both projects share and the most important one is to have a stable rebol system out there regardless to if it's R3 or Red that is where the common denominator lies. Also lets be honest when Red is done it will in effect be Rebol4 unless the R3 team gets a stable release and gets to R4. I mean what do you think will happen on a stalled project and then comes Red stable and being developed? R3 is history for those who aren't just tinkering with it any real consideration will be placed with Red even from some of you. Meaning if Doc was to magically finish Red by the end of the week and announced Red CTP Vxxx damn near everybody in here myself included would be playing with Red code all weekend. So as I have been told several times Red is the future of Rebol I mean y'all said it not me, so Red is Rebol successor by your own admissions. hence Rebol4 and this is especially true considering R3 is stalled and not progressing so maybe Red is actually Rebol3. Lol gotta hate me....      And, I'm glad somebody gets what I'm saying about Red running on R3. with an emphasis on he would be building onto of an Open interpreter rather then one he does not have the source to. right now he is building an open system as his vision dictates on top of a proprietary binary albeit one that is available for free but for how long.      Nobody here can guarantee that Rebol.com will even be up next week that binary can disappear at anytime. So Red is taking a risk by even using it because if Carl takes it away then what???      You can't legally distribute a proprietary binary and if Red is not self hosting that is what he would have to do to even allow those who download the source to even get it to work.      Only he would be able to compile the source with his legally obtained binary including others that have a legally obtained R2 nobody else (new users) would because they couldn't download the binary from Rebol.com which could render the Red project dead in the water from a legal and source distribution stand point.      Running Red on R3 takes this risk away and allows Doc the freedom to maintain stability as long as needed without having to depend on a proprietary interpreter that nobody can guarantee will even be available next week.      Just saying, sometimes, actually most times you have to look at the risk or pros and cons when doing something and in my view depending on a proprietary binary thats future is uncertain is big time risky.      Now unless Doc knows something I don't I would think cooperating with the R3 team enough to release this dependency and get Red 100% open source is worth it. Because as it stands just having that dependency on a closed source interpreter makes Red highly susceptible to Carl regardless to what Doc wants to believe if Carl wanted to pump his breaks all he has to do is shut down the Rebol.com website, take away any and all downloads of the R2 system and forbid redistribution and guess what? game over now only those who have R2 can even do anything with Red, new users cannot because you cannot legally distribute R2.      The R3 and Red communities share more meat then ya think, I don't see why Red wouldn't be trying to make sure R3 makes it to stable cause it needs to free itself from R2 just to secure it's future. That's my view.      Yeah I know I'm playing the devils advocate but you have to in order to find your strengths and weaknesses when your investing and dedicating your life to something like Doc has been doing.      Just saying .... posted by:   Patrick Stewart     28-Sep-2014/14:08:38-7:00 Actually it is already all bad as Red states this.      Prerequisite      "You need a Rebol SDK copy with a valid license file in order to rebuild the Red binary, this is a constraint from using Rebol2 for the bootstrapping. Once selfhosted, Red will not have such constraint."      well here is a problem according to this you need the Rebol SDK with a valid license to even build Red and I can tell you first hand I purchased the SDK last week and Carl/RT have failed to deliver the product or license even though some of you have tried to help me by sending him emails nobody has sent me a download link or a license key. So as it stands right now I CANNOT build a Red binary even though I tried to purchase the SDK.      So any new users who try and discover Red using the source are already barred because they cannot purchase the SDK. At least I couldn't even though I sent the money. posted by:   Patrick Stewart     28-Sep-2014/14:35:06-7:00 Perhaps obviously (given a month or so of effort invested in getting it to mostly work) I think Red should be built on Rebol3 as well.      That is not going to happen as long as Rebol3 has things like BLK/0 being what Rebol2 and Red calls BLK/-1. While it may seem like "oh, what's the difference" to some, it is a big difference to Nenad. More relevantly--it's a disruptive change with little benefit, considering a long history of delays on things that users actually needed to have delivered.      I empathize...so realize that some of this is symbolic in relaying a *sentiment*. We might paraphrase it as: "We the faithful community needed A, B, C from closed source Rebol...we were promised answers...we waited...then we got X, Y, Z." Some sort of gambled away years of their lives and their code capital on this. I think it's okay to be grumpy when you feel your attention isn't being valued. Many of us would lurve to have attention for our projects.      ( See: http://blackhighlighter.org )      Still, I don't think it should become polarized to a level where ideas aren't evaluated on their merits.      It happens that Red's vision of freeing itself from Rebol2 is to bootstrap... trust its integrity based on the test suite... and roll with the punches of any codegen glitches without the safety net of an ANSI C toolchain.      Under that scheme: a stable "primordial" Red 1.0 would be blessed and trusted. Any glitchy problems encountered might require backtracking to that "primordial" Red...and perhaps tweaking the last point of the Rebol toolchain to fix any deep problems in that primordial Red. But Red 2.0 would be started from scratch and built using Red 1.0.      I have *strongly urged* not to attack it this way. My background in DSL compiler research and bootstrapping puts me in a unique position (at least among present company) to have an informed opinion on the matter.      Letting Red and Rebol3 converge--at least within the subset of code used by Red in its implementation--would be a much more stable approach. It would allow for continued evolution; even if the downloads page of red-lang.org ships the Red built with Red, there will also be a Red built with Rebol3 available to debug and keep the bootstrap stable.      Again: that all *could* have happened by now if there was proper mobilization behind Rebol3. Doc's basic assumption has been nothing will happen with Rebol3, and so far he has been right, outside of bugfixes and GUI work for Atronix's agenda. Getting dragged down by Rebol3 would hinder progress on what he wants to see done...so he keeps out of it and basically pretends it's not there.      But pragmatically, he wouldn't turn away a working open source Rebol3 toolchain building Red if it worked and didn't ugly up the source. And if it ran on Rebol3 you could compile your Mach-O executables from your Android phone and upload them to DropBox to run on your Mac. I'm sure he'd like to announce that on Twitter tomorrow. But he's not going to redo the indexing or turn all the HASH! to MAP! to get that.      Them's the breaks. So the best steps from my view are:      * Get the indexing compromise done and restore path indexing back so that BLK/-1 is the previous element to the position of BLK and BLK/0 is an error.      * Have a HASH!-like solution for blocks (e.g. HINT) in Rebol3 so you can use ordinary block operations and get map performance.      * Get these things done on GitHub rebol/rebol master with Carl's blessing that we were oh so close to clinching just a few weeks ago      * Ask Saphirion to PLEASE release the Android APK sources and the Rebol3 encapper just so we don't have to redo that for no reason posted by:   Hostile Fork     28-Sep-2014/15:11-7:00 You dont need the sdk to use red. you can run it from source with r2 just fine. you only need the sdk for building a standalone bin, for cases where you dont wanna run from source. also r2 license allows free redistrib. please stop spread fud posted by:   YYY     28-Sep-2014/15:12:34-7:00 To clarify what YYY says above, the only thing the SDK allows you to do that you cannot do with the free version is "encapping":      http://www.rebol.com/docs/sdk/encap.html      Which basically zips up all the scripts and resources, tacks them into a safe data area of the executable containing the interpreter, and makes it one nice EXE. Doc has a copy of the Rebol2/SDK you tried to buy (any response on that?) so he does that with Red.      There is actually a bit of difference in the command-line interface of how Red runs if it has been encapped vs. if you download the source and run with a Rebol2 interpreter. For instance: running it with no filenames passed does not kick over into the console automatically...you have to build the console as a separate program.      (AFAIK this is not foundational, it's just that those who bother to git clone the sources are expected to probably be interested in building the console themselves. Especially since they are likely changing the Red sources, so they probably want to build the console more frequently than on the first run.)      However, it *is* true that by being having a closed source component, Linux distributions would not be willing to package Red as a binary in its current form. Being built on the Apache 2.0 licensed Rebol3 would open some doors there, to the extent they are relevant. Not that relevant when you can download it about as easy as you can `sudo apt-get`      But wait...which side are we on in the battle against software complexity, again? :) posted by:   Hostile Fork     28-Sep-2014/15:33:43-7:00 YYY      Nobody is spreading FUD (whatever that means) as you put it I'm going on the information provided by the Red project which clearly says you needed the SDK and a valid License. It is not FUD that I tried to purchase one (cause it said I needed one) and couldn't (so far) not because I didn't purchase it but because nobody seems to think they should deliver the license key and download links and it's been 9 days and counting since I paid via Paypal.      And everything I said has some validity regardless to if you agree or not and regardless to if it would ever happen. Just for the record there have been plenty of software products and projects that have disappeared from the internet regardless to what the license said. I can recall a few open source projects that got acquired by a commercial interest and BAM source disappears, binaries disappear and lo and behold it's now in a paid for product and all the freeness in it is gone and you can't even find it anymore (with the exception of archive.org if they indexed the site or via the new pid product) to even redistribute it (assuming you don't already have a copy of it and don't know anybody with one). I always wondered how a company could make something disappear like that from something as big as the internet but it has happened.      Now that being said I admit not examining the license of R2 and just assumed because it was proprietary it would have some restrictions on redistribution anywhere other then rebel.com as most proprietary software does so I wasn't totally out of bounds for making this assumption. But i stand corrected in that regards and see that R2 is kinda like freeware sorta.My Bad, don't FUD me for it. lol      Bottomline is I still would like to have the sdk and license so what if you can use it in source form maybe i want to encapsulate a standalone binary which i cannot do without a license key and surely I cannot make an R2 exe without it. So @ fork yeah, no response on that sdk purchase Paypal has even inquired and RT has not responded to them either as of yet.      Anyway again not trying to start no crap just trying to figure out what can happen if anything. So I'm throwing stuff out there. Don't FUD me for it. LOL posted by:   Patrick Stewart     28-Sep-2014/16:25:28-7:00 Red and R3 can be seen as complementary. Red has clearly the ability to be embeded, to produce native code, and to be a full stack language so even if you need a low level functionality, you'll be able to write it in Red (while with R2 or R3, the missing functionality has to come from a lib or some C writting). We always talk about language when speaking about REBOL, but R2/R3 are more than just a language: it comes with a tailored environment to enable network, file access, windowing, graphics, events (keyboard, network, ...), ... To some extend, it looks more like a web browser but instead of dealing with HTML+CSS+JS+(JQuery, NodeJS, Bootstrap, ...) it simply deals with REBOL. The X-Internet we spoke about 16 years ago is now Google Play. I'm glad REBOL can achieve the same in a less complex form. Also people are used to use non native UI. Webpages and Apps are usually non natives, but that's not the main point anyway. I believe there is a long term future for both Red and R3. posted by:   GregP     28-Sep-2014/16:30:42-7:00 @Patrick      I'd suggest to kickstart some activity, you consider placing a bounty on getting a proper console for Rebol3. I'd suggest starting at $500, and see if there are any takers. If not, you may need to increase the bounty. Most people I've spoken to see that as a major failing of the current release. posted by:   Graham     28-Sep-2014/18:22:59-7:00 Well Patrick... I don't know what to tell you about the Rebol/SDK license. Hope that doesn't cause any problems for Carl. But like I said, you are probably the first to push that button in a long time. Still business is business--so get your money back if you didn't get what you ordered. I'm a big believer in truth-in-advertising.      The State-of-the-Union discussion you've provoked is good because we haven't really had an "everyone chime in" discussion like this for a while. Nice to have someone come along to raise the challenge...or stir the hornet's nest...or whatever.      But it will take more than a cat herder to fix the problem:      https://www.youtube.com/watch?v=m_MaJDK3VNE      If you have skills and dev cycles to spare (or finances to coerce dev cycles from those with skills), that might make a difference in how the projects proceed. Other than that, the plans will probably continue just as before.      https://en.wikipedia.org/wiki/Serenity_Prayer posted by:   Hostile Fork     28-Sep-2014/19:19:43-7:00 Yes I would be in for trying to finance some dev cycles but your gonna have to guide me some. Like can I get in simple terms a list of what it would take to bring R3 to the state R2 is in now. I'm sure there are new things that separate the two but a list would help me to see a path.      So we got so far. 1. JS port 2. Console 3. Red needs a OS X build server      Now @fork listed a lot of stuff up there someplace can it be summarized in like a task list kinda simple like above please      I would like to identify as many things as possible in order of priority that will produce a stable usable R3 then I know how to channel my resources. I will kick off some paying the bounties hopefully we can get the work done. posted by:   Patrick Stewart     29-Sep-2014/0:50:57-7:00 This is all great everyone. Thanks for taking the time, and to Patrick for lighting the fire. I'll do what I can as well of course. posted by:   Gregg Irwin     29-Sep-2014/3:50:11-7:00 For R3, we could add: - Android port - support of "do task" (multi threading) - R2/R3 comparison - R3 test cases posted by:   GregP     29-Sep-2014/3:54:05-7:00 This thread is long, so if people want to discuss proposals I've made new posts, and would suggest new posts for any specific technical topic.      RE: Multithreading      http://rebolforum.com/index.cgi?f=printtopic&topicnumber=44&archiveflag=new      RE: Testing      http://rebolforum.com/index.cgi?f=printtopic&topicnumber=45&archiveflag=new posted by:   Hostile Fork     29-Sep-2014/9:07:46-7:00 Surely, the first step in bringing R3 to a usable state, before even attempting to match R2's scope, is to address the 745 open bug report/enhancement requests recorded. posted by:   Peter Wood     29-Sep-2014/9:49:59-7:00 Definitely needs a VID 3 system and the Schemes implemented and updated.      That'll bring it back into a nice compact and updated package. posted by:   Luis     29-Sep-2014/9:58:04-7:00 Apparently there is a bizarre linking system here.      My two posts "permalinked" are:      http://rebolforum.com/index.cgi?f=printtopic&permalink=Hostile%20Fork29-Sep-2014/8:34:13-7:00&archiveflag=new      http://rebolforum.com/index.cgi?f=printtopic&permalink=Hostile%20Fork29-Sep-2014/7:56:17-7:00&archiveflag=new      I'd suggest that the "permalink" should be the link produced by the page. I don't see the value of the non-permalink. posted by:   Hostile Fork     29-Sep-2014/10:17:15-7:00 @Hostile I personally don't see a need for a JS Port. Having something that runs inside the browser doesn't seem relevant now everybody is familiar with Apps. So instead of having a JS Port that will have to run inside a fat web browser and after a more or less long "loading..." message, we could just have a R3 or Red App. This is only my opinion so it would be best to poll to know what other expect.      Regarding the console, I use it only to "do %myfile.r", so a very basic console is enough for me. I could even live without a console at all. Again this is my opinion only and I respect the fact that some other people find the console important.      Regarding multithreading, I find this is useful for anything related to user interfaces, this is probably mandatory for an arcade game and can benefit also for server side implementation. This is again my POV only.      This is a long and interesting thread as it gives a picture of where we are and possibly where we want to go. At this point of time, I would call for ideas rather than rejecting anything, then only later we could filter. posted by:   GregP     29-Sep-2014/10:19:24-7:00 I think we should approach this topic with more business sense and less "developer" sense. What derailed R2 was a failed business plan. There will always be some developer bickering about various implementation choices, but dealing with those differences is not what will move this project forward. If we're going to invest in developing R3 or Red further, then we need to have a clear understanding of how much money is available, what goals are going to be accomplished with the time that can be paid for, how that time and effort is going to be organized, and who is going to do exactly what, to achieve a particular list of end goals. Right now, there are no clear goals defining what needs to be done (and just as important, what the business purpose is for achieving those goals), but much more important, WHO can accomplish those goals, and how much time they have available to do the work. If we want to focus on producing solid releases for the most popular platforms, it's going to take more than a little pocket change. And if we're going to invest significant dollars, we need to know that we'll receive a useful product which can be used to produce reliable commercial projects - whatever technical choices are made about details of the implementation (I would focus on making the fewest possible changes, and adding the greatest number of features). In my experience, Cyphre has delivered some serious end results for a relatively small investment. He is very capable, and at the time when he did that work, he was interested and personally invested in completing the work. When my financial investment stopped, his work stopped, understandably. I would get the ball rolling by talking with him and getting a clear answer as to just how much time he has available to dedicate to this project, give him a list of requirements, and get an estimation of how long all that work would take to complete. Let him tell you who may be able to help, and see how much time those people have available. If Cyphre, Shixen, and others who have already worked on the R3 code base aren't available to do the work, perhaps they can at least provide some consultation as to what it would take to bring a new team of C developers up to speed. At this point, the most bang for the buck, and the most viable business goal, would probably be to finish "feature complete" ports to Android, Windows, Linux, and Mac, with all the networking protocols, graphics/sound/media, security, external library (DLL/SO) access, database drivers, encappers, etc. which were available in R2. I think, in particular an APK encapper for Android, which is not tied to the standard Android development toolkit would be a particularly valuable and potentially popular tool (no one here seems to agree, but I think web tools would be far more popular and commercially viable - that is the current direction of a huge portion of the industry, and the kind of developers who would most likely be drawn to the benefits of using Rebol are most likely found in that portion of the industry). Either way, I think the community would rally behind the basic goal of getting ports done with the features which made R2 "complete" and fully capable out of the box. posted by:   Nick     29-Sep-2014/12:12:34-7:00 Didn't R2 run in the browser as a cgi or fast-cgi? I also recall RSP and Cheyenne and saw a few mvc style apps out there in the browser. In that scope in a web based scenario are we trying to achieve the same kinda functionality as what I have mention or is it different? Also I like how you think the business aspect of this is paramount to any development efforts. Can you maybe reach out to the people you keep mentioning and get a feel for them assisting the effort as you have described. And also Peter Woods has a very very valid point in that all open bugs need to be addressed first. Let's move this to the other threads Fork created. posted by:   Patrick Stewart     29-Sep-2014/12:35:29-7:00 It was asked if anyone ever speaks to Carl. When Carl and I were at a gathering on Saturday, he mentioned that he speaks to HostileFork about once per week, and he appreciated being kept in the loop in this way. He also stated that he expects his interest in Rebol to be renewed in the future, although he didn't have a specific timeframe.      I passed on the SDK purchase from Patrick Stewart to Carl's wife, Cindy, so I know she is aware of it. I believe she is the one who either fulfills those orders or makes sure they are fulfilled.      I agree with the statements made by the community, like Nick and HostileFork. However, I don't think Nick has yet surpassed the amount of documentation written by Carl. However, Nick's work is very important, and I have republished some of his work in ODROID Magazine.      Just a few notes after catching up on the conversation. posted by:   Bo     29-Sep-2014/14:34:13-7:00 There are lots of things that can be done and sure, those who aren't going to do them can argue about priorities, but ultimately it's the developer who does them that decides. You can bounty as much as you like, but the guy who implements them is the one who decides. So, that's why I suggested console, and you could add others as well. But having at least one bounty up there ( the $$ held by a 3rd party ) can tell us if the money is actually there, and whether there is anyone willing and capable to do them.      I'm less concerned about business plans because we're not RT. We're not running on business selling Rebol3 to earn a living. posted by:   Graham     29-Sep-2014/14:47:08-7:00 Patrick,      The only code that runs in a browser is HTML, CSS, and Javascript. Any other client code that runs "in" a browser has been transpiled to the native JS environment. JS is like the "machine code" of every browser - you can't escape that.      CGI, RSP, and all are implemented at the server, and produce code which a browser can render - in the same way that PHP, JSP, Perl CGI, etc. do. But just as PHP code is never evaluated "in" the browser - only the RESULTS of it's evaluation are sent to the browser (as HTML, CSS, Javascript) - Rebol fast-cgi, RSP, apps etc. don't run "in" the browser. They just output HTML, CSS, and Javascript. The Rebol developer still needs to write Rebol code to *output* the appropriate HTML, CSS, and Javascript (i.e., the Rebol developer still needs to write the actual Javascript code, convert data structures to JS data structures, etc.). A JS port of Rebol would mean that the entire code base, both on the server (if there even is a server component to a given app) and in the client, would consist entirely of Rebol code and Rebol data structures through and through. You could build a graphically rich client application entirely with Rebol code, and the compiled Rebol interpreter, running on the web page, would run that app, without any HTML, CSS, Javascript code, layout, or data structures required at all. Data could be transferred back and forth to server apps (CGI, RSP, etc.) using entirely native Rebol data structures. Every part of the application could be created using pure, productive Rebol code and Rebol methodology.          Any web work I do lately necessarily requires using a JS framework (Webix) to create the GUI, which sends/receives data back and forth to/from the server using one of the data formats it handles natively (json, CSV, etc.)) Rebol gets used on the server to store and manipulate data (instead of PHP, JSP, etc). As nice as Webix is, any app with a big client front end still needs to be written in Webix (and adjusted with HTML, CSS, Javascript), needs to use its native data structures, methodology, etc. It's not Rebol.      For any sort of browser app which consists mostly or all of client code, you can't write that code in Rebol. The main problem which this community doesn't seem to care about is that web is absolutely one of the most prominent delivery mechanisms for modern software. It doesn't matter if we like it or not - that's the situation the world is in. GredP's point of view is that he'd rather work with native apps, but that's simply not the choice of the developer in most cases. If you want to reach an audience who will only work with your application on the web, then you can't currently write that application in Rebol. And the fact is, a huge percentage of modern mobile apps are also developed and distributed as packaged web apps. As a result, in that environment, developers simply CANNOT serve an enormous population of clients and users with Rebol. The writing on the wall seems so obvious. By developing the JS port, we would kill so many birds with one stone. You can PACKAGE a web (JS) app so that it runs just like a native APP on every modern mobile and desktop OS. So, that one JS port would cover so many of the needs developers may encounter for client and user application deployment. I can't understand why I'm the only one who sees this as a viable and efficient solution to a huge portion of our needs. But it goes beyond that. Doing the JS port would suddenly create a tool which would be interesting and useful to the ever growing throngs of Javascript developers (tens of millions of them). With JS maturely established in the browser (ALL THE WEB, for crying out loud), in cross platform mobile development (an absolutely enormous market segment), and on the server in NodeJS, that growing trend is NOT going to slow down any time in the near future. Whether we want it to or not. Put Rebol there, and it's got a very strong chance of actually attracting attention and USERS again. In that environment, Rebol could provide a unique and potentially productive solution for millions of working developers, where there currently is nothing comparable (JS with Node, and perhaps Java with GWT are really the only tool sets which may compare in that space). Without that attention, the business case for Rebol is limited to the motivations of those who are currently involved, and so far, aside from the investments made by Robert, me, and some of the community, on the Android and R3-GUI ports, Rebol has had to sit quietly waiting. The fact that it's not available on modern platforms (WEB and MOBILE, for anyone who has been alive for the past 7 years!), is the reason it's not being used by others. If developers could use it to create and deliver JS apps, Rebol would suddenly become a viable and practical choice for millions of active, working developers. Things would change, in the way hoped for by everyone who appreciates Rebol. I don't understand how much more clear this situation could be. That's where some business sense is needed. If we want to ignore use cases, and just talk about how interesting and beautiful Rebol is, and never see it used again to produce production code, then we should just continue to do what we've been doing. If we want to see it in use, we just need to get the relevant ports done. Although the hardest to complete, my vote is for a JS port first - I don't expect anyone to listen, though, and I would still be happy to see the Android, desktop, and server ports get completed ... as a start. posted by:   Nick     29-Sep-2014/14:59-7:00 My point of view is that no working developer is going to leave Java to work with Rebol full time, even if we get some stable, feature-packed ports done for native platforms. I do, on the other hand, see the potential for millions of JS developers to use Rebol as a productivity and workflow enhancing tool in their environment - in the same way that Java developers use Closure in the Java environment. At this point, completing ANY port, on any platform, to any degree, is helpful because it allows people to actually USE R3, and may potentially get more developers to become involved. If we're going to do that, then it just makes sense to go where the largest potential market and the lowest hanging fruit may be found. Creating a killer Android build, getting it in the Play Store and supporting it, would certainly be a good move, ESPECIALLY if language and feature compatible builds are available for Windows, Linux, and Mac, because that's a huge plus for any interested developer. I just see the JS developer market as being much more likely to actually put Rebol to use - JS is the new wild west of application development, and it's a tremendous and growing percentage of the market. posted by:   Nick     29-Sep-2014/15:18:36-7:00 @Nick, if you're asking for an emscripten build of Rebol3, that's nearly done if not done already. If you're asking for Rebol3 written in JS, then Gabriele tried that with Topaz and could not finish it. Potentially you're asking for several years of developer funding. And we don't really know if there is any money available. Let's see if something attainable can be done first! posted by:   Graham     29-Sep-2014/15:22:56-7:00 "the guy who implements them is the one who decides" - I agree. It's best if input from the developers using the implementation can be used to create the best solution, but I'd rather see actual working products with rough edges, than a perfectly designed imaginary product. posted by:   Nick     29-Sep-2014/15:26:36-7:00 @Graham, Emscripten build. That's most of what I've been railing about in this thread :) posted by:   Nick     29-Sep-2014/15:28:11-7:00 Let me restate a desirable feature list, and maybe others could chime in with other ideas which would make R3 "complete" for their needs:      1) graphics/sound/media features 2) network protocols 3) external library (DLL/SO) access 4) database drivers 5) security 6) encappers (especially an APK builder for Android) 7) console      Comparable or improved over those same features available in R2 (especially media). posted by:   Nick     29-Sep-2014/15:38:23-7:00 @Nick      If you want to see the Emscripten build, ask Andreas to release it. AFAIK, it's done. posted by:   Graham     29-Sep-2014/15:42:52-7:00 Last I heard there was some troubleshooting to do with the core version that Andreas had worded on. The bigger issue is getting View and R3-GUI ported to WebGL or some other browser based graphic renderer. Without graphics and GUI, there's no viable point in having an Emscritpen build completed. View and R3-GUI replace CSS, HTML, and all the JS stuff related to visual layout and presentation in the browser. posted by:   Nick     29-Sep-2014/15:54:44-7:00 I agree with Nick about business needs being important. And there are two sides to that: 1) What those who already use REBOL need, and 2) Who the target audience for REBOL is and what you expect them to build with it. I did a checklist long ago for Carl to prioritize, because knowing who your audience is tells you what features you need.      Then leverage what we have as much as possible and look for low hanging fruit. posted by:   Gregg     29-Sep-2014/16:39:16-7:00 @Graham      So are u saying you would be developing the console? Also just for the record I am running a business and if I put myself out there with funds generated by my business then I would have to disagree with you on if a business plan is needed. Now it may be that the terms are wrong and that a project plan would be more what should be being asked for instead of a business plan. But as a person of financial interest it would be suicide for me to invest in something that does not have a plan that would guarantee that any funds I put into it will actually render some tangible results according to a plan not a free for all. Your free to not care about that but seeing how I'm not pulling personal money out my pocket and indeed it is coming from the coffers of a running company a project plan or plan of action is required. Now we can do this by identifying things that need to be done the priority it means to the community which is fine with me and gives me a list that I can attach dollar amounts to offer them up and raise them if not acceptable till somebody takes up that task. I do however agree with you about everything else you said.      Now let me ask you this you say a console is needed but what do you think about peters suggestion that the current backlog of bugs should be the first pick in order to proceed .      Again I'm only looking for a list of issues bugs and features that are required to get a stable release out of that a plan of action can be formed real easy. So while you might be right about not needing a full blown business plan some form of a plan is needed because failure to plan is planning to fail and it's been my experience that it don't matter if your selling a product, providing a service, running a non-profit, or a open source project failure is a direct by product of not planning. Well if I start dumping funds into the bucket for developers to complete cycles I want it to succeed.      I also have to account for those funds from a business perspective so yeah in order for me to do anything I need some sort of plan to go by and again it doesn't have to be a book just something that lets me see what is needed lets me place bounties on those things and cross of items done till nothing is on it anymore that's all I'm asking for. But, make no mistake some form of plan is needed for this to have any desirable outcome. posted by:   Patrick Stewart     29-Sep-2014/16:46:35-7:00 @Gregg      Is that checklist still viable? If so that seems like a good place to start. posted by:   Patrick Stewart     29-Sep-2014/16:51:18-7:00 @Nick      I gotta say nick that I am inclined to agree with you on the JS port. The web ecosystem is huge right now and for the foreseeable future. If Rebol was ported to JS that would indeed be a huge addition to the web development community. So if there is already a port in progress what does the developer who did it need to finish it where does it stand? posted by:   Patrick Stewart     29-Sep-2014/16:59:09-7:00 @Graham      So who would be this 3rd party that would hold funds pledged for the bounties? Is there some form of service that does this kind of stuff or do you have someone in mind for this because i agree that is important. posted by:   Patrick Stewart     29-Sep-2014/17:03:13-7:00 @Bo      Thanks for the update on Carl and for passing on the info about my purchase appreciate that. posted by:   Patrick Stewart     29-Sep-2014/17:05:15-7:00 Nick, I agree with you that a JS port of Rebol (like Emscripten) would be a great benefit to Rebol. I've recently started developing in plain JS (not using any fancy JS-derived toolkits) and tying that in to Rebol3 on the server. I find that to be a good solution for me now, but it would be even better if Rebol ran natively in the browser so I wouldn't have to write document.getElementById() all the time. posted by:   Bo     29-Sep-2014/17:05:43-7:00 @Patrick      No, I'm not able to do the console.      There are lots of hire developer sites on the internet that could hold the funds in escrow. Or, you could just send portions to various trusted known current developers.      Regarding a business plan, I meant we as a whole don't need a business plan. We just want a final release. You need a plan since it's your capital.      As others said, pick the low hanging fruit and get that done. Aim for something like a JS port with all the GUI etc, and you'll likely end up with nothing to show for it. posted by:   Graham     29-Sep-2014/17:19:42-7:00 @Graham      Exactly, which is why i'm asking all these questions. Cause I need a plan and you folks are giving me one in all these responses. Just got to read and reread them making notes.      I understand the low hanging fruit element but can also see nicks point in a JS port hopefully we can pick some fruit and sip some Java (script)...      posted by:   Patrick Stewart     29-Sep-2014/17:56:23-7:00 Old checklists: http://pointillistic.com/open-REBOL/r3-target-audience-checklist.html http://pointillistic.com/open-REBOL/r3-dev-target-checklist.html posted by:   Gregg     29-Sep-2014/18:42:09-7:00 @Gregg      That's nice Gregg thanks for the links to both checklist. posted by:   Patrick Stewart     29-Sep-2014/21:29:36-7:00 @Bo      Thanks again Bo Cindy sent me my SDK license. :) posted by:   Patrick Stewart     30-Sep-2014/0:03:02-7:00 If some prototyping on REBOL/emscripten has already been made, do we have an idea of the JS build size? How much time will it take to load? posted by:   GregP     30-Sep-2014/3:46:36-7:00 I'm a bit surprised on how things currently turn. This thread started with: "I got the time, money and desire to help make this a reality" And now we're talking about bounties....      I thought this thread would first result into centralizing the community efforts, whether it is documentation, fixes, ports, ... posted by:   GregP     30-Sep-2014/3:55:16-7:00 There is a lot flying around, so we may all be confused. :) The great thing is that it has already resulted in *something*. Patrick has stepped up and gotten the ball rolling. I'm excited. posted by:   Gregg     30-Sep-2014/4:26:47-7:00 @GregP      And why does that surprise you? Let me break it down for you like this. I'm a newbie on the block and I feel (and i could be wrong but i doubt it) that i'am being tested by some members of the community and rightfully so.      my statement "I got the time, money and desire to help make this a reality"      has some saying nicely "stop asking questions then and kickstart something to get something happening or in laymen's terms put up or shut up" so launching some bounties came into play so in good faith I'm with it and is not a bad thing, i mean Red already got a server added to their build farm out the deal soooo.      In the end doing some bounties has no bearing on trying to centralize some things. That is my goal. However it was met with some resistance to which I really don't care about because it's still my goal to try and get the community to centralize efforts so I figure I got to walk the talk I talk.      However, in case you didn't notice when I started offering bounties most said something similar to this "hold on before we do bounties we need to do.... what?" basically centralize because once money came into play from outside your existing comfort zone I think it became real clear that a little bit more organization would be required to actually do effective bounties. And one community member proclaimed his enthusiasm and will be participating in putting up bounties in the near future himself. So it's not a bad thing at all.      However, I came in here riding two horses trying to get your attention and now that I have it I believe I have to show the community what I' am talking about and maybe just maybe they will appreciate centralization and use the tools to get some of this other stuff your talking about done. But I'm on my own on that and will get no help there so I must spend some time and money to provide a live implementation for the community to digest once I do that hopefully everyone will become comfortable and we can move forward.      This has been an interesting thread and it's exciting to watch all this knowledge and passion that the community actually has. I think when Carl returns he will be very happy with what you will have accomplished but we still got lots to do.      Simply put at first nobody cared about anything I was talking about, it took a few days to really get anyones attention I don't mind the bounties I got to earn the trust of the community and besides after checking into some things HostileFork pointed out bounties actually work. Now don't get me wrong I'm still thinking about trying to hire some developers that will put in scheduled time into development cycles but supplemented with bounties.      It's going to take me a few to get what I have in mind up and viewable by the community in order for it to be seen that centralization is not a bad thing. Also I must find a way to drive home that I am not trying to fork the project or step on Carl/RT toes or anybody else's I just want to provide what I know can put this project in scope and when Carl decides to do whatever it is he is gonna do If he approves of what has transpired we can migrate systems and centralizations to the Rebol domains or whatever it is that everyone is waiting on. But I must tread lightly because this community is loyal to Carl so the best that I can do is attempt to have Carls back as others have in his absence as a facilitator and motivator because that's all I can do and hopefully we can do him proud when he returns to which he will, believe that.      Right now I'm only looking to provide an official temporary infrastructure (you folks do represent the official community ya know) in another location/domain and only because we don't have total access to any of the ones up currently once that's resolved anything we do can be migrated where it's supposed to be. What I'm trying to avoid is anyone thinking I'm preaching abandoning Carl or trying to run off with his work as a fork because I'am not, I don't want Hostilefork saying we can't use the Rebol branding he created, I don't want Andreas saying we can't use the Rebol branding HostileFork assigned to him. I just want to create an official centralized Rebol community out of all this Rebol passion fully recognizing Carl and his work that hopefully will find it's permanent home when Carl does whatever it is the community has been asking him to do. But we do need a centralized home to represent and nobody is going to take on that challenge but me.      I believe in you as a community, I believe in Rebol, I believe in Red, Honestly, In my opinion after playing with R2 I think in a lot of respects Carl was ahead of his time some because Rebol is ridiculously powerful and as much of a viable solution today as it was 15 years ago.      There's a lot of good information floating around up in here some way above my head but at the end of the day I know what to do, it's what I do best.      I'm a business man, I have been most of my adult life, t's what I know and I know we need a professional presence to splash with this passion, to motivate and represent us at our best. So I will take a gamble by doing some of the things I'am about to do.      Stay tuned I will bring forth more fruit and then we can eat..... posted by:   Patrick Stewart     30-Sep-2014/5:31:58-7:00 What is R3 really lacking for the interface purposes and I find it really important - is the R2 level CALL external apps function. R3 has much simplified implementation, which does not easily allow to get output of external app into the Rebol app. Red implementation source could be used as a reference implementation, of course, if Boost SW license is compatible with Apache 2. Here's the link: https://github.com/red/red/tree/master/system/library/call posted by:   -pekr-     30-Sep-2014/6:37:37-7:00 Request Features/Improvements/Etc List. Compile list (trim to an agreed initial minimum). Vote on list. Set bounties/dates/etc.      Luis. posted by:   Luis     30-Sep-2014/7:33:32-7:00 An accounting or law office might be interested to be the 3rd party to hold bountie funds. There might be little or no charge for this. There may also be some anticipation of future work that would attract standard fees. This would likely be needed as the organisation grows. posted by:   Felix     30-Sep-2014/7:43:41-7:00 As things progress here, maybe it would be good to organize some sort of meeting. Whether in person or in an online conference, speaking in person might help to strengthen the possibility for some genuine momentum and results. Even a quick video conference may be useful to personally introduce newcomers and to reconnect old community.      I do like the written format online - it's an efficient and comfortable way for the group to express and work through ideas in a sustainable way. And it's always difficult to organize a group meeting. I don't recommend anything elaborate - maybe even just a few phone calls between groups working on a given goal. A little bit of effort in person can just do wonders to motivate action. posted by:   Nick     30-Sep-2014/11:08:48-7:00 I'd like to talk more about the centralization issue. Can we come to a consensus about a name and URL for a permanent 'official' home for R3? I like the idea of making a clear break from R2. I think "OpenRebol" is effective. It clarifies the open source nature of R3, and clarifies the new and refreshing direction of any releases produced by the effort. The power of having a single 'official' location for binary and source distributions, documentation, forum, etc. even if it just contains links to repositories and resources which are hosted elsewhere, is important for community growth. Without that single official starting point, new community members inevitably miss parts of the currently fragmented community establishment. I don't think Carl has expressed any worries about his project being 'hijacked'. On the contrary, I think he's out of the game for the time being, and would likely welcome any organized and effective progress regarding Rebol. (I'd love to hear him chime in here).      I prefer to avoid too many long and drawn out arguments about complex infrastructure decisions and distant future needs. At this point, I think a URL with a simple web page, a logo which represents the current group coalition, a brief introduction to the project, and links to whatever repository we choose to be 'official', perhaps a well known PHP forum, perhaps some established wiki software, and most important, an organized page of links to documentation which currently exists. I think the most important thing is for everyone to agree that one particular URL, whatever it is, is the home page of this particular 'movement'. Anyone can start their own 'movement', and hopefully any such offshoots can all work together, but having that one place to link resources and communication, that's what's needed to build a community. And links to *everything* in the existing Rebol world should be found there. We just need one place for people to start their search and exploration, and a place for all new work to be collected and organized. I'd be happy to help with that work, provide some simple shared hosting space if needed, install and customize some software to make it operate, etc.      I'm curious to hear what everyone else thinks is a realistic, hopefully simple, doable way to complete that effort. posted by:   Nick     30-Sep-2014/11:38:40-7:00 The choice to continue now after waiting almost 2 full years on a domain away from the original is right. No use in waiting longer and longer and never see progress from the community because there are no handles to control. OpenRebol is fine, and it will be clear that the project is a continuation, not a (hostile) fork. posted by:   Arnold     30-Sep-2014/15:01:28-7:00 Nick, what about the openrebol repository on github? It's not that I love github but many contributors already have an account there and it's just a matter to push. Also, it is group owned, not just one guy. We can make a repository + wiki + static web site. BTW, do you have a github account so I (or some other owners) could send you an invite? posted by:   GregP     30-Sep-2014/15:03:34-7:00 @GregP,      I'm willing to go wherever everyone else is willing to go. Patrick already owns openrebol.com, but it's just parked at Godaddy. Patrick do you have hosting set up for that domain? What are all the other options that everyone would like to consider? posted by:   Nick     30-Sep-2014/16:11-7:00 @Nick      Nope, I do not i was actually working on a deployment strategy because I was trying to give the community a live presentation on what the community could be represented like and it's a turnkey solution meaning take it and run with it. Sometimes seeing is believing and believing is understanding so I was in show an tell mode only because it seems when I first tossed that out there that some didn't really grasp what I am really trying to give up.      Anyway I got something to say some of it is directed specifically at GregP.... posted by:   Patrick Stewart     30-Sep-2014/17:10:36-7:00 Yeah, Never mind anyway      @Nick do you have a place I can transfer control of these domains to.      The domains acquired for the community not owned by me if you want them which i think you should.      openrebol.com openrebol.org openrebol.net openrebol.us openrebol.info openrebol.academy ( I was actually thinking of you when I selected this one because you be writing some nice tutorials and stuff)      Since the repo has been created then please except these domains to add to them. Hopefully the rest of the community will agree to that and they can be put to good use.      I will monitor things, don't be strangers my email is up top. If you figure out how to do bounties let me know I'm game to fund some. Or if you need something just ask.      Now I got to go write a report, blah hate that lol                     posted by:   Patrick Stewart     30-Sep-2014/17:52:57-7:00 "If you figure out how to do bounties let me know I'm game to fund some."      what i meant is you folks are the best ones to put a bounty out there i don't know enough to do it they way it was suggested if the community could take that up it would be easier for me to participate. posted by:   Patrick Stewart     30-Sep-2014/17:58:36-7:00 Thanks for your enthusiasm and first steps Patrick. It sounds like we need you a lieutenant. That is, you need to make the final call on what you want to support, but someone can sift, filter, suggest, and help. Everyone is biased, so find someone you think meshes well with you, take your time, and here's to making a REBOLious future! posted by:   Gregg Irwin     30-Sep-2014/20:50:28-7:00 Please ensure, whichever way it needs be done, that 'REBOL' (as in 'OpenREBOL') can be used without repercusions/prejudice now or in any future/multiverse (assuming this one is the originator). Once bitten...      Luis. posted by:   Luis.     1-Oct-2014/3:52:41-7:00 The various comments regarding the reuse of logo or name push to conclude that to avoid any legal issues, it would be wiser to make a disruptive fork with a new name and logo. posted by:   GregP     1-Oct-2014/5:01:24-7:00 I don't think a disruptive fork is the answer I believe that you represent the official community as most of you if not all of you have worked directly with Carl on this.      Why not just ask Carl if it would be ok for the community to setup shop in a community repo called OpenRebol using the OpenRebol domain names so that you can work together in an open fashion taking some of the pressure off him to make any decisions regarding RT controlled repos and domains for the moment.      I see plenty of community domains using rebol in the name like learnrebol and rebolsource are these sites not owned by RT? I believe when In doubt ask. OpenRebol is perfect for the official community and only represents the openness of rebol as released by Carl not as forked by someone else as the official community it fits if and when Carl comes back or decides to give up domains simply point the rebol domains to the OpenRebol ones and do a DNS overlay then both resolves to the community infrastructure it's a no brainer just ask him. Your not trying to fork and rebrand your just trying to represent and collaborate openly in his absense that's all posted by:   Patrick Stewart     1-Oct-2014/5:47:25-7:00 I hate to ask a remedial question, but I am having a little trouble following parts of this discussion because I am not sure I understand the meaning of a "javascript port."      In a compiler scenario, I would expect that the C code for REBOL would be run through a compiler and the output would be an executable program, like rebol.exe.      Does a "javascipt port" of REBOL mean that the REBOL C source code would be run through some program and the output would be a monstrous javascript program, like rebol.js which would be the REBOL interpreter written in javascript, and that monstrous javascript program called rebol.js would be called in a web page something like this: