[ci skip] You can view, comment on, or merge this pull request online at:https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/350 Commit Summary
File Changes
Patch Links:
— |
Hi All, This adds two guidelines to CONTRIBUTING.md following on from the coding convention discussion that Ben started (and which is still ongoing) (thanks, Ben!): - Separate function declaration type and name to two lines - Tabs are 4 spaces Since this is intended to become the documentation, it is written as a fait accompli, but I of course welcome discussion. Cheers, Alistair On Sun, 6 Jan 2019 at 08:09, akgrant43 <[hidden email]> wrote: > > > > [ci skip] > > ________________________________ > > You can view, comment on, or merge this pull request online at: > > https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/350 > > Commit Summary > > CONTRIBUTING.md: Add some style guidelines > > File Changes > > M CONTRIBUTING.md (39) > > Patch Links: > > https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/350.patch > https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/350.diff > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. |
In reply to this post by David T Lewis
@fniephaus commented on this pull request. In CONTRIBUTING.md: > @@ -212,3 +212,30 @@ If you were working on a feature branch, do this: If your feature branch is ready or you are an external contributor with your own fork, use the github web interface to open a pull request. + + +# C Source Code Formatting + +When editing an existing file, please be polite and first follow the +guidelines below, and secondly follow the general rule of keeping to the +same formatting conventions as exist in the file. + + +## C Function Declarations + +C function declarations should have the type on one line and the +function name and parameters on the following line, e.g.: + +``` Adding a c to the end of this line should enable C-syntax highlight. In CONTRIBUTING.md: > + +C function declarations should have the type on one line and the +function name and parameters on the following line, e.g.: + +``` +static int +convertCopy(char *from, int fromLen, char *to, int toLen, int term) +``` + +This facilitates searching for function definitions by searching for the +name at the beginning of the line. + + +## Tabs are 4 spaces + +The heading says it all. I'm afraid the title doesn't answer the question when to use spaces/tabs? Are tabs banned? — |
In reply to this post by David T Lewis
@nicolas-cellier-aka-nice commented on this pull request. In CONTRIBUTING.md: > + +C function declarations should have the type on one line and the +function name and parameters on the following line, e.g.: + +``` +static int +convertCopy(char *from, int fromLen, char *to, int toLen, int term) +``` + +This facilitates searching for function definitions by searching for the +name at the beginning of the line. + + +## Tabs are 4 spaces + +The heading says it all. A side note: the legacy platforms/win32 is using these settings: 8-space tabs stops I don't want to create massive change of ownership for fixing that... — |
On Sun, 6 Jan 2019 at 18:57, Nicolas Cellier <[hidden email]> wrote:
Side question: (I've been meaning for a while to ask...) I've understood the minheadless arrangement aligns with Pharo's vision from years back and it seems destined for Pharo 8. I've been curious what the perspective is from the Squeak side, so the use of the term "legacy" here caught my attention. I know Squeaker's are more concerned about backward compatibility and I guess the minheadless requires significant image changes that might complicate that. Has it been discussed by the Squeak Oversight Board? I've seen Nicolas recently synchronising the minheadless and original platforms. Knowing whether everyone is aligned with a future move to minheadless, or otherwise knowing what concerns there are would help my own approach to working between the two streams. For example, for file that are identical between the two, perhaps its useful to have one be empty except for a #include of the other ?? btw, to familiarise myself better with minheadless I produced and overview spreadsheet. Its incomplete and quite busy, but perhaps of use to others. Feel free to update it as you see fit... https://docs.google.com/spreadsheets/d/1HnHzPPM0-OBF7oJt49YIrTCMqwfq7ggdMHQcVwQHOTU/edit?usp=sharing cheers -ben |
Hi Ben, Le dim. 6 janv. 2019 à 15:53, Ben Coman <[hidden email]> a écrit :
I don't know if this was dicussed in last meeting because i missed it (blush!) :( But it would sure make a good subject. All I will say here is my own opinion, not that of the SOB.
A minimal headless is interesting per se, whatever the Smalltalk flavour. I'm thinking of embedding a VM into another app for example (even if not with power of full Smalltalk IDE). The goal to replace low level GUI with alternatives (SDL2 or whatever) is also interesting. So my own motivations are: - curiosity - to not let good initiatives rot - to not take risk of breaking just freshly commited minheadless code by my own UNICODE cleaning - to verify compatibility and study eventual possibility to reconcile
In short term, duplicating code can be OK, but not sustainable in mid term IMO we already have too many duplicated things (particularly for building, the mvm scripts, the plugins.int/ext as you shown recently etc...). Forking is super easy, but then maintaining all the copies is close to impossible. All the good refactorings included in minheadless could be re-integrated in a shared core. (minheadless is very close that what the core should be since minimal...). And all the headfull extension cleanly separated. But this is some more work! minheadless has gone half way, which is already something.
At one moment, we also need paperboard |
In reply to this post by Ben Coman
Hi Ben-- > I've understood the minheadless arrangement aligns with Pharo's vision > from years back and it seems destined for Pharo 8. I've been curious > what the perspective is from the Squeak side, so the use of the term > "legacy" here caught my attention. I know Squeakers are more > concerned about backward compatibility and I guess the minheadless > requires significant image changes that might complicate that. Has it > been discussed by the Squeak Oversight Board? Not yet. I put it on the agenda for the 2019-01-16 meeting. thanks, -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco [hidden email] +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
In reply to this post by David T Lewis
Hi Fabio & Nicolas, Thanks for your feedback and my apologies for not responding, I've been caught up with other things the last couple of weeks. I haven't forgotten and definitely not ignoring this. Cheers, — |
In reply to this post by David T Lewis
No worries at all, there's no rush. Have a great weekend... Fabio — |
In reply to this post by David T Lewis
@akgrant43 pushed 1 commit.
— |
In reply to this post by David T Lewis
There haven't been any more comments for a couple of weeks. I'm not particularly happy with the section on tabs vs spaces, however it's always easier to criticise someone else's work than start with a blank slate, so take this as inspiration! :-) [ci skip] — |
In reply to this post by David T Lewis
Closed #350. — |
In reply to this post by David T Lewis
Reopened #350. — |
In reply to this post by David T Lewis
Merged #350 into Cog. — |
Free forum by Nabble | Edit this page |