text:
Talk:C++ Programming/Conventions/Archive 1

Common Programming Errors
It would be nice to point out some common programming errors, pitfalls and the like by highlighting it. Many books on programming have an inset with an icon indicating the type of the inset (general notes, common errors made in general & errors made mostly by people coming from some background (e.g. in our case a C or Java background may cause some confusion in people adopting C++), general pitfalls, pitfalls in some C++ implementations, etc.) beside it. We could also probably do something similar. There is already a common programming error in Programming:C plus plus Hello world. -- Paddu 12:46, 16 Dec 2003 (UTC)
 * What about Programming:Improving programming skills that will assume knowledge of programming and just focuses on improving style/skill so on? Dysprosia 07:01, 22 Feb 2004 (UTC)

 * Dysprosia, did you mean to respond to section 2? Section 1 deals with errors in programming, not styles. -- Paddu 08:01, 22 Feb 2004 (UTC)

 * This could be done with something similar to infoboxes in Wikipedia -- Paddu 20:45, 17 Oct 2004 (UTC)

Brace Style
An important problem is how to have NPOV in the indent styles of examples. -- Paddu

 * Present all the styles and "let the reader decide"... at least that is my idea. -- Emperorbma 19:59, 16 Dec 2003 (UTC)

 * I didn't quite get that. Obviously each example cannot be presented in all styles. So we should present one particular example in all styles & the rest all in the same style as a `convention we'll adopt in this book' (which may itself be controversial). But then the example must be comprehensive enough (to include, e.g. cuddling of else, do-while, etc.). Then what about the examples which are presented before this comprehensive example? -- Paddu 07:37, 17 Dec 2003 (UTC)

Separate Chapters
y not split the content into different chapters? --Yacht (talk)Q 02:48, 21 Feb 2004 (UTC)

 * Follow the link to "your first program". I have been making separate chapters. I am just reluctant to make N different pages now itself (them each would be with nothing more than a few lines). Once each chapter is sort of complete, content from here would be moved there and a link added here. -- Paddu 06:47, 22 Feb 2004 (UTC)

Broad overview ?
Sorry to ask, but do you think you have here a broad overview of C++, like the first chapter in Kernighan & Ritchie ?

Now the same subjects would have to be expanded in specialized chapters, right ?

Hgfernan 12 May 2004

What must be covered
IMHO there should be a book covering C++ without reference to platform & non-ANSI libraries, so that people who want to use various C++ libraries can first get to learn C++ per se. And, IMHO this is that book. Of course, there could/should be books about the various C++ libraries, e.g. MFC, boost, GTK--, etc. But they should be covered in books different from the book meant for learning C++. Any comments on this? -- Paddu 07:12, 20 Sep 2004 (UTC)

 * I do agree that things must have a structure and a logical one if possible, using as many references to any C++ oriented content information would be only contributing to the goal (readers <= contributors), if there is any part that would could be made into a separate work they should be moved, I've done that with OOP part (as a test, but it pretty empty, if someone dislikes it they can change it), more important would be saving any work already done under the same license like *How To Think Like A Computer Scientist Learning with C++ by Allen B. Downey and other free work under a compatible license before they are lost and mailing other free content authors so the information remains free for all...

 * OOP is central to C++ and would have to be dealt with in a book on C++, but a book on C++ should not deal with MFC, etc. as they are not required to learn C++. There could/should be (a) separate book(s) on OOP; they'd probably deal with not only C++ but other OO languages as well. IMHO C++ is one subject for a book, MFC is another, general OO is yet another. Each would ideally be dealt with a separate wikibook.

 * Agree... but other libraries should be referred to... I personably don’t have a problem with some examples on the differences of approaches etc... but yes I agree that C++ and STL should be the main subject... -- Panic

 * Trying to pour in material from 3 subjects into one book would IMHO not lure contributors but would turn them away, since they'd think it's an unorganised set of notes rather than a textbook. -- Paddu 20:45, 17 Oct 2004 (UTC)

 * Disagree... as we are working on virtual space and not restricted to paper or other media a dif. page or chapter for MFC (until enough data to form a dif. work) is more logical than a different empty book for it... people would participate more if given a vast range of options to build upon, this is one of the reasons that a single "huge" page would work better, given the restrictions of wiki. (more on that below) -- Panic

My replies removed
My replies to many of the above threads have been wrongfully removed. -- Paddu 13:57, 18 Nov 2004 (UTC)

 * These include threads that User:Panic2k4 calls dead, and includes threads about User:Panic2k4's behaviour in Talk:Programming:C plus plus. My replies can still be found in Talk:Programming:C plus plus and Talk:Programming:C plus plus/single page. Some stuff I wrote to him are also at User talk:Panic2k4. -- Paddu 14:09, 18 Nov 2004 (UTC)

Rearranged discussion "area"
The above three sections enclosed within horizontal rules is User:Panic2k4's interpretation of the previous discussion. I'm opposed to his/her refactoring at least because:
 * 1) I was misquoted at least once — Panic's interpretation is that I asked someone to be nice, though I'd just said that doing something would be nice.

 * Geezz Paddu just correct them, people do make errors, English is not my natural language, and try to not spend my time taking things that seriously... (probably the mess this was, if anyone changes your lines you wouldn't notice it :)

 * 1) The interpretation makes at least one false claim — It's false that I didn't implement the highlighting I proposed. All the pages that I edited (except those in which I added navigation links) follow the convention I proposed.

 * Didn't see any and I didn't contribute to any modules only to "the book" (modules have seperate discussion "boxes" (hint) ) was this miss plassed here ?

 * 1) It calls proposals without any opposition as dead.

I didn't check for more errors as I don't have much time. Besides, even then I wouldn't be correcting them as IMHO they form a comment Panic has posted and I believe I shouldn't edit his/her comment. Presenting the original is an easy way to make clear what each person said.

 * Humm the originals are still there only commented out so to reduce the mess (I reverted it again), and missquoted are is not the same as edited, it's easier to prioritize stuff as I have arranged it, please try to give it a chance, as for the dead proposals as adopted, heck if a house is pink I say it's pink I dind't select the color...

 * Please state what proposals you wish still to debate (if you still consider that for example the highlights are open, you should consider helping on heerr highlighting stuff :) lol at this point in time I don't think it's a great idea if that would have been settled before no time would be have to be lost on this (humm btw for example "In My First C++ ..." I didn't seem to notice any nor in the other modules I've seen...)
 * It can be done when all sections are filled and a full revision starts, but now it's a bit late on the game

And BTW Panic, Dysprosia is a "she" not a "he". -- Paddu 13:11, 8 Nov 2004 (UTC)

 * Lol I'll correct that one :)--Panic 02:10, 9 Nov 2004 (UTC)

moved from my talk page as this is relevant to this topic... (there = here)

Stop "vandalising" Talk:Programming:C plus plus with your own ideas

What you said there: "If you are an active contributor / engaged on any of the proposals you are free to edit this section" is not the wiki way. Everyone is free to edit any section. Stop adding this kind of nonsense. Thanks! -- Paddu 05:16, 9 Nov 2004 (UTC)

I don't think I'm vandalising anything My First Contribution-as it is now... (you can always ask for moderation if you have your mind set into it). I'm just asking for your opinion on some proposals (and some were already "adopted" by contributors or just ignored) and take your point or of any other "major" contributor into account, the ideia is to make contributors in general happy... geezz

As for the warped ideia you have on the humm wiki way... wiki pages may have passwords and other "protections", I didn't and can't prevent any non humm "major" contributor from editing the section, it's just a request and I do think it's a logical one so to keep some order on it... geeezz you are to litral for me, first you wrongly accused me of vandalizing and them make me spend this time debating a self evident point don't be so single minded (almost anal) on the subjects, take the time to think on what/how you did/react and how I could have gone about it, I think I've been contributing so don't call me a vandal ... txs

PS: I'm a "he" :) --Panic 01:39, 10 Nov 2004 (UTC)

Having all material in a book in a single page
Can't the reference tables be moved to the main page into the related part of the doc and use anchors to refer to them ?

This does have something to have with previous discussions about removing part of the work to other pages but as this is not an independent topic (it relates to misc. parts of the main topic) -- Panic

 * It's infeasible to have an entire book in a single wiki page. It may be OK for some people to read that (there do exist a lot of e-books available in "one-big HTML" format), but editing such a page would be difficult. Yeah, we have section editing and all that, but still it is a pain. After submiting it, you've to wait for the whole book to load again. Which reminds me... What about people trying to learn about just one language feature. Do you want them to wait for the entire book to load? That's why pages in the context of wikibooks are called "modules", not "books". Depending on the size of the book, each "module" may be a separate chapter or section or sub-section or anything.

 * If you want all chapters in one big HTML, it should be possible to create a page like this:

 * but the navigational links I've added to some of the chapters won't point within the page but to the page for individual chapters. But that should be the least of our problems. The real problem is that the servers would slow down. -- Paddu 20:17, 18 Oct 2004 (UTC)

 * A single page from my point of view is the best trade off, for the user and the writer, as stated above any contributor would find more easily were he can be most useful and avoid repeating already contributed information, as a reader I do really hate wiki because of the limitations it gives to export to a non wiki env. like to get a copy of the work as a PDF. -- Panic

 * What was dicussed before was not trying to include all C++-related topics into this book but to deal with only one topic — C++. The other topics must be in different books. Of course there should be a link to those books here and a link to this one in those, but each chapter in those other books should not be mentioned in the table of contents of this book. -- Paddu

 * Agree, but the "topics" can be easily moved later if found to be extensible enough to be a stand alone book, moving empty topics will only fragment the user/contributor base... -- Panic

and there isn't a wiki "extractor" (does it?) that would facilitate getting a copy of all the work I do think that it should be avoided and only use external pages to start independent "books" (works with private topics), I have also tried to find an offline editor (that isn't a Emacs or Unix solution...), does anyone know about one ? -- Panic

 * Probably you are looking for Special:Export?

 * Nope, something like a OpenOffice plugin something on those lines... I dont want to install a server and wiki on my comp to be able to edit offline :)... -- Panic

... and still on forking the work into multiple books. First lets have a working "book" and then we'll trim it out, using s streamline structure without references to multiple subpages will help to desegregate other topics, hec... even STL, that is part of the standard should have a separated book only for it, but lets try to just keep it on topic and with a simple and logic structure, then we can see if it is worth to fork it for the moment all content (on topic) will help to bring contributions ... -- Panic

 * It's difficult to have a working "book" without structure, with just random stuff about every C++-related topic thrown about. Talking of forks, splitting a program into a lot many source files is not equivalent to creating forks. Forks in wikibooks would be having two different wikibooks on the same subject. Is there any other book on C++ here? -- Paddu 20:45, 17 Oct 2004 (UTC)

 * Ok, I should have used thread of subject and not fork (topic would also be wrong as a topic can be linked to a external subject), but I've seen your changes to the "Guide to Writers" but is there a way to list all "modules" on a single page so anyone can get a easy copy of the book (for printing or just to avoid repeating info or just to link to the relevant areas ? ) if not dividing the work into multiple modules is not a good idea it will only hide information and segment the readers reducing the writers as they will only see blocks of the work and probably if a users comes to the book as a reader the probability that he will contribute to a section he wants to read about is less that to a part he already knows, in modules only people that already have some degree of knowledge on the subject would contribute and I really doubt that this would result on more work being done, to do spell checking I don't need to know C++ (for example)... -- Panic

 * The intent is to make the readers aware that they can edit any page, not just what they are reading. With Wikipedia, the average newcomer is tempted to read more & more pages following various internal links, and hence can easily arrive at something known and start contributing to that article. In wikibooks, the no. of links is low and this may be a problem. But IMHO the reader can easily guess that there is more than one module to a book and search for other modules in a book.

 * As far as coverage of new subjects is concerned, the idea probably was to list the books expected to be written in a bookshelf, and a visitor to the bookshelf can easily find what subjects he could contribute to. This approach would not work if bookshelves are (e.g.) given lower Google ranking than to a particular book. In such a case most visitors would only visit that book and might not be able to guess that they are free to contribute to any of the other books listed in the bookshelf.

 * I can't think of a solution to the problem other than what I've mentioned, namely have a huge page that instantiates each page of the wikibook as a template (did you know you could insert the contents of any page into any other page using templates?). It is possible to also have an edit link to individual pages, so any reader could be lured into adding content for any of the modules. But the real problem is that having large pages both irritates the reader and stresses the servers. I think we could get a better solution if we ask this in the Staff lounge, which has a greater visibility.

 * BTW, please sign your comments with a  ~ . It's difficult to find which comments are by whom. I'm having a tough time taking our discussion to the Staff lounge. -- Paddu 14:42, 20 Oct 2004 (UTC)

 * Done -- Panic

 * As it turned out, all the anonymous comments were by the same person, and I didn't have time to take this discussion to the lounge. Will do so today. BTW our conversation is quite large and I've decided to give a brief description and link to this page instead of copying the entire conversation there. -- Paddu 07:23, 21 Oct 2004 (UTC)

 * How about an infobox in each module of a book, which includes some text like:

 * -- Paddu

 * That is a great idea, but not to empty books (that is really very frustrating), btw keep those wiki wiki codes coming it's helping my learning curve :) -- Panic

 * That way you may not learn much. Read the help pages here and in meta to learn more. I believe you can get a better idea about Mediawiki and the way we work in Wikimedia projects by perusing the pages in Wikipedia in the Wikipedia: namespace. Not all those pages have been ported to Wikibooks.

 * Since you seem to have arrived at Wikibooks without first having been to the 'pedia (please confirm this), you might be able to give a better insight into how wikibooks must be different from wikipedia. IMHO red links are not frustrating, but rather an invitation to contribute. A wikibooks reader oblivious of wikipedia might think differently. BTW you could change the way broken links show up by changing your Preferences. -- Paddu 07:23, 21 Oct 2004 (UTC)

 * Er... That's not an infobox, that's more of a navigational template. -- Paddu 07:23, 21 Oct 2004 (UTC)

Here's my 2c. A book has a lot of largish chapters - let's emulate this. Having everything on one page disadvantages the reader in having things referenced, it's easy to bookmark a module page to a certain section, but it's not if everything's on one page, since one has to look through that to find something. Not to mention it's more difficult on dialup connections. It also allows one to structure the material and have different people working on different things without loss of apparent continuity in the text. Speaking of forks, I am strongly against this. If we have any chance of making something decent here we need to pool our resources and create something unified. Dysprosia 21:32, 2 Nov 2004 (UTC)

Here is a possible solution: Either way, the text needs to be split up into different sections. How about splitting up this page into chapters and having more lecture style material more suited for a Wikiversity type course which can be a bit more freeform as Panic seems to be more comfortable with? (Though you will need to break it up into a set of lectures regardless, and most importantly keep it structured).

HTH Dysprosia 10:30, 9 Nov 2004 (UTC)

Lol, sorry about the "he" Dysprosia you are part of a minority so I did take it for granted, I've been corrected and switched any wrong gender references :) (Hope it alright now...)

I'll elaborate it more here and them move relevant parts to the "proposals section", I understand that you are referring to modules (separated pages) as chapters and sections... as for the order or structure I do think it's taking shape but stuff needs from time to time to be moved around just to make sense (we can't talk about classes before going into what OOP brings to C++ etc...), as for the fixed idea Paddu has with modules, I'm not against it nor mind set into a huge page but to make it a logical work. If we have multiple pages and with it discussion pages etc... it makes it a very difficult job on making a good work just take a look on the wiki bib. (on the previous modules) they go all over the place, I think that the problem is that people tend to look at this wiki book as an extension of wikipedia and this is separated work that must stand by itself if we fragment it it stops being a book. I'm taking the road set by P3 "move chapters to modules as they were finished" (they aren't) and see if the solution Paddu indicated will work (transclusion, I think its a great option), still waiting for him to give me a working example but that would solve the problem of extracting all content to let's say a .TXT file and make it easier to coordinate edits (stop the duplication) and keep the ease of editing (if you go into the history you can easily see that people edit and contribute to different "chapters" that would be made impossible if using modules at this stage... ufff I think it's all, combined with I and others have said before, will this close the subject ?!? (until we have a complete "chapter") --Panic 02:05, 10 Nov 2004 (UTC)

Where is the reference to the STL ?
The book doesn't have any reference tothe STL. Since it is a part of the C++ standards, is there a plan to create a section on it? --Mecanismo 13:31, 21 August 2005 (UTC)

Altering how talk pages are structured
As there seems to be no discussion about the cover image any more and seems to have been finished, I think its discussion should be removed. If for some reason someone disagrees with this I suggest, merging it with an archieve of previous proposals. I also think the link to book editing should be removed as well replaced with a link to help for editors and/or help for wikibook users. I also think the parts on merging contents and orphaned pages can be elemented since any merging and orphans should of been taken care of by now and the end of the main page lists anything that people think should be merged or added and the discussion on book contents seems to be the place to discussion it. I think copying and/or moving conventions and future contents that have been discussed and agreed to should be placed on the main talk page for quick access with a notice to not remove whats listed here, but to debate them if people disagree in the aproperate discussion.

Something like this to replace the main talk page:

== See Also ==
 * Before contributing to this book, read Wikibook Policies and Guidelines.
 * For information on editting wikis see help for editors and help for wikibook users.
 * See Archives for older talk pages.

Please try to limit discussions to the related discussion page:
 * See Conventions for debates over conventions used in this book.
 * See Contents for discussion and planning of books contents.
 * See the talk/discussion page of the related module for discussions and debates limited to that module.

==Conventions used in this book== ==Book Focus and Direction==

with maybe the see also part placed on its own page so that it can be included on any talk page for this wikibook to elemenate duplication. --darklama 18:42, 30 September 2006 (UTC)

Please move this to the proper section... And I disagree.--Panic 04:48, 1 October 2006 (UTC)

Is there anything you disagree with specifically? The choice of what cover image to use seems like a proposal that was finished. The help for editors seems like it would answer any questions related to editting making the book edit part unnessary. it also looks like its dead and could potially be duplicate contents. --darklama 17:21, 1 October 2006 (UTC)

 * Before contributing to this book, read Wikibook Policies and Guidelines.

This is already on the book itself and sending it in that "In your face" form, could just scare contributors.

Probably including the link in every existing talk page to the policies and guidelines would be helpful l is there a template we can implement on contributors discussion areas in genera (small fonts) and not in a red background would be great. (or on the side of the page, as V2 of the book something on those lines...) --Panic 03:41, 12 October 2006 (UTC)

Your right, it is be a bit "in your face". If you have better wording suggestion, go for it. The idea is to cut down on needing to point out specific guidelines or policies that are better understood by reading them. For example "avoid copyright paranoia" is better understood by reading the policies and guidelines. Then again it may not be necessary at all since the "help for wikibook users" includes a link already to policy and guidelines. I don't see a red background, its all white here, must be something on your end. I don't know if a template for it exists or not yet. The closes I know of off hand is which gives:

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally. --darklama 05:58, 12 October 2006 (UTC)

Again you misunderstood me, what I said was, we could probably use a banner (or something like V2 toc) and place those links and other info in all talk pages but not with a red background or big fonts. --Panic 16:14, 12 October 2006 (UTC)

I don't think I misunderstood you this time. I was answering your question. There doesn't seem to be any existing template, except maybe, we would need to create one to use on all talk pages. It doesn't have to be a red background or big fonts, I was pointing out that what I used above doesn't use a red background, but a white background, in case thats what you see on your end. --darklama 19:08, 12 October 2006 (UTC)

Altering the TODO box logic
I Propose altering the way the TODO boxes are used at the moment, the idea would be adding a TODO template on the C++ Programming namespace with a redirect to the existing root: template, this would provide a easy what on checking where TODO boxes are on the book and add the what links here link to the Content discussion. --Panic 05:36, 30 October 2006 (UTC)

The TODO template could probably be changed to categorize pages in something like Bookname/Todo, but why is it needed? --darklama 03:14, 31 October 2006 (UTC)

A new template (reworked that is) will not be needed a simple redirect from a local (in the book namespace) to the general one would provide a whatlinksHere list of were all the TODO boxes are, so to facilitate contributions and prevent that people that add them forget or get confused by moves or text changes...--Panic 05:09, 31 October 2006 (UTC)

Sounds to me like the category would be the better option, because the TODO template may be used by more then one book and people may forget to create a redirect. The category would ensure its always available for any book that has things to do that makes use of the TODO template. --darklama 12:01, 31 October 2006 (UTC)

Try it then lets seem how it feels, I do think that the TODO box in itself doesn't need a link to the category, that could be done in per book bases in the talk section.--Panic 15:37, 31 October 2006 (UTC) PS: This discussion should be moved to the template page, so if anyone objects sees what our intentions are.

Making the template not appear in the category isn't a problem, thats easly done. --darklama 16:14, 31 October 2006 (UTC)

Humm ok but I don't see another way of doing what I said having a Special:Whatlinkshere/Template:TODO with only the C++ Programming Pages.--Panic 17:39, 31 October 2006 (UTC)

Yup I remember now why we didn't use the category on the TODO box, the box is intended to help editors/contributors not to crowd the navigational aids, even if in part it would help the page listing isn't specific to a book.--Panic 20:23, 1 November 2006 (UTC) PS: I will be moving this discussion to the TODO box talk in a few days (3 max)

So are you saying now you don't want it?! I had went ahead an added a category for it already, since pages (including templates) should be categorized. Maybe it can be somewhat helpful anyways. See Category:TODO. --darklama 23:09, 1 November 2006 (UTC)

-

I'm saying that I don't like it, there is no need to have an extra link in each page (on set of pages) that use the TODO, a quick way to see what book pages used it would suffice, as it is it only makes like a bit more confused to users, but I can live with it.--Panic 17:11, 20 November 2006 (UTC)

Tables, Figures and More
'''From prev. debates...''' I like the green boxes, and i would re-use them until someone can come up with a better solution.

Here is an example:

I would suggest:
 * TODO for TODO notes (since that's already there)
 * Programming:C_plus_plus/Pitfall for common errors
 * Programming:C_plus_plus/Portability for portability tips
 * Programming:C_plus_plus/Practice for good practice

with right now the only difference being what is written there.

--Max 01:26, 18 September 2005 (UTC)

Have a box template that can be used for tables, figures, examples and other commonly tools used in technical books. For now use a fix style. In the future if we can get it approved, allow for customize style by way of class or id name thats available in all monobook themes.

Usage would be one of:

which would be rendered as:

I also agree that we need to use several different types of notes with different styles to distinguish level of importance of the information being given. --darklama 20:34, 11 October 2006 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
User talk:MrItty

Sorry
I'm really sorry about that, I wanted to try to put some filehandle stuff a little later but I ended up forgetting to copy the page. Won't happen again.

--Joelnackman 03:27, 18 Nov 2004 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called MrItty. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name MrItty~enwikibooks that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:31, 17 March 2015 (UTC)

title: User talk:MrItty


text:
User talk:66.139.198.115

The pages that you created (located at WWLS - How To Find A Class and WWLS - The Wrong Way To Learn Spanish) have been flagged as candidates for speedy deletion. If you were trying to perform a test, it worked. However, for the future, it would be appreciated if you would perform all tests at Sandbox. Please do not continue to create test pages outside of the sandbox, or it may be percieved as vandalism. If you have any questions, feel free to leave me a note on my talk page. -[[User:Frazzydee|Frazzydee|✍]] 04:13, 18 Nov 2004 (UTC)

title: User talk:66.139.198.115


text:
Cookbook:Béchamel Sauce

| Sauces

Béchamel is one of the five "mother sauces" in French cuisine. As a basic white sauce, it can be used as the base of many other sauces.

Recipes

 * Béchamel Sauce (Basic)
 * Béchamel Sauce (Beeton)
 * Béchamel Sauce (Louisiannaise)

bpy:%E0%A6%A5%E0%A6%96%E0%A7%A5%E0%A6%B2:B%C3%A9chamel sauce bxr:Куисиска:Сос бешамелска Livre de cuisine/Sauce béchamel ta:Cookbook:பெஸமஎல Sauce te:Cookbook:B%C3%A9chamel sauce

title: Cookbook:Béchamel Sauce


text:
Music Theory/Classical

Classical music was a musical style that was popular in Europe in the 18th century. By convention, it begins in 1750, with the death of Johann Sebastian Bach, although "classical" music appeared earlier. The Classical era marked a move away from the intense emotionalism of the Baroque period towards a highly structured, stylistic manner, and was the flowering period of the sonata-allegro form (a three-part structure, with the first movement allegro, a slower second movement, and a faster--often allegro-- third movement). Later Classical-era symphonies often added a minuet-trio section as the third movement, and the faster third movement became the symphonic fourth movement. Popular composers include Haydn and Mozart.

Ludwig van Beethoven is sometimes considered to be a classical composer, but is a special case, as his early music was classical, and his later music romantic. In fact, his Pathetique sonata for piano is sometimes thought of as the piece that ushered in the romantic era.

Notable Features
Music from the Classical Era took on many defining features.

Composers

 * J.S. Bach (1714-1788)
 * J. Haydn (1732-1809)
 * W.A. Mozart (1756-1791)
 * L.V. Beethoven (1770-1827)

title: Music Theory/Classical


text:
Ada Programming/Libraries/Database/GWindows

Library functions
David Botton created GNATCOM project to help Ada interoperate with Windows COM Object. The GWindows project is based on GNATCOM. It is used to create Windows Graphics User Interface.

The database package is a subset of the GWindows project. It is very easy and useful.

Library links

 * Author          : David Botton
 * Homepage        : http://www.gnavi.org/index.php?Command=Class&ClassID=GWindowsWin32&Title=GWindows
 * Project Info    : GWindows
 * Library Document : http://www.gnavi.org/gwindows/ref/gwindows-databases.html
 * CVS Archive     : - missing -
 * Download        : http://www.gnavi.org

Sample code
Gnatcom.Initialize; Gnatcom.Types; Gnatcom.Variant; Gwindows.Databases;  Gwindows.Databases; ;         ;  ;  ;  ;  ;  Test Connection : Database_Type; Recordset : Recordset_Type; customer  : Gnatcom.Types.Variant; Gnatcom.Initialize.Initialize_Com; Open (Connection,        "DSN=Northwind","your ID","your password"); Open (Recordset,        Connection,         "SELECT * from Orders",         Dynamic,         Optimistic); Eof (Recordset) customer := Field_Value(Recordset,"customerId"); Process (customer); Move_Next (Recordset); ;     Gwindows.Databases.Close(Recordset); Test;

Wikibook

 * Ada Programming
 * Ada Programming/Libraries
 * Ada Programming/Libraries/Database

Ada Reference Manual
—none apply—

|GWindows


text:
Talk:Java Swings/Overview

Reorganized
I tried to reorganize the Swing topic so that it was more on par with the others -- ie, navigation boxes at the top of the pages, discrete pages instead of giant ones; hopefully I did alright. The content needs some serious work as well, but hopefully this was a step in the right direction :-)

title: Talk:Java Swings/Overview


text:
User talk:James Dennett

Some kind soul left me these references...

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.

C++ Programming
I see you've started contributing to this book again. I just wish to say thanks for your corrections to errors and am glade to see you've decided to start contributing to this book again and hope you will continue to do so. --dark lama  00:29, 6 December 2006 (UTC)

Thanks for the encouragement; I don't know how much time I'll have to contribute. It rather depends on how worthwhile (or, to look at it differently, how futile) it seems. Last time I tried to work on the predecessor of the C++ wikibook, I found that mistakes were being added faster than they could be corrected, and re-added after being corrected; there were some contributors with more time than (correct) knowledge. (On the other hand: if I do get something wrong, please fix it, and ideally tell me.  I like it when I learn I was wrong about something, even more than I hate the fact that I was wrong in the first place.)  James Dennett 05:27, 6 December 2006 (UTC)

My hat's off to folk including User:SBJohnny and User:Swift who invest so much in trying to make wikibooks work. -- James Dennett 10 December 2006

It seems appropriate to acknowledge their work by giving this one more try; I've added some new material to the C++ Programming book, and saw somewhere that dark  lama  might have persuaded someone else to contribute. In a cooperative environment it shouldn't take a lot of people to make good progress.

Let's hope that past troubles can stay in the past. There are plenty of people here who care passionately about doing good work, and it can be tough to yield to others in the community, and to truly accept that once we write something on Wikibooks it is, in a very real sense, no longer our private property, but rather a common good.

(And if it doesn't work out, I hope I can disappear as quickly as I came in, leaving small ripples that soon die out!) -- James Dennett 00:24, 11 December 2006 (UTC)

Glad to see you decided not to leave after all. Completely true, all we can do is try to work together to make great books. --dark lama  01:32, 11 December 2006 (UTC)

I'm afraid it'll have to be other books that I help with after all; the C++ Programming situation is still not viable, for me at least, in spite of the efforts of various admins and others. I wish those who continue the best of luck; as I've noted elsewhere, the release of the next C++ standard (hopefully in 2009) might be a good time for me to try again, perhaps with a separate book if The Powers That Be find that appropriate. -- James Dennett 23:34, 25 April 2007 (UTC)

C++ Programming/Classes/Polymorphism
I'm curious about your motivation behind making a distinction behind dynamic and static polymorphism, as far as I know, C++ doesn't make any distinction.

I'd also be curious to know what you think about combining the bits within Abstract Classes and Pure Abstract Classes into the chapter on Inheritance. C++ AFAIK, doesn't really make a distinction between classes and other sorts of classes, but it does related to inheritance in the sense that an abstract class is typically used as a base or parent class for a derived or child class. I'm not entirely sure what to do about the "nice class" information. I was thinking maybe it makes more sense in the general Classes chapter, but then the Classes chapter seems to be missing information on operator overloading and probably shouldn't be introduced until operator overloading has, so I've though maybe it makes since in the operator overloading chapter instead. --dark lama  03:03, 11 December 2006 (UTC)

The distinction between static and dynamic polymorphism is applicable to C++; alternative terms are compile-time and run-time polymorphism. Various kinds of polymorphism are supported in C++; templates provide one or two kinds of static polymorphism, overloading provides a form of static polymorphism, and runtime/dynamic polymorphism (which is commonly, if loosely, often just called "polymorphism") is of course based on the virtual dispatch mechanism. Having thought about this a little though, I think this might be best covered as a small diversion for context, and then the book could state that it will use the term polymorphism only in the context of dynamic/runtime polymorphism, specifically the features supported by virtual functions in C++. Presentation could be too awkward if the term "polymorphism" is qualified every time it is used, and there is occasion to speak of polymorphic classes (such as if we get around to saying what typeid does in detail).

It would seem to me that it does make sense to include discussion of abstract classes with the material on inheritance.

Off the top of my head, it might be good to cover classes in a number of phases; first introduce concrete classes (without any operator overloading), then introduce inheritance, then virtual functions, and then operator overloading. Alternatively operator overloading could be covered before inheritance; I can imagine a good case can be made for either order. There might even be room for another "advanced" chapter on classes to cover things like class-specific operator new/operator delete, techniques to restrict inheritance (and why they're a bad idea), the "pimpl" idiom, and more.

The term "polymorphism" is indeed not used much (if at all) in the C++ standard, but then the standard isn't trying to be a tutorial. It might make sense for us to link to Wikipedia material on different types of polymorphism rather than trying to rewrite it all here -- it's a CS notion much broader than C++, and I figure we might want to give only a brief overview of the general idea and focus on the C++ aspects.

No idea on "nice classes". I'd have to take a look. Might do that sometime. -- James Dennett 06:08, 11 December 2006 (UTC)

Generally I understand polymorphism in C++ to refer to classes such that transparently one class may be treated as another through the use of virtual functions and multiple inheritance. I think it may be confusing to refer to function overloading and the use of templates as forms of polymorphism. I admit I'm of the opinion that a book on C++ should compliment the C++ standard. I don't think its necessary to cover the broader CS notion to explain polymorphism as it applies to C++. I agree that a brief overview of the general concept makes sense, but I think it should focus on what it means in terms of its usage in C++.

There's a difference here with regard to using links from how it is on Wikipedia. Books are for the most part suppose to be self contained so that any information needed to learn the subject is available in the book, rather then relying on outside information to provide it. So while linking to Wikipedia material sounds like an easy solution, I don't think it makes sense.

A nice class in summary is basically one with copy constructors and provides operators with the expected operations of that operator and does so safely. For example overloading = is expected to involve assignment of one class instant to another and check to make sure that both aren't the same class when doing so which if failed to do can lead to memory leaks if assignment involves allocating memory with new. --dark lama  07:20, 11 December 2006 (UTC)

I think our viewpoints on the use of the term "polymorphism" here aren't far apart. We shouldn't get too bogged down in generalities; it would be nice to at least mention that there *are* more general notions that apply. I still feel that a link to Wikipedia would be helpful as a supplement, but I'm not all that concerned either way.

The only thing that seems to set a "nice" class apart from other working classes are that it allows copying, and it allows comparisons for (in-)equality. Fair enough. I've done some minor fixes in that section recently (as it said that the default copy operations are binary, which seems untrue).

Time for me to sleep; happy editing. The new front page is great, incidentally.

-- James

I think the broader meaning of polymorphism could be discussed earlier in the book where general programming concepts are introduced with as you said a note regarding thhe use of polymorphism as it applies to C++. The entire introduction chapter is in need of a rewrite, and thats the main part of this book that I'm going to be concentrating on for now. If you want to pitch in I'm all for it. To get an idea of what I have in mind you might wish to read (if you haven't already) the discussion that took place in regarding to doing just this. I've already begun the first steps twards this aim in C++ Programming/Programming Basics if you want to take a look.

I agree with your ordering for teaching classes. I think this book could use a chapter on advance classes as well. Both to cover mixing everything thats been taught previous about classes, and to introduce things like overloading the new and delete operator. Might even be the best place to discuss "nice" classes and other good tips for using classes effectively. So maybe all that needs to be done for the nice class page is to change the name and expand its focus. --dark lama  17:44, 11 December 2006 (UTC)

Essences
I noticed you changed the TOC2 Print version to say Essentials instead of Essences. Any reason for that?

Essences (n): The intrinsic or indispensable properties that serve to characterize or identify something.

Essentials (adj): Constituting or being part of the essence of something; inherent. --dark lama  22:39, 13 December 2006 (UTC)

 * Sure, but if you have a strong preference, change it back; it seems an odd place to use the term "essences". It's a question of the "feel" of a word, if I can be vague (and it seems that I can, for better or worse).  "Essences" struck me as seeming non-idiomatic in this context, something that would most likely be written by a non-native speaker.  Not that you seem to be one (nor is there anything amiss about the majority of the world's population who don't speak English as their first language, come to that).  I guess in the end I just feel it's more readable to most people as "Essentials".  If you'd like to challenge people to "think differently" then "Essences" will quite possibly do so.  (Or maybe this is a US/UK English thing; I'm British, though living in the US.  I've noticed that some fraction of things that strike me as poor English are just poor English by British conventions, and are idiomatic elsewhere.  Similarly the other way around.)  Incidentally, I'm assuming you're watching this page, having left notes here... -- James Dennett 23:26, 13 December 2006 (UTC)

 * I am a native US English speaker (but my spelling and grammer tends to end up bad anyways, without comparing color to colour), however I was actually going for a word similar in meaning to essential, so I ended up going with essences in order to avoid using the word essentials twice. I think its going to be a mute point anyways, as I was thinking of combing the two sections together and renaming it to maybe "The Essentials", soon anyways. I was just wondering if there was more to it, like in preperation for futher changes, so as not to step on your toes if you were in the middle of doing something. I'm somewhat watching this page. I don't have it on my watchlist, but I am checking it maybe once or twice a day, if I see any activity from you. I don't have it in my watchlist, because it seemed to me, like you don't really look at this page much yourself. --dark [[Image:Yin yang.svg|12px]] lama 00:43, 14 December 2006 (UTC)

 * Nice of you to include "grammer", "mute" (for "moot"), "preperation" ;-) but luckily one thing Wikipedia and Wikibooks are good at is having people who know things write them down, and then wikignomes can come along and fix the trivial things. (Yup, I'm some kind of spelling/grammar freak.)  As for me watching this page; when I'm active on Wikibooks, I'll watch it.  "Free" time comes and goes.  One of my writing flaws, getting back to the subject at hand, is a tendency to repeat words when it might be better to use a synonym or to rephrase.  So maybe one of us should revert my change.  It's a pretty minor issue, sure, but I suggest you just do whatever you feel is best; I'm not going to "fight" about such a thing, now that I know it was a deliberate choice.  Today I've been working mostly on the memory management section.  It's maybe 35% done, to give a ridiculously over-precise and under-accurate estimate. -- James Dennett 04:21, 14 December 2006 (UTC)

C++ functions
Now that you mentioned malloc/free, I'd like to mention that I was of the opinion that we should be calling these std::malloc</tt>, <tt>std::free</tt> in the text, and we should not be using the <tt>using namespace</tt> construct, so the readers will get a better grasp of the correct way to use namespaces earlier in the book (that would just be a few simple "find-&-replace"s but could go a long way in ensuring we teach namespaces correctly). -- Paddu 20:44, 15 December 2006 (UTC)

 * I'd like to go the way, certainly (indeed, I recently removed the "using namespace std;" directives from a moderately sized commercial project). You might notice that examples I've added use std:: qualifications.  (And in my own code I'm sometimes, just sometimes, crazy enough to write ::std for the namespace name!) I'll mention the idea on the Talk:C++ Programming page and if nobody objects I'll do some of the "busy work" soon. -- James Dennett 20:49, 15 December 2006 (UTC)

 * Sounds good to me. I think "using namespace std;" teaches bad habits. I think we even should explain why its a bad idea to make use of it in the chapter on Namespaces (eg because its clobbers/pollutes the namespace). --dark [[Image:Yin yang.svg|12px]] lama 00:43, 16 December 2006 (UTC)

 * I've started to change bits and pieces of the code to this style, as I see them. Probably there are better ways.  Tips are welcomed. -- James Dennett 03:26, 17 December 2006 (UTC)

casting without type conversions
Txs for the input, now I know a little more. --Panic 05:24, 29 December 2006 (UTC)

Arbitration Decision
I have stepped in to deliver a decision for the arbitration which I believe has gone on long enough. Please see my decision page and write on my talk page if you have a response. Thanks. -within focus 23:03, 31 January 2007 (UTC)

 * I see no need for further comment. Enough has been said.  Thank you for your contributions. -- James Dennett 23:09, 31 January 2007 (UTC)

Where's this all going?
Now the "Dispute Resolution" page has gone, and redirects to Panic's talk page? That seems odd to me. Also, large fractions of the text that were there are no longer present (they are, of course, in the histories for those who go and look). Seems that we're going backwards again. We need this discussion to happen in one place, that won't move around, with some clearly defined goals and a visible, updated current status being prominent. I do appreciate your willingness to help -- just trying to avoid repeating history (as recent history in this case has not been good for the community). -- James Dennett 04:17, 28 February 2007 (UTC)
 * I was asked to 'perhaps' move the discussion to Panic2k4's talk page so he can edit even when blocked. Since he removed the page I have restored it on the original location. -- Cat out 15:51, 28 February 2007 (UTC)

I was going to use TOC2...
But I suppose I will take a look at TOC1 and see what would be the best course of action. --Remi 21:02, 2 March 2007 (UTC)

 * I rather like TOC2 myself! -- James Dennett 22:03, 2 March 2007 (UTC)

Passing array through reference
Now I know that it is possible. Thanks for your response. I didn't note that when I studied template. -- Ron Lau 07:15, 28 March 2007 (UTC)

Re:C++/TOC
Hello James. I certainly feel your frustration on the matter, sometimes it seems that people would rather argue then come to any sort of compromise. When this happens, I agree that it's usually best to find a new project to work on. There are certainly plenty of books available, especially programming language books. I am even planning to create a few new books, once I have the time to do it. What other kinds of things are you interested in? what other programming languages? I've got a book right now on Microprocessor Design that i'm putting some serious effort into, and there are several books that i've worked on in the Assembly Language realm, if any of that is your cup of tea. Also, I know that the C Programming book is in lousy shape (comparatively) and could use some helping hands.

I've thrown around the idea of creating two C++ books before, but that idea met with the usual resistance, as you can imagine. The people who don't want a second C++ book are generally the same people who stay far away from the problems in the first book, however. It's never ending, and you are a saint for putting up with it all for this long. --Whiteknight (talk) (projects) 00:46, 26 April 2007 (UTC)

 * I don't think canonization is likely in the near future... ;)

 * I've worked fairly extensively with only a couple of assemblers (ARM, 6502), moderately with a couple (POWER/PowerPC and MIPS), and less with others. x86 is largely a mystery to me.  I'm competent to contribute usefully on C and various other languages in that family, or on Perl, and can brush up on my Smalltalk, Haskell, Python, Modula-2, Ada, and some others easily enough.  I'll have a look at the C book in a little more details (I've briefly glanced at it in the past) to get a feel for it and its community, and see if there's anything useful I can do there; thanks for the pointers. -- James Dennett 03:37, 26 April 2007 (UTC)

 * I've decided to start a new C++ book, in response to the problems with the existing one, since it is very unlikely to ever be resolved. The book is directed at readers who have no experience in programming, but who have enough knowledge about using the operating environment of their choice, to be able to install and use a compiler without needing to explain it to them in this book. This book is only going to cover standard C++ and common programming constructs that are portable, like creating linked lists, hash tables, trees, etc. Things like graphic libraries aren't going to be covered. I would also like to emphases throughout the book, good habits to have and things to watch out for or to avoid, in order to avoid making bad assumptions or writing non-portable code. Of course having fun writing about it is also a must. If your interested you can take a look at Understanding C++.
 * I haven't done much yet, the first chapter Introduction is trying to take the approach of discussing the basics of programming starting from general and ending in more detailed information with an emphases on a C++ perspective throughout. I'm hoping to give enough information for readers to have insight into what programming is all about and what this book is going to cover with links to chapters for more information. For myself I would prefer to have this more or less done first, before any other chapters are added, sine I think it will provide a good guide or roadmap of what to cover in each chapter. --dark lama  17:38, 2 May 2007 (UTC)
 * I've also started a style guideline for the book under Understanding C++/LMOS, to have some of my ideas for providing consistent style for the book written down. --dark lama  17:45, 2 May 2007 (UTC)

Understanding C++
I haven't really decided on a single approach yet. One approach that comes to mind though is mixing both high level and low level together. For example teaching both the basic variables types as well as the ones provided through the standard library in the same chapter, side by side. Making little distinction between high level and low level, since part of C++ is about abstraction. I'm also thinking about maybe covering pointers and references in the same chapter, and touching a little bit on new, delete, unions, structs and classes. Maybe in a later chapter covering new, delete, unions, structs and classes in more detail, and point out how some of the standard types that have been used so far like string are implemented using classes. I don't think the approach of separating based on a specific aspect of C++ is going to be used, like seems to be done in a lot of books. Hopefully better emphasizing the importance of learning all aspects of C++ and providing a better insight of both the whole picture and C++'s parts. --dark lama  21:20, 2 May 2007 (UTC)

 * Interesting. The key thing, to me, is to have a coherent way of getting the first few chapters to lead people to feel that they're achieving something.  Which suggests leaving new/delete and pointers until later, as they don't add new capabilities for a while, from a beginner's perspective.  But maybe we can work awhile on sketching some plausible outlines and documenting their rationales, so choose one we would wish to pursue.  And maybe we should discuss this on a more public place than our talk pages? ;) -- James Dennett 23:20, 2 May 2007 (UTC)

 * We can discuss this on Talk:Understanding C++ if you wish, it doesn't really mater to me, whichever you would prefer. I agree a plausible outline is needed, which is why I've been holding off adding the book to a bookshelf and making its existent more prominent. I figure a small group of people working out the details would be better for the book in the beginning then a large crowd, if such a crowd exists. I would love for readers to come away from every chapter feeling like they've achieved something. --dark lama  00:35, 3 May 2007 (UTC)

 * Agreed, I'll move my thoughts there. (And it's true that design-by-small-group works better than design-by-committee, aka design-by-large-crowd/mob.) -- James Dennett 05:07, 3 May 2007 (UTC)

 * Alright. I wasn't initially going to reply to this, because I thought you would go ahead and begin discussion there, but thought after 2 days maybe you were waiting on some sort of response from me first. --dark lama  18:25, 5 May 2007 (UTC)

 * No, just dealing with The Real World. I'll be back when time permits. -- James Dennett 22:58, 5 May 2007 (UTC)

It has been awhile and I have found myself stuck on how to move forward, I still don't have a decent outline/plan/notion for tackling the subject. I know every aspect of C++ that needs to be covered, but maybe my lack of teaching experience on the topic is blocking me from seeing any easy way to teach C++. I could use your creative inspiration on this. You have mentioned using a top/down model for teaching C++. When I think of a top/down or bottom/up model I always think of a pyramid. Is a pyramid the wrong way to think about this? What do you consider to be the rough/top of the pyramid? What do you consider to be the foundation/bottom of the pyramid? How would you teach C++ using a top/down model? Can you provide some examples? I think figuring that out has turned out to be the hardest part for me. Once I have a decent idea of how to teach C++ using a top/down model, the rest in theory should come easily. --dark lama  12:14, 9 March 2010 (UTC)

About manual memory management with new, delete etc.
James,

Could you clarify what you're basing the you finding in this section on?

"Modern C++ code tends to use new quite rarely, and delete very rarely."

Wouldn't code use delete precisely the same amount as new, in order to avoid memory leaks?

"Heap allocation times are much slower than allocations off the stack."

Isn't this completely negligent considering the real bottlenecks of modern software systems on modern hardware?

"However, there are still times when it's appropriate to do so"

I would say that there are many more times than you lead people to believe, where it makes no sense from a design standpoint to allocate your memory off the stack, as far as object lifetime or object size is concerned.

You also make no mention of stack size limitations.

--Shomron 09:21, 13 June 2007 (UTC)

 * When I note that delete is "used" less often than "new", I mean that it appears in fewer places in source code. Obviously it must be executed the same number of times.

 * In some kinds of work, heap allocation times may be negligible; in many fields, it's simply untrue that it doesn't matter. Busy servers, embedded systems, high-performance computing, games, and more, still need to care about performance, and dynamic allocation in tight loops can be a killer.  Much of the optimization work I've done in the past has come down to reducing the amount of dynamic allocation performed (in C++, Java, C and others).  The other big bottleneck I see these days tends to be excessive synchronization between threads, or poor use of parallelism in databases, but that's an aside.

 * Obviously we cannot cover every factor in choosing memory allocation patterns in a book that's intended to teach C++, otherwise we would end up teaching every related aspect of software engineering. My note about times when it's appropriate to use heap allocation is intended to acknowledge situations such as limited stack sizes (which are common in embedded or multi-threaded applications) and others, without getting into too much distracting depth.

 * Naturally, if you think you can make the text better... it's a wiki. Go ahead and contribute.  I'm no longer actively working on this book. -- James Dennett 22:18, 13 June 2007 (UTC)

Thankyou
I appreciate all the work you've done with this book. I have been reading through it (I'm just up to dynamic memory allocation), and I should of seen those mistakes that you fixed on the preprocessor section, but awell you fixed it =) Hope you can keep making this book better, rawrawrer (talk) 07:15, 23 April 2008 (UTC)

C++ Programming/TOC2
A VFD on the TOC2 page was initiated (27 July 2008) and then closed (30 July 2008) by Mike.lifeguard, if Wikibookians wish to express concerns about the speedy action they can use this page, You may restate your points (or post part of the your discussion there). --Panic (talk) 23:54, 30 July 2008 (UTC)

"garbage collected implementations of C++"
Is this what you intended ? I see it as a contradiction, to include a default garbage collection into the C++ language we would not have a C++ implementation, but something else, I also attempted to locate something that validated you change and came out empty were you referring to D ? I don't think the new wording and referring other languages on that section is an improvement to clarify the point. A better place to advance that issue, if we must, would be here C++ Programming/Programming Languages/Comparisons, see if you agree... --Panic (talk) 00:26, 2 January 2009 (UTC)

 * Yes, that's what I intended, and I was talking about C++ (certainly not D -- nothing against D, but it isn't very close to C++). Some implementations of C++ include garbage collectors, i.e., they are "garbage collected implementations of C++".  The next version of C++ is more explicit in allowing for such implementations, but they've existed for a long time. -- James Dennett (talk) 07:40, 2 January 2009 (UTC)

 * But if C++ is defined by the standard and the standard doesn't include any such default capabilities any deviant implementation will not be C++, right ?
 * Can you point me to one of those implementations, as I said I searched for them and came up empty I'm curious to see if they are really labeled as C++, if so it can have a detrimental effect on the language. For what I know "C++" is not a trademark (brand) like "Java" is and so open to be abused, but I would like to think that they would clearly make a distinction that it was not an implementation of C++ but an extension to it (as defined and permitted on the standard, not everything can be added as a library), even Microsoft has done so in the past. --Panic (talk) 18:50, 2 January 2009 (UTC)

 * Nothing in the C++ standard forbids garbage collection, though C++0x makes it clearer that GC is permitted (and provides some more control for it). C++ permits garbage collection, but does not require it.  "CC -library=gc" is an option from Sun (see http://developers.sun.com/solaris/articles/libgc.html) but it's also somewhat common to use the Boehm collector  -- James Dennett (talk) 03:57, 3 January 2009 (UTC)

 * Humm I think we have crossed wires somewhere. What I'm attempting to understand and to what I disagree is the wording of "implementations of C++" (notice that you last edit to the page added also C++ to the phrase), I don't think I'm getting the definition of garbage collecting wrong with you, from the above url "Garbage collection deals with the automatic management of dynamic memory." this so far I know is excluded from the standard, that is the C++ languages doesn't define or implement it, but does support external (to the language) implementations. In the example above that compiler uses the libgc and they clearly state "The library takes care of freeing memory that is not in use.".
 * I agree with all the rest you have said on the above post. I'll retrace the steps to see were I (or you) got lost. I claim that "a garbage collected implementations of C++" is not a good statement, first the use of the adjective "collected" indicate that the actions is finished/done, literally can be read as indicating an implementation of C++ that was generated using garbage collection, this can be true but that is not very relevant to the paragraph and can be confusing, and from the argumentation above this is not what you were attempting to say, since you stated «Some implementations of C++ include garbage collectors, i.e., they are "garbage collected implementations of C++"», and this is incorrect, any garbage collecting mechanism incorporated into the language would by default generate a new language (or at least a new version of the language) and any external inclusion of garbage collecting capabilities would be extensions (and are permitted and defined as such in the standard), and so, the previous statement on that page "C++ does allow for garbage collection, and garbage collection implementations (often based on the so-called Boehm collector) do exist" seem clearer and with only a correct interpretation.
 * Since we clearly understands the concepts and agree on the theory behind it, can you state where my rational as explained above is wrong and the downside of the statement before your last edit ? --Panic (talk) 07:24, 3 January 2009 (UTC)
 * It is idiomatic to speak of "garbage-collected implementations of C++", and doesn't imply anything more than that they are (a) implementations of the C++ language and (b) they offer facilities for garbage collection. For example, see http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) which says "Other languages were designed for use with manual memory management, but have garbage collected implementations (e.g., C, C++)."  There's a difference between saying that "garbage collection implementations" (i.e., implementations of garbage collection) exist and noting that "garbage-collected implementation of C++" (i.e., implementations of the C++ programming language that offer garbage collection support) exist.  The very fact that people mistakenly think that a C++ implementation cannot include garbage collection is why we should not write the former.   Note also: the C++ standard defines "implementations" which cover both language and library, as well as any underlying platform; a feature may well be implemented by a library and yet still be very much a part of the associated "implementation" of C++.  The original phrase used, "garbage collected implementations" meant "implementations [of C++]" implicitly, but your edit shows that it was not clear enough. -- James Dennett (talk) 20:50, 3 January 2009 (UTC)
 * Ha, yup that was it, now we identified the problem (my native language is not English), I did some searches (and looked on that Wikipedia link content), it a bit disconcerting that I've never noticed this, my education on the subjects was mostly based in English (US) literature, and have read some paper since then and never noted the wording "garbage collected languages" was used, and as I pointed above it doesn't seem correct English. I've learned OOP and about GC with Smalltalk, I've looked into the literature I have and it isn't never used, not even on the C++ literature, it is proper to say garbage-collected heap or class but stating that a language is garbage collected never appears and it still seems wrong, but now I understand that we were referring to the same thing. I will think in a way to extend that section in a way that this issue is made clearer, I strongly doubt that I'm alone on the literal interpretation I gave to the wording, even if your wording is commonly used (4,190-5,590 hits on google, not hugely common, but well above my option)...
 * Just to understand how common it is I asked some people, most responded with a third option "language with garbage collection".  --Panic (talk) 00:54, 4 January 2009 (UTC)
 * In google books we get 61 hits on "garbage collected language", mostly in "recent" books the oldest being from 1993 (that would explain how I never came across it) and coincidentally dealing with C++, The Evolution of C++ by Jim Waldo from MIT Press, where it shares my interpretation that a garbage collected C++ would be a new implementation of the language (a new language or a new version of the language), and casts a dark picture in that if such evolution occurs C++ will lose the low-level capacity people tend to select C++ for.  --Panic (talk) 02:04, 4 January 2009 (UTC)
 * C++ already has optional support for garbage collection. The key is that it is optional, so C++ does not lose any low-level capability as code does not have to use GC at all.  The author of "The Design and Evolution of C++" is a strong supporter of garbage collection for C++ ;-) but if you can find a way to phrase things that is clearer while also being informative and correct, that would be great. -- James Dennett (talk) 03:29, 4 January 2009 (UTC)

In The Design and Evolution of C++, page 68, "...I suspect that since the fundamental design choices from C++ were made assuming the absence of garbage collection, a C++ garbage collector would be less efficient than, say, a good Lisp or Clu garbage collector. Worse, I suspect that a garbage collected C++ would fail to deliver the low-level performance people have come to expect from C++." not what I would call a strong supporter for a "garbage collected C++" at least at the time he wrote the book, since then his work on Java (at Sun Microsystems Laboratories) may have changed his view but couldn't find any info on that. Waldo is also known for his opinion on C++'s multiple inheritance and work on distributed computing. --Panic (talk) 04:30, 4 January 2009 (UTC) I've reworded the section a bit incorporating some of what we said here and I was strongly motivated to remove the "strangely named idiom" bit but will let you decide if we should keep that in, see if you have any problem with it now. --Panic (talk) 05:30, 4 January 2009 (UTC)
 * ident reset
 * The point from D&E is that C++ would have failed if it had *mandatory* garbage collection. The world has moved on, and people including BS recognize that better support for *optional* garbage collection is important for C++ (see also discussions on "litter collection"). See also http://www.research.att.com/~bs/bs_faq.html#garbage-collection (I don't know if I have enough motivation to review the text again). -- James Dennett (talk) 09:37, 4 January 2009 (UTC)
 * OK, I motivated myself a little, and reviewed it. Unfortunately I find the latest version rather unreadable, in spite of a lot of work we seem to be making the book worse rather than better.  Hopefully someone else can work on this to better effect.  -- James Dennett (talk) 09:45, 4 January 2009 (UTC)
 * And one note: I expect you didn't really mean to suggest that Bjarne Stroustrup worked at Sun (or on Java)! -- James Dennett (talk) 09:56, 4 January 2009 (UTC)

C++ Programming/Half open
Can I tag this for deletion or were you going somewhere with it? I attempted to figure out where to make use of it on the book but came up empty. Probably in an exercise ? If no reply in 7 days I'll tag it for speedy deletion (only a single "real" edit in 20 November 2004). --Panic (talk) 19:33, 12 April 2009 (UTC)

 * Do what you will.  Half-open ranges are fundamental to C++'s library, but this content doesn't seem very well suited to a C++ book. -- James Dennett (talk) 22:21, 12 April 2009 (UTC)

 * Done. --Panic (talk) 23:15, 12 April 2009 (UTC)

title: User talk:James Dennett


text:
Robotics/Design Basics/Physical Design

General Design Considerations
Designing a robot requires balance between size (mostly weight), motor power and battery power. These three elements are connected with each other (more battery power increases the weight of the robot and requires stronger motors) and finding the "perfect" balance requires a lot of tweaking and experimenting. Try to describe heavy components in output/mass (e.g. motors: torque/Kg; batteries: mAh/Kg) and pick the one that gives the highest value.

Using light materials brings down the weight significantly (aluminum instead of steel). Building a frame out of light metal and using plastic plates as surfaces would be a lot lighter than using metal plates. For small robots acrylic plastic is a good material to use and it is easy to work with.

There are other ways to build a robot than to cut and drill your own aluminum plates. Toys like Lego Technic and Meccano, although expensive, are an alternative when you don't have the ability to cut and drill your own parts. Especially Meccano (or better: the cheap imitations) can be useful even when you do make your own parts. There is something convenient about having a collection of parts with standard holes and sizes. Of course you would need to drill your own holes at the right distances and size, if you intend to add Meccano parts. The values can (most likely will) differ between different "brands" of imitations. So it's a good idea to buy a few boxes when they are on sale. Screws tend to be M5 (on the set I've seen so far this is the only value that is common. The hole spacing very rarely matches up).

Another kit that would be good to use is the Vex™ Robotic Design Kit from Radio Shack. The parts in this kit are all metal with holes predrilled every half an inch. That makes it easier to add to parts that you may already have. This kit gives you everything you need to get started with robots. If you do not want to buy the kit you could just buy the Vex™ Metal and Hardware Kit for Robotics Starter Kit.

When you start your design, first decide how big you want your robot to be. Don't think about exact sizes, compare it to the size of an object ("the size of a shoe box") will be sufficient. Exact values can be "calculated" after you've got your motors and batteries, as these have a large influence on the size and shape of the robot.

Make an estimate about the weight of the complete robot and pick your motors and wheels. Keep in mind you need high torque and low speed. A bare DC-motor has high speed and low torque, adding a gear reduction will solve this one. Motors with reduction gears are also available. The speed of your motor and the size of your wheels determine how fast your robot will be able to move.

For example: RB-35 is a motor with a 1:50 reduction. It makes 120 RPM or 2 rounds per second. Lets pick a wheel with a diameter of 20cm (radius R = 10cm). This wheel has a circumference of 2 x $$\pi$$ x R = 2 x 3.14 x 10 = 62.8cm. This means in one turn the wheel moves 62.8cm. When we mount this wheel on the motor it'll turn twice every second and therefore move 2 x 62.8cm = 125.6cm. So its speed would be 125.6cm/second or 1.256m/s.

In reality this speed is going to be a little lower as the motor turns 120RPM without a load. But even a 1 m/s is pretty fast for indoor robots. You'll probably use PWM or other methods to slow it down.

Pick your batteries. Make sure you have enough power to keep the motors and all the electronics running for a sufficient amount of time and keep some reserve for future additions. Compare the weight of the batteries and motors you've chosen to what you had planned. You might need to go over this part again (picking different motors and/or batteries). Keep in mind that your robot's body has a significant weight.

Wheeled Platforms
Wheeled platforms can have any number of wheels. Most common are 3, 4 and 6 wheeled vehicles (excluding wheels used for feedback). Other numbers are also possible, but can be hard to build, such as 1-wheeled or 2-wheeled robots, or have superfluous wheels which can make turning difficult or complex. Basically there are 2 types of wheels: powered wheels and unpowered wheels. The first are powered by the motors and are used to move the robot forwards (or backwards). Unpowered wheels are used to keep the robot in balance by providing a point of contact with the ground.

Turning
Turning can be accomplished in several different ways:

 * Differential Steering (Tank-like Turning):
 * Moves one wheel forward and the other backwards. The robot turns around within a small circle which centre lies in between the 2 powered wheels.
 * Move one wheel slower than the other, the robot turns in the direction of the slower wheel. How fast it turns depends on how large the difference between the 2 speeds is.

 * Ackerman Steering: This is the same steering system as the one used in cars. It is relatively complicated to implement since the inner and outer wheels need to turn to different angles.

 * Crab Drive: Each wheel can turn independently in crab drive steering. This can be very flexible, but requires complex mechanics which either turn the entire motor/gearbox/wheel assembly or transfer power from a statically mounted motor. The second option is much more difficult to build but may have advantages over the first.

 * 3-wheeled platforms: These can come in a variety of forms, with the articulated wheel powered, or with the two fixed wheels powered, or a combination of the two. These are generally built for very specific purposes.

 * Omnidirectional wheels: The omnidirectional wheels design is based upon the use of a series of free turning barrel-shaped rollers, which are mounted in a staggered pattern around the periphery of a larger diameter main wheel. For this you need 4 powered wheels. However these wheels allow movement in any direction without turning (including sideways and diagonal movement) and can turn the same way as in tanklike steering. Building these wheels is time-consuming, but it's a very powerful steering method. Also, inexpensive omnidirectional wheels are available commercially, often used in conveyors. One drawback, however, is the lack of sideways traction; if something is pushing the robot to the side, it relies on the strength of the motor or brakes to restrain it. Omnidirectional wheels used in place of caster wheels can provide quicker responses and can often roll over larger obstacles.

Tracked Platforms
Tracked platforms use tracks similar to tanks. This kind of propulsion is only useful on loose sand and mud, as concrete and carpet provide too much horizontal traction when turning and will strip the tracks off of their guides.

Walkers
Walkers are robots that use legs instead of wheels or tracks. These robots are harder to build than wheeled robots and can be a nice challenge for an experienced builder. Walkers are designed to imitate how animals (or humans) move.

2-Legged Walkers or Bipeds
This is the hardest type of walker. This type tries to imitate how humans walk. The biggest issue is balance.

Two-legged walkers are used for two main purposes: to imitate humans and to provide a great amount of force and traction. Taller walkers used to imitate humans are difficult to build, requiring many balancing circuits and devices, quick motions, and precise construction. Just like any human knows, these can also be knocked over, tripped, etc. Shorter, wider walkers can be used to move a large load. When using walkers, it is possible to use pneumatic systems, which can provide a much larger force than motors. However, turning with such a system is nearly impossible.

4-Legged Walkers
4 Legged walkers imitate 4 legged animals. Many of these designs end up moving one leg at a time, instead of the 2-legged movements typical of animals. It requires 3 legs to be on the ground to provide static balance. Dynamic balance moving 2 legs at a time provides faster and more fluid motion.

6-Legged Walkers or Hexapods
These walkers are imitations of insects. Many of these move 3-legs-at-a-time to provide static balance. Because half of the legs can be moved at one time without losing static balance, 6-legged walkers can actually be simpler to build than 4-legged.

Note: Static balance means the construction is at all time in balance. This means that if the robot would stop moving at any time it wouldn't fall over. In contrast there is Dynamic Balance. This means that the robot is only in balance when it completes its step. If it's stopped in the middle of its step it would fall over. Although this might sound like a bad thing, dynamic balance allows much faster and smoother movement, but requires sensors to sense balance. Animals and humans move with dynamic balance.

Whegs
There are various combinations of wheels and legs that are useful for varying terrain. For quick details see.

Ball Wheels
This means of propulsion is very similar to how a classic computer mouse works: A ball is mounted in a casing in such a way that it can freely rotate in any direction. Two wheels around the ball are mounted against this ball at an angle of 90° to each other, parallel to the ground. One wheel registers the up-down movements and the other the left-right movements.

A ball wheel uses the same setup but connects the internal wheels to motors. This way the ball can be made to rotate in any direction. A robot equipped with a ball wheel can move up-down and left-right, but can't rotate around its vertical axis. Using 3 ball wheels allows rotation as well.

Electronics
The electronics of a robot generally fall in 6 categories:
 * Motor control: controls the movement of the motors, servos and such. Relays and PWM H-bridges fall under this category.
 * Sensor reading: reads the sensors and provides this information to the controller.
 * Communication: Provides a link between controller and an external PC, another robot, or a remote control.
 * Controller: microcontroller board, processor board or logic board. This part makes decisions based on sensor input and the robot's program.
 * Power management: parts that provide a fixed 5VDC, 12VDC or any other level coming from the batteries. Circuits that monitor the status of the batteries.
 * Glue logic: Additional electronics that allow all the parts to be connected with each other. An example is a CMOS to TTL level converter.

Not all of these categories are present in all robots, nor does every circuit fall completely into one category. Many robots don't require a separate sensor board as a whole lot of sensors have built-in electronics which allow them to connect directly to a µcontroller/processor.

Some Tips

 * Use low-power (or simply dimmer) LEDs. Always. This drastically reduces how much current your circuits consume. A normal LED consumes around 15 mA. A modern microcontroller consumes about the same. Disabling unneeded LEDs is advisable, but not always possible.

 * Use CMOS ICs instead of classic TTL. Again this reduces current usage and allows a more relaxed supply voltage. But pay attention to their sensitivity for static electricity when soldering them.

 * Use good quality IC-sockets (or better don't use IC-sockets at all). They're worth their price.

 * Avoid using IC-sockets on sensitive circuits (high speed digital, clock signal and analog signals). The moving robot can shake those ICs loose over time. Using In-Circuit programmable microcontrollers removes the need to be able to unplug an IC.

 * LEDs are very practical to make slow digital signals visible, adding them on some signal lines can be interesting for testing purposes, however, they do increase power consumption. Removing them when your circuit works correctly can make it more power efficient (replace LED with a wire, replace resistor with a higher value one).

 * See if your microcontrollers can run with a lower clock speed. The higher the clock speed, the more they consume.

 * Use your microcontrollers sleep functions whenever possible, disable any part that isn't required (e.g. on-chip ADC).

 * Learn to make PCBs (Printed Circuit Boards). It's not that hard and it makes your electronics look more professional. Don't throw away your breadboard, PCBs aren't very practical for prototyping.

 * If you're up to it: build your circuits in SMD components on PCBs. This reduces size, weight, and cost. However soldering SMD ICs isn't easy. SO-packages (Small Outline) aren't too hard for an experienced builder. Smaller packages are almost impossible to do by hand. Get good soldering tools before you attempt this. For many modern SMD microcontrollers are complete build and tested board available. These can be a solution for those who don't have the equipment, expertise and patience to solder these ICs themselves. These boards don't have to be large as the demo-boards most IC developers sell, e.g. the BasicStamp is such a board with the size of an IC.

 * Buy a breadboard. They're invaluable for designing and testing circuits.

 * If you intent to build your own electronic circuits, invest in a dual channel oscilloscope. Single channel is very restricting. Pick one with as high a bandwidth as you can afford. At least 4x the highest signal frequency you intend to use.

 * A good variable power supply is very handy to test how your circuit operates at lower voltage levels (as happens when the batteries discharge).

 * If you can choose between pull-up and pull-down resistors, pick the one that uses the lowest amount of power. If the circuits output is at +5V most of the time, use pull-up, if it's 0V use pull-down. Remember that such outputs consume power when the transistor is active (when it's inactive it consumes a small amount of power: a leak current through the resistor and through the input impedance of the next circuit).

 * Use high value resistors as pull-up/pull-down. But keep in mind that high speed signal lines need lower value resistor in order to minimize signal distortion.

 * Most electronic components on a robot will run on a 5V supply and need a 5V regulator. Use a regulator with low dropout to prevent the 5V supply from browning out.

Display
Very simple robots need only a few LEDs to show everything that it is "thinking".

When trying to debug more complex robot software, it is useful for the robot to display text. A few calculators and PDAs have a RS232 connector or some other simple way to connect to a robot.

Many robots have such a calculator or PDA or other display strapped to the top in order to show the humans what the microcontroller is "thinking", which is vastly more productive than trying to guess what's going on inside that little chip of silicon.

With large robots, sometimes a full-size laptop computer is strapped on top for such display purposes.

Balance
Everybody encounters balance every day. While walking, when putting down a glass of water or in so many other ways we have to keep a balance. Now in most of these cases you wouldn't need to think about it, but when designing your robot you'll have to keep an eye on this concept. For most designs, balance isn't hard to achieve, even without doing calculations on it. A few rules of thumb suffice. For more complex designs, e.g. a robot with an arm, you can get away with just some rules of thumb and some common sense, but there's no guarantee. Doing a simple calculation would make it clear if the robot is going to stay on its wheels or if it is going to tumble over and crush whatever it was trying to pick up.

If you're into walkers, you'll need to spend more attention to balance. The fewer amount of legs you have, the more important balance becomes.

Simple 4-Wheeled Robots
Achieving balance on this type of robot is pretty trivial. Keep the center of mass between the wheels (picture a rectangle between the centers of the wheels) and as low as possible. In practice it mean you should place the heavy components, e.g. the batteries, somewhat in the center of the robot and as low as possible.

Simple 3-Wheeled Robots
These designs are nearly as simple as 4-wheeled robots; the difference lies in that you need to keep the center of mass close to the center of the triangle formed by the wheels. If your robot is rectangular avoid placing weight at the two unsupported corners. These points are prone to making the robot tumble over.

Wheeled robots with an arm or gripper
For the working of an arm or a gripper, we need to take the help of a stepper motor in simple cases or use sensors in sophisticated cases.

title: Robotics/Design Basics/Physical Design


text:
Ada Programming/Libraries/Standard/Apex

Please note that you cannot actually compile this package.

|Standard:Apex

title: Ada Programming/Libraries/Standard/Apex


text:
Japanese/Kana/Lessons/Hiragana/Lesson 3

In this lesson you are going to learn how to read and write さ、し、す、せ、そ. Adding two small lines called dakuten, but commonly known simply as  tenten, meaning "two marks", causes clear sounds to change to their voiced sound. Thus, adding the tenten marks to さ、し、す、せ、and そ will produce ざ、じ、ず、ぜ、ぞ.

title: Japanese/Kana/Lessons/Hiragana/Lesson 3


text:
Japanese/Kana/Lessons/Hiragana/Lesson 4

In this lesson you are going to learn how to read and write た、ち、つ、て、と. Adding two small lines called dakuten, but commonly known simply as  tenten, meaning "two marks", causes clear sounds to change to their voiced sound. Thus, adding the tenten marks to た、ち、つ、て、and と will produce だ、ぢ、づ、で、ど.

Clear sounds

 * Note: In Japan, the t is crossed first, not last.

Double Consonants
By adding a small "っ" (tsu) in front of a syllable, it causes the subsequent consonant to double. This is called the sokuon. This kana results in a slight pause between the two consonants (a double consonant pause). There is an exception for the kana ち. Instead of having a 'cch', a ~tch is used.

A couple examples are かった (katta) and しっけ (shikke).

title: Japanese/Kana/Lessons/Hiragana/Lesson 4


text:
Japanese/Kana/Lessons/Hiragana/Lesson 5

In this lesson you are going to learn how to read and write な、に、ぬ、ね、の.

title: Japanese/Kana/Lessons/Hiragana/Lesson 5


text:
Japanese/Kana/Lessons/Hiragana/Lesson 6

In this lesson you are going to learn how to read and write は、ひ、ふ、へ、ほ. Adding two small lines called dakuten, but commonly known simply as  tenten, meaning "two marks", causes clear sounds to change to their voiced sound. Thus, adding the tenten marks to は、ひ、ふ、へ、and ほ will produce ば、び、ぶ、べ、ぼ. Adding a small circle called a handakuten, but commonly known simply as a  maru, "circle" causes clear sounds to change to their plosive sound. Thus, adding a maru to は、ひ、ふ、へ、and ほ will produce ぱ、ぴ、ぷ、ぺ、ぽ.

 * Note: "は" is pronounced wa when used as a particle.

title: Japanese/Kana/Lessons/Hiragana/Lesson 6


text:
User:GJeffery~enwikibooks

I am Graham Jeffery, from London, UK. My background is a degree in Mathematics followed by several years as a software consultant and a strategy consultant. I currently work in the pharmaceutical industry assisting clients to make better decisions regarding their assets in clinical development.

I started contributing to Wikipedia and Wikibooks in Nov 2004.

title: User:GJeffery~enwikibooks


text:
Japanese/Kana/Lessons/Hiragana/Lesson 7

In this lesson you are going to learn how to read and write "ま", "み", "む", "め" and "も".

title: Japanese/Kana/Lessons/Hiragana/Lesson 7


text:
Japanese/Kana/Lessons/Hiragana/Lesson 9

In this lesson you are going to learn how to read and write "ら", "り", "る", "れ", "ろ".

Note: The handwritten form varies slightly from the printed form り

title: Japanese/Kana/Lessons/Hiragana/Lesson 9


text:
Japanese/Kana/Lessons/Hiragana/Lesson 8

In this lesson you are going to learn how to read and write "や", "ゆ" and "よ".

Yōon Hiragana
Certain sounds ending with -い(i) ( き(ki), し(shi), ち(chi), に(ni), ひ(hi), み(mi), り(ri) and their voiced variants) can be followed by small versions (ゃ, ゅ, and ょ) of the hiragana や(ya), ゆ(yu), and よ(yo). In this case, the two hiragana are not pronounced individually, but rather as one sound.

In most cases, the compound sound is the consonant of the base syllable followed by the modifier (fjord may be an example of a similar compound sound in English):
 * きゃ (kya)
 * きゅ (kyu)
 * きょ (kyo)

In other cases the y sound disappears entirely:
 * しゃ (sha)
 * しゅ (shu)
 * しょ (sho)

Look at the Kana Chart for the others.

title: Japanese/Kana/Lessons/Hiragana/Lesson 8


text:
Japanese/Kana/Lessons/Hiragana/Lesson 10

In this lesson you are going to learn how to read and write "わ", "を" and "ん".

Note: The "を" syllable is used only for the object marker particle. No other word is written with "を".

Note: No word starts with "ん".


text:
Japanese/Kana/Lessons/Katakana/Lesson 1

Welcome to the first installment of the katakana lessons. In this lesson you are going to learn how to read and write the Japanese vowels, "ア", "イ", "ウ", "エ" and "オ".

Japanisch/ Katakana Japonais/Katakana/Leçon 1

title: Japanese/Kana/Lessons/Katakana/Lesson 1


text:
Japanese/Kana/Lessons/Katakana/Lesson 2

In this lesson you are going to learn how to read and write カ、キ、ク、ケ、コ. Adding two small lines called dakuten, but commonly known simply as  tenten, meaning "two marks", causes clear sounds to change to their voiced sound. Thus, adding the tenten marks will cause カ、キ、ク、ケ、コ to be produced ガ、ギ、グ、ゲ、ゴ.

title: Japanese/Kana/Lessons/Katakana/Lesson 2


text:
Japanese/Kana/Lessons/Katakana/Lesson 3

In this lesson you are going to learn how to read and write サ、シ、ス、セ、ソ. Adding two small lines called dakuten, but commonly known simply as  tenten, meaning "two marks", causes clear sounds to change to their voiced sound. Thus, adding the tenten marks to サ、シ、ス、セ、ソ will produce ザ、ジ、ズ、ゼ、ゾ.

title: Japanese/Kana/Lessons/Katakana/Lesson 3


text:
Japanese/Kana/Lessons/Katakana/Lesson 4

In this lesson you are going to learn how to read and write タ、チ、ツ、テ、ト. Adding two small lines called dakuten, but commonly known simply as  tenten, meaning "two marks", causes clear sounds to change to their voiced sound. Thus, adding the tenten marks to タ、チ、ツ、テ、ト will produce ダ、ヂ、ヅ、デ、ド.

title: Japanese/Kana/Lessons/Katakana/Lesson 4


text:
Japanese/Kana/Lessons/Katakana/Lesson 6

This page introduces "ハ", "ヒ", "フ", "ヘ" and "ホ". Adding two short lines, the dakuten or, more informally, tenten  meaning "two marks", to create "バ", "ビ", ""ブ", "ベ" and "ボ" changes clear sounds to voiced ones. Adding a small circle called a  handakuten, but commonly referred to as maru  meaning "circle", written "パ", "ピ", "プ", "ペ" and "ポ" changes clear sounds plosive sound.

title: Japanese/Kana/Lessons/Katakana/Lesson 6


text:
Japanese/Kana/Lessons/Katakana/Lesson 5

In this lesson you are going to learn how to read and write ナ、ニ、ヌ、ネ、ノ.

title: Japanese/Kana/Lessons/Katakana/Lesson 5


text:
Japanese/Kana/Lessons/Katakana/Lesson 7

In this lesson you are going to learn how to read and write マ、ミ、ム、メ、モ.

title: Japanese/Kana/Lessons/Katakana/Lesson 7


text:
Japanese/Kana/Lessons/Katakana/Lesson 9

In this lesson you are going to learn how to read and write ラ、リ、ル、レ、ロ.

title: Japanese/Kana/Lessons/Katakana/Lesson 9


text:
Japanese/Kana/Lessons/Katakana/Lesson 8

Below we'll be looking into the characters "ヤ", "ユ" and "ヨ". These are transliterated as "ya", "yu" and "yo", respectively.

Choon Katakana
Certain sounds ending with -イ(i) ( キ(ki), シ(shi), チ(chi), ニ(ni), ヒ(hi), ミ(mi), レ(re) and their variations) can be followed by small versions (ャ, ュ, and ョ) of the katakana ヤ(ya), ユ(yu), and ヨ(yo). In this case, the two katakana are not pronounced individually, but rather as one sound, taking up one mora.

In most cases, the compound sound is the consonant of the base syllable followed by the modifier (fjord may be an example of a similar compound sound in English): In other cases the y sound disapears entirely: Look at the Kana Chart for the others.
 * キャ (kya)
 * キュ (kyu)
 * キョ (kyo)
 * シャ (sha)
 * シュ (shu)
 * ショ (sho)

title: Japanese/Kana/Lessons/Katakana/Lesson 8


text: Japanese/Kana/Lessons/Katakana/Lesson 10


text:
User talk:GoodStuff

Hey, good to see you back in action on the Japanese wikibook. I hope you have time to be around for a while. In any case, you should sign up for the new mailing list. - Sik0fewl 14:38, 12 May 2005 (UTC)

healthy/healthful
See here: http://www.grammarerrors.com/wordchoice.html

Granted, the distinction is often ignored in recent years, but it's a good distinction to make. I never eat healthy food, excepting bean sprouts and alfalfa sprouts I guess. Most of my food is dead.

Japanese wikibook
yes, that's why i stopped and asked, if u dont find that, here is what i asked. thx for ur concerns. --Yacht 13:10, 24 August 2005 (UTC)

title: User talk:GoodStuff