I was going to do a detailed JAL manual later when I finish catPad project.
With simple examples *AND* serious complex examples such as Graphics Animation, DSP for tone generation, detection and filtering, AES, CRC, and such. I actually had this as a paying job once (for C++). But I think the jallib style guide should be separate as there are other opinions on programming style which are perfectly acceptable to the Language Definition and also not different to other library / "official" styles. The Jallib style is perfectly fine and acceptable if you want to contribute to jallib, but otherwise people might even be put off by that exclusive lower case + underlines + rarer 3 space indent. But in either case we (this project or my future project, which are not mutually exclusive) need a hot line to Kyle. Such as the other day when he explained how to use Chip Defs in code to check stuff. Also if he is "about" to release ability to have print_string(terminal, "This is a message") rather than const byte MSG1[]= "This is a message" print_string(terminal,MSG1) He has suggested this is "soon". Also some_proc(byte in stuff[]) works but some_func () return <some sort of array> doesn't Functions and Out parameters can only be scaler, not vector? Also how close are we to having Struct/Record or maybe enum or sets? I'm thinking also "start <Task>" and suspend should be removed. Or warned against use *ever* as 1) It's so limited there are better ways 2) It doesn't work at all on 18F currently (confirmed by Kyle) 3) The 16F is totally brain dead for multitasking this way, and the 18F is only barely sensible. 4) I'm writing a paper on how to decently do multitasking in JAL without Assembler, "start" or "suspend". 5) Inherently any decent model of multitasking uses too much RAM for PIC and needs either a Software stack (slow) or can't suspend/signal in a call. CPUs with a stack pointer that points at real RAM, the scheduler can create "process frames", each is a separate stack (and optionally heap). switching task is then a swap of stack pointer after context is saved on stack. If you really want multithreaded/ Multiprocess you need an ARM Cortex (same price). > The current title is "JAL 2.0 manual". This title has not much to do > with jallib, and we are not jal 2.0 anymore. My idea for this manual > is to be a "extended language ref" with a small reference to the > jallib style guide, as well as reference to some jallib libraries. For > example, when explaining array's, I would also put a note about the > jallib large_array library. > > It will not be a picture book like the tutorials. It will be code > only. > > I am also interested in a Jallib complete library reference, should > this be in the same book? > > Matt. > > On Apr 1, 4:09 am, Sebastien Lelong <[email protected]> > wrote: > > > Hi Chief Editor, > > > 2010/4/1 vasile surducan <[email protected]> > > > > However, the "jallib group" is an entity which doesn't written a word on > > > the original pjal documentation. So maybe keeping the title and the main > > > authors as is, should be a good idea and put somewhere the jallib logo > > > (BTW, > > > someday my daughter ask me the copyrights incomes, when she draw it has 9 > > > or > > > 10 if I remember well and now has 19). > > > So, should we change logo ? Maybe we could organize a contest ? > > > Cheers, > > Seb -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
