Re: Source changes
Juergen Luethje wrote:
> Sorry, I disagree.
> While knowledge of C and SVN is necessary to make changes to the
> language,
I suggested that developers should be able to build on at least
one platform (using a C compiler), but actually, since most
Euphoria libraries are written in pure Euphoria, and the
front-end is written in pure Euphoria, I would accept
new developers who do not know C or have a C compiler set up
on their machines, as long as they are just changing Euphoria code.
They would have to test their changes by running eu.ex
(slow Euphoria-coded execute.e as back-end) or int.ex
(newly-available in 3.1, front-end can be interpreted but
calls fast C-coded back-end via machine_proc()).
SVN is just a tool for copying source files from a common
repository, and checking them in again, when you want to
officially change them. It has features that help you to keep
track of what you have changed, and resolve conflicts with
others who (rarely) may happen to be working on the
same file at the same time. I think anyone could learn the
basics of SVN in an hour or two. Like most mature tools,
it has lots of advanced features that are rarely used by beginners.
TortoiseSVN for Windows makes things particularly easy.
You just right-click on a file and it gives you menu of things
that you can do with that file, such as check it in (commit it).
> this does not mean that everyone who meets these requirements
> will make sensible changes. Sometimes (often?) less is more, and
> sometimes (often?) it is better _not_ do do particular things.
Very true.
> Maybe there should be a democratic vote about proposed changes? While
> this cannot be perfect, it probably would be much better than allowing
> everyone with knowledge of C and SVN to change the language.
We may eventually need a formal voting system, but at the
moment we are still "playing it by ear", trying to get
an informal, rough consensus on any changes.
> > Besides, in the future, if there are
> > any bugs in get() or value(), we'll have someone to turn to,
> > other than me. 
>
> I can understand, that you appreciate it when Euphoria is more and more
> taken over by the community. And of course this is a "natural" process
> after something has been made open source.
Having recently read "Wikinomics: How Mass Collaboration Changes Everything",
http://www.amazon.com/Wikinomics-Mass-Collaboration-Changes-Everything/dp/1591841380/ref=pd_bbs_sr_1/103-7756507-1669435?ie=UTF8&s=books&qid=1183395126&sr=8-1
I am optimistic that open source is the right way to go.
Although bugs will be introduced at a higher rate, (especially as
developers are first exposed to my complicated code),
I think they will be fixed at a much higher rate than before.
Think about the recent find_from() bug that you helped resolve:
Someone detects it, other people come up with simpler examples,
someone else goes into the C code and suggests a fix. By the time the
developer wakes up in the morning, most of his work has been done!
Then someone else (me) eventually re-releases it.
Many hands make light (and fast) work!
> However, in the past another advantage of Euphoria has been its
> reliability. Every change introduces the risk of new bugs. So changes
> that have almost no benefit better shouldn't be made.
> As far as I can see, _currently_ get() and value() are not buggy ...
>
> So maybe you can firstly release a bugfix release of Eu 3.1, without
> any other changes? This would be important in order to provide a stable
> version which we can use for building reliable programs. I would
> appreciate it _very_ much.
I'd like to do a 3.1.1 release within a few weeks, rather
than a few months (like the past few releases).
A major advantage of SVN is the ability to look at diffs
in source files, identify the causes of bugs,
and undo changes that we decide are bad ones.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
|
Not Categorized, Please Help
|
|
