1. Equal branch
- Posted by andi49 Jun 25, 2014
- 1709 views
Hi
I have build the 'Egual' branch on Windows (32bit). Seems to compile out of the box. But what is the diff to the default branch? There is nothing in the created docs.
Maby the changes in the branch can be documented in the Doc's.
Andreas
2. Re: Equal branch
- Posted by jimcbrown (admin) Jun 25, 2014
- 1716 views
Hi
I have build the 'Egual' branch on Windows (32bit). Seems to compile out of the box. But what is the diff to the default branch? There is nothing in the created docs.
Maby the changes in the branch can be documented in the Doc's.
Andreas
It's a prototype branch to demonstrate feature changes. These changes may not necessarily ever be merged into the mainline - the branch is intended to demonstrate what can be done, but not necessarily what should be done.
In addition, even if a feature is later agreed upon and implemented, the prototype implementation may be found wanting (e.g. it may have serious performance problems), so even in that case changes originating from this branch may never make it into the mainline.
Basically, it's a place to stage demos.
Currently, it implements the following proposals:
append() and prepend() support using atoms as the first parameter.
sequence operations (e.g. and_bits({1,2},{2,1}) ) support sequences of differing lengths - the extra elements in the longer sequence are preserved unmodified in the result (aka the seqop nop standard). Previously, it truncated to the shorter of thw two sequences (aka the seqop truncating standard).
Sequences can be used as true/false values. An empty sequence is false, anything else is true (aka the false sequence standard).
Doing logical comparison in an if/while statement is the same as calling compare() or equal() (aka the DerekParnell standard). Previously, this was extended to all uses of logical comparison, even assignment to a variable (aka the no-seqop standard), however that is a backwards compatibility breaking change.
A new addition to the standard library is provided. Based on code by Pete Lomax, it implements the sequence operations purely through high level euphoria code. (This is probably not needed, it was intended as a replacement for backwards compatibilty reasons for any code that relied on the old seqop behavior if the no-seqop standard is adopted. An example of this is the 3.1.1 lower() and upper() routines.) Also, this library is entirely undocumented.
The reason these features in the branch are undocumented is because I'm too lazy to write docs for features that might not ever get put into the mainline. If they were mainlined, I'd still prefer to trust _tom's documentation skills over my own.
3. Re: Equal branch
- Posted by mattlewis (admin) Jun 26, 2014
- 1620 views
The reason these features in the branch are undocumented is because I'm too lazy to write docs for features that might not ever get put into the mainline. If they were mainlined, I'd still prefer to trust _tom's documentation skills over my own.
I would recommend updating something in the release notes, if only to track it and know what we need to document. Maybe add a secion to the current 4.1.0.txt file for your branch. That way, it identifies what's there, and should stick out when it gets merged so we can remember to fix up the main release notes and other docutentation.
Matt
4. Re: Equal branch
- Posted by andi49 Jun 27, 2014
- 1535 views
It's a prototype branch to demonstrate feature changes. These changes may not necessarily ever be merged into the mainline - the branch is intended to demonstrate what can be done, but not necessarily what should be done.
In addition, even if a feature is later agreed upon and implemented, the prototype implementation may be found wanting (e.g. it may have serious performance problems), so even in that case changes originating from this branch may never make it into the mainline.
Basically, it's a place to stage demos.
Okay, i understand this.
But how could somebody test the changes if there are not documented? And more, there are no builds for this branch to download. Who should try them?
Only developers?
Maybe the changes are really expected ;) but noone can vote for them (they just do not know) ;)
Andreas
5. Re: Equal branch
- Posted by jimcbrown (admin) Jun 27, 2014
- 1568 views
It's a prototype branch to demonstrate feature changes. These changes may not necessarily ever be merged into the mainline - the branch is intended to demonstrate what can be done, but not necessarily what should be done.
In addition, even if a feature is later agreed upon and implemented, the prototype implementation may be found wanting (e.g. it may have serious performance problems), so even in that case changes originating from this branch may never make it into the mainline.
Basically, it's a place to stage demos.
Okay, i understand this.
But how could somebody test the changes if there are not documented?
If they've been following the threads I've updated, then they'd know what to expect and how to use them. Other devs are the main audience for this - though I welcome anyone who wants to try it to go ahead.
Docs will come eventually, but I should finish the changes first. (I haven't finished fixing the translator to implement some of the new features, for example.)
And more, there are no builds for this branch to download. Who should try them?
Only developers?
The main audience is other developers. However, I did take the time to update eu.ex (or rather, execute.e ) in a way so that a person can just run eu.ex to demo the changes with a 4.1.0 beta eubin, without the need to actually build anything themselves. The changes should be implemented in an identical way (though I suppose there's always the possibility that I missed something, causing an edge case where the Eu and C backends differ in behavior).
6. Re: Equal branch
- Posted by SDPringle Jul 01, 2014
- 1484 views
Writing documentation for something should be easier than writing the code.
7. Re: Equal branch
- Posted by DerekParnell (admin) Jul 01, 2014
- 1452 views
Writing documentation for something should be easier than writing the code.
LOL ... that's a joke right?
8. Re: Equal branch
- Posted by SDPringle Jul 01, 2014
- 1435 views
Writing documentation for something should be easier than writing the code.
LOL ... that's a joke right?
No. I am of course not talking about documenting someone else's work. That's going backwards. First the documentation should be written and then it should be implemented. If one is too lazy to do both parts, he ought to the documentation part. The code can be written by someone else if the docs are any good.
Shawn Pringle
9. Re: Equal branch
- Posted by jimcbrown (admin) Jul 01, 2014
- 1501 views
Writing documentation for something should be easier than writing the code.
LOL ... that's a joke right?
No. I am of course not talking about documenting someone else's work. That's going backwards. First the documentation should be written and then it should be implemented. If one is too lazy to do both parts, he ought to the documentation part. The code can be written by someone else if the docs are any good.
Shawn Pringle
Writing technical documentation - especially for a layman/beginner's audience - is very hard and in fact qualifies as its own occupational specialty: http://www.bls.gov/ooh/media-and-communication/technical-writers.htm
I'll go as far as to assert that there exist people who have the technical skills to control a computer by programming it, but lack the communication/social skills to explain things clearly to others. I don't think I'm the only one who asserts this: http://www.bizjournals.com/cincinnati/blog/2013/07/tech-companies-want-to-hire-it-grads.html?page=all http://www.thefiscaltimes.com/Articles/2014/01/29/Surprising-Reason-College-Grads-Can-t-Get-Job http://business.time.com/2013/11/10/the-real-reason-new-college-grads-cant-get-hired/
So, no, in the general case, I don't believe it is easier to write good documentation than to code. In fact, I strongly suspect the opposite is true.
That said, the real reason I haven't documented anything yet is that I'm lazy. The documentation already exists - in the threads where the features were discussed. I simply need to copy and paste the widely dispersed pieces into a coherent whole and stick them in the right place.
Even if _tom or someone else ends up rewriting the whole thing (as he probably should), having the original developer's docs as a guide would probably be helpful.
Anyways, I just spent the past few days working with Hostwinds (the new host) and euphoric and a few others (RC gets a mention here) to get the site back online after the whole Burst.net issue lead to an unexpected outage. So I'm more or less tapped out for now.
Of course, if you really find this state of affairs really intolerable, you can always put the documentation into the branch yourself. Like I said, it's already documented on the forum (well, more or less) if you know where to look. And anything you write will mean less work for me to finish documenting later.
