Comments on: Catching up on Git and other advancements
I'd like to catch up on R3 github and any other advancements before attending Montreal. I'm quite far behind on GIT, and I don't have a huge amount of time -- just a few hours on evenings and weekends.
I know there's a parallel repository that's moving forward in my absence, and I think that's a good idea, but I still care about what's in the base build and want to go over it to see what's new.
So, any advice is appreciated. Thanks.
9 Comments Comments:
Maxim Olivier-Adlhoch
29-Jun-2013 18:05:31 |
You'd have to get in touch with Andreas Bolka. AFAIK he's the person with the most knowledge about latest developments on R3 sources.
both at saphirion and the alternate community-driven repo. | Maxim Olivier-Adlhoch
29-Jun-2013 19:26:25 |
The community Repo is here:
https://github.com/rebolsource/r3 | Fork
30-Jun-2013 1:24:11 |
We're in a bit of a holding pattern (at least speaking for people like myself) due to taking a step back, and wanting to solve big picture issues rather than worrying about isolated patches during Rebol's transition to an open-source project.
Rebol3 is a quite mature codebase and hard to crack into for many. Especially since most Rebol followers have chosen—on principle—to not become too familiar with the likes of C (...or HTML, or CSS, or JavaScript for that matter.) This means the existing community is not a huge source for fixing problems, so laying the groundwork for being able to accept community growth will probably bear more fruit.
One example, I found a tricky bug regarding the hashing of word names:
https://github.com/rebol/r3/blob/master/src/core/c-word.c#L237
If you read it closely: you can see that things like case-insensitive four character comparisons are matching MMAP_MAP_ANONYMOUS and mmap due to an improbable (but possible) hash collision. Thus it gotos out of the loop when it shouldn't. :-(
I have an inefficient fix (required to run Red under Rebol3, BTW). But without confidence that there is a chain of command to accept these fixes, it doesn't really serve a lot of purpose to submit them for review. Right now what we need is to unblock the chain of command so that we enter a "virtuous cycle" of improvement. To me Rebol's technical bugs are of slight concern compared to any perceived competition, it's cultural bugs!
My hope is that our "summer vacation" in Montréal will be just the thing to found a workable governance model. Which will be nice when I can get back to coding instead of making politically-oriented slide decks. :-) | Andreas
30-Jun-2013 2:28:15 |
For starters: here's a summary of changes in the "community" branch compared to your "mainline":
https://github.com/rebolsource/r3/compare/master
For an even briefer summary of changes, here's the "shortlog" of changes (without merges):
https://gist.github.com/anonymous/41b4c2cbe44687af2e39
More detailed response later. | Andreas
30-Jun-2013 15:55:06 |
Carl, I've also created a "summary" pull request on GitHub, which allows you to re-integrate everything that has been merged into the community repository back into the mainline repository with a single click:
https://github.com/rebol/r3/pull/119
Even if you don't want to merge that wholesale, the "commits" (https://github.com/rebol/r3/pull/119/commits) and "files changed" (https://github.com/rebol/r3/pull/119/files) tabs should help in reviewing the changes. | Carl Sassenrath
6-Jul-2013 12:28:02 |
First, many thanks to Andreas for organization and management of github. And second, thanks to all of you who've been pushing ahead and making fixes and improvements.
- Andreas, thanks for those links. Although the single click merge is tempting, I'd like to familiarize myself with each submission. And, I'm not sure what would happen in the case where I decide not to accept a submission or move it to a separate fork (of course, there can be a few reasons for that.)
- Fork, regarding your comment about "not everyone can contribute to the C base," I understand what you mean. And, most of it is not a code base for casual coders either. Although the code is well structured and documented, there are many implicit rules. Simple bugs should be easy to fix, but adding anything that requires knowledge of the architecture and the subtle rules of memory management or evaluation ordering can be tricky. There are also rules to ensure cross-platform compatibility. But, all that said, I expect a few of you gurus have reached that level of understanding by now.
- Also, I really want to reply to your note about a workable governance model and your comment "Which will be nice when I can get back to coding instead of making politically-oriented slide decks."
I totally agree! Working at Roku has taught me a lot, or more correctly, it's brought me back in-line with a mindset I once had about getting things done. I think it's too easy for scientists, engineers, and programmers to get caught up in small tweaks and miss the bigger picture.
I find it helpful to relate it to building something truly physical, let's say a fine Formula 1 race car. We often get so engrossed in perfecting the shape of some small valve that we don't step back and realize that the car is still on the rack, has no wheels, and isn't going anywhere. This happens not just to us, but to anyone who works on system/programming projects. Our personalities are such that we get great enjoyment out of solving intricate little puzzles. But, that doesn't get the car on the track, and it certainly doesn't win the race.
So, I think it's important to figure out a plan, take the big to-do list and sort it into what's really critical to finish, and what can be done as research projects for special teams.
- I've got a good example, something very practical, that will be my presentation for the ReCode conference. I'll be posting an explanation as to why I picked the project in a separate blog article very soon.
In my mindset the bottom line is that we've got to get practical and push forward. There are bound to be a few difficult decisions, we may make some mistakes, but let's do our best to get things moving quickly again.
| Maxim Olivier-Adlhoch
7-Jul-2013 19:16:08 |
The governance model is the main reason I wanted as many Rebol experts and Gurus at the table at the same time...
I can say that although I would have like to get a bit more representation from the old world, we do have a heap of the top Rebol minds comming to the ReCode Devcon, so its going to be the perfect place to iron out the governance, community and model for mainstream Rebol going forwards.
Anyone who has topics to discuss about these, or related issues should tally them and bring them to the devcon where I have reserved an open session for such discussions. | Carl Sassenrath
10-Jul-2013 21:05:27 |
Thanks Maxim. I'm looking forward to those discussions. It will be interesting to see how developer goals mesh. | shadwolf
18-Jul-2013 16:58:49 |
you know me ... deficite of C coders is comprehensible
rebol is opensource but still unknown so not a C programer attraction (or funland ..).
Once you coded with rebol doing it is hard to put a ton of efforts to write a source code in C.
There is not an organisation that promote a vision with concrete schedules release plan financement. Saphir intend that but they are still too much closed and shaddy to be a success.
My point of view is that we have rebol opensource but still not a release or plan on regular release. We don t even know what is missing to go rebol3 out of alpha. juste changing the labels? a linux GUI? a macOS X GUI? a 64 bit version of rebol3 on every main OS? a version on android ?
and it is not multiplying the rebol 3 reboots to other os that we will set score be notice and attrack tons of C coders.
PErsonally I still try to get a concensus on how we will achieve to do the gui only once for all OS. and be able to use full power of modern video cards.
|
Post a Comment:
You can post a comment here. Keep it on-topic.
|
