Elua on Mizar32 book
Locked
12
12
|
On Wed, Jan 12, 2011 at 11:20 AM, Martin Guy <[hidden email]> wrote:
> On 12 January 2011 11:29, Bogdan Marinescu <[hidden email]> wrote: >> On Wed, Jan 12, 2011 at 3:34 AM, Martin Guy <[hidden email]> wrote: >>> Ok, here's a first suggestion for skeleton chapters. Add stuff at will. >>> http://tracker.eluaproject.net/projects/elua/wiki/EluaOnMizar32 > >> I took a look at the chapter list and I'd like to understand the >> purpose of this project better. Your initial message said "We're >> writing a book for a tiny computer that runs eLua natively" (which is >> great BTW :) ). My problem is that I don't really understand what the >> idea of an "eLua computer" is to you. I can see chapters like this in >> your book: >> >> - list of pin assignments on connectors, *memory map* and other stuff >> from the mizar32 wiki >> - invitation to produce your own boards and derivatives >> - Compiling the eLua interpreter from source using Ubuntu, as flash >> image or for SD card with eLuaBLOD >> - Flashing firmware using DFU bootloader >> - Mention mizar32 Google code project for precompiled firmware and >> latest patches >> >> This hints to the fact that your eLua computer is targeted towards >> experienced developers. Nothing wrong with this, I just want to >> understand where you're trying to go, as my own ideas about an >> eLua-based computer are a bit diferent and I need to understand yours. > > and, privately: > > 2011/1/12 Sergio Sorrenti <[hidden email]>: >> Una cosa importante, e' che il libro sia veramente popolare, >> quindi non mirato agli universitari ma a tutti. > or >> Something important is that the book be truly (er, literally, "aimed at the general populace"; it's not non "popular" as in "with lots of people who like it"), >> so not aimed at university types but at everyone. > > Thanks. I just put down what would seem absolutely necessary to me as > a developer or to someone like me at mid-late school age. I'm used to > teaching 18-21s, but that is just be a professional deformity of mine. > :) > But absolutely i agree, defining the target audience is critical. > > In the 80s Acorn (as it was then) produced "Atomic Theory and > Practice" teaching programming in BASIC and even a full course in 6502 > assembler(*). It was a huge step in my programming education and I > devoured every page. But something like that takes a year to write. > > My first hack at a contents list is just a collection of the essential > info for a geek, plus a scraping of the wikis and mailing list posts. > I'm also anxious to lift as much of it as possible from existing > sources, of course. > > Should we (can we?) include the Atmel datasheet which describes the > operation and register layout of the devices? Does book size > significantly increase the printing costs or not? Shipping for sure, > as extra weight. A few thoughts on this front: I wouldn't include a full datasheet up front (and certainly not the whole manual, since I'm sure that's over 100 pages :-)), but I definitely would include quick-reference material that will be essential for operation of the peripherals (like which output pins correspond to what functions, and maybe tables of configuration parameters if they're configurable on different pins). I'd try to keep what's in the document down to the essentials and leave the nitty gritty details to the datasheet or some other online resource. Here's an example of such a quick-reference page from mbed: http://mbed.org/handbook/mbed-NXP-LPC1768 (they also ship a credit-card sized plastic card in the box that has that image on the top printed on it) As far as how one would present other content in the book, I would start with things that the user can immediately dive into and get working, starting with simpler examples so that the user will feel like they have a handle on what each line of code is doing and what all the connections are for, and moving on to more advanced examples (on a graduated basis, I wouldn't immediately jump to something like "writing your own C module!"). As above, I would be selective about including highly detailed technical things, but quick references and cheat sheets are fabulous to have in paper form for both novice and advanced users when they have already gotten a handle on things but can't remember what function does one thing or another. For peripheral modules, I might even include very short examples for the patterns for configuring a module and sending/receiving information using that peripheral. I guess one other question to ask is whether this is to be reference material or a quick start guide. I don't think that included documentation needs to be exhaustive as long as more detailed information is available quickly and easily online. I think there should be some sort of happy medium where the printed document is useful both when the user is just getting started (to keep them interested and motivated) and to more advanced users (providing some useful quick reference information) without having it take a year or more to put together. Of course, one can always make revisions as time goes along and respond to feedback from users. Updated versions can go in the latest shipping text and be available online so that users can read them on the computer, print them out or consume them in some other medium. > > Should we include stuff that's already on the web? I'd say yes, since > printed book format is much easier to learn from, read on the bus and > use as a reference while hacking. The pages should become stained with > food :) > > This points to a slim volume with reference data primarily, with > explanations around each item explaining its main components, how they > talk to each other and how to read the following diagrams/tables. > > Like I said: my list is a collection of the material we already have, > largely. If someone has a different overall structure in mind, or if > someone can brainstorm an alternative content list, we could add them > as alternative chapter lists, then synthesize a single work later on. > Feel free to modify the existing one. > > M > > *) with their amazing in-BASIC assembler, which would write machine > instructions sequentially in RAM at the address pointed to by P > autoincrementing P as a side effect, with some extra keywork to jump > to it as a subroutine. Example: > P=32768 > FOR I = 1 TO 10 DO > [ NOP; ] > END > [ RTS; ] > CALL 32768 > (or something like that. Sorry, I forget the BASIC syntax for FOR > loops. Thankfully.) > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On 12 January 2011 21:12, James Snyder <[hidden email]> wrote:
> credit-card sized plastic card in the box that has that image on the > top printed on it) Nice :) I agree with everything and have integrated your thoughts into the wiki page M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Suppose we drop a language tutorial as such, and just give tiny code
fragments? Teach them Lua by stealth without ever explaining it. :) then refer them to the LRM and PIL for a complete reference and tutorial. If, for each of our fragments, the preceding description of what it is trying to achieve is clear, it should be obvious what the code means. Well, ok, some explanation of tables when we first hit them. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Wed, Jan 12, 2011 at 10:41 PM, Martin Guy <[hidden email]> wrote:
> Suppose we drop a language tutorial as such, and just give tiny code > fragments? Teach them Lua by stealth without ever explaining it. :) > then refer them to the LRM and PIL for a complete reference and > tutorial. > > If, for each of our fragments, the preceding description of what it is > trying to achieve is clear, it should be obvious what the code means. > Well, ok, some explanation of tables when we first hit them. It's probably a good moment to confess that I have no idea at all about how to write a book, or how to be a good teacher in general. I tend to go from 0 to way too technical faster than a Porsche; however, people don't seem to like this as much as they like Porsches. This didn't even worked for the brief period of time when I teached some labs at the university, and those people were technical by definition :) That said I'd go with the approach suggested by James: start with stuff than even a beginner could easily grasp (setting up the board, running samples, on/off LEDs, switches, timers, UART + basic Lua (variables, functions, tables, modules)) then gradually get more advanced at user level (PWM, ADC, SPI, I2C, networking, remote file systems + using advanced Lua concepts such as metatables or manual control of the GC) and _maybe_ going very advanced, beyond user level (modify the eLua configuration and recompile it, how to use the platform interface to extend it, how write regular modules in C, how to write dynamically loadable modules in C and so on). The latter part might well stay in a wiki instead of the book itself, I have no idea if it should be it the book (and it's not my decision anyway :) ). Also I wouldn't include a datasheet. Not printed at least. I would burn in to a CD that I'd sell with the book if I could figure out if a CD is really needed. One question: do you plan to make this a standalone computer or not? My idea was to hook it to a VGA monitor or TV screen on one side and to a PS/2 keyboard on the other side (maybe via an IR link or something equally wireless) and use a simple but functional on-board editor to write programs. It would be a pity if this thing would need a PC to function. Best, Bogdan > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On 12 January 2011 23:17, Bogdan Marinescu <[hidden email]> wrote:
> (variables, functions, tables, modules)) then gradually get more > advanced at user level (PWM, ADC, SPI, I2C Yes > networking, remote file systems Maybe (see below) > using advanced Lua concepts such as metatables or manual > control of the GC) and _maybe_ going very advanced, beyond user level > (modify the eLua configuration and recompile it, how to use the > platform interface to extend it, how write regular modules in C, how > to write dynamically loadable modules in C and so on). Not in the book, I think. Maybe in Book 2 :) > One question: do you plan to make this a standalone computer or not? It can be or not, but I'd aim the book first at the bare main board. The possibilities opened by other hardware modules (serial port, ethernet, VGA/kbd/audio etc) and the possibilities that they open up, could be extra chapters in the online edition, maybe separate booklets that come with those modules when/if you buy them, which both conveniently limits the scope of the book and also allows for new hardware modules to be produced without having to reprint the whole book. > My idea was to hook it to a VGA monitor or TV screen on one side and > to a PS/2 keyboard on the other side (maybe via an IR link or > something equally wireless) and use a simple but functional on-board > editor to write programs. It would be a pity if this thing would need > a PC to function. yes, that is possible to create with the VGA/PS2/audio board, as I understand the hardware. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Thu, Jan 13, 2011 at 2:19 AM, Martin Guy <[hidden email]> wrote:
> On 12 January 2011 23:17, Bogdan Marinescu <[hidden email]> wrote: >> (variables, functions, tables, modules)) then gradually get more >> advanced at user level (PWM, ADC, SPI, I2C > > Yes > >> networking, remote file systems > > Maybe (see below) > >> using advanced Lua concepts such as metatables or manual >> control of the GC) and _maybe_ going very advanced, beyond user level >> (modify the eLua configuration and recompile it, how to use the >> platform interface to extend it, how write regular modules in C, how >> to write dynamically loadable modules in C and so on). > > Not in the book, I think. Maybe in Book 2 :) > >> One question: do you plan to make this a standalone computer or not? > > It can be or not, but I'd aim the book first at the bare main board. > The possibilities opened by other hardware modules (serial port, > ethernet, VGA/kbd/audio etc) and the possibilities that they open up, > could be extra chapters in the online edition, maybe separate booklets > that come with those modules when/if you buy them, which both > conveniently limits the scope of the book and also allows for new > hardware modules to be produced without having to reprint the whole > book. I understand your idea better now. Mostly you want the book to be about the board itself and what it can do, not to limit its scope around a single hw/sw combination such as an eLua based computer. Great, I think I got it :) > yes, that is possible to create with the VGA/PS2/audio board, as I > understand the hardware. It definitely is, and the results can be quite spectacular :) I tried the same thing on a different MCU but with the exact same hardware for video generation and it works very nice. Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
On Wed, Jan 12, 2011 at 18:41, Martin Guy <[hidden email]> wrote: Suppose we drop a language tutorial as such, and just give tiny code This is exactly the approach we have on our articles, projects and tutorials on the eLua User Labs wiki http://wiki.eluaproject.net The integration with the code will be better from now on, as we're moving the projects from local svn repos hosted here on the lab to public services (mostly github) that have facilities (and APIs). eLua main repo will also move officially to github soon. We have already an official mirror and many eLua-related projects hosted there already. We encourage users to make it grow and we will support new host plans or hosting options if necessary. If, for each of our fragments, the preceding description of what it is Yes. There is a whole new class of "users" in the eLua audience today that are not, don't want to and will never be "programmers". Industrial designers, event/show organizers, fashion/wearable creators, artists, college teachers, electronic hobbyists ....., the list surprises me every day. I think the approach Martin is trying to explain here is very useful for these creative specimens :) Well, ok, some explanation of tables when we first hit them. Yeah. And once they all (above) hear about Lua tables, they'll quickly become great programmers ! :)
Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by BogdanM
On Wed, Jan 12, 2011 at 4:17 PM, Bogdan Marinescu
<[hidden email]> wrote: > On Wed, Jan 12, 2011 at 10:41 PM, Martin Guy <[hidden email]> wrote: >> Suppose we drop a language tutorial as such, and just give tiny code >> fragments? Teach them Lua by stealth without ever explaining it. :) >> then refer them to the LRM and PIL for a complete reference and >> tutorial. >> >> If, for each of our fragments, the preceding description of what it is >> trying to achieve is clear, it should be obvious what the code means. >> Well, ok, some explanation of tables when we first hit them. > > It's probably a good moment to confess that I have no idea at all > about how to write a book, or how to be a good teacher in general. I > tend to go from 0 to way too technical faster than a Porsche; however, > people don't seem to like this as much as they like Porsches. This > didn't even worked for the brief period of time when I teached some > labs at the university, and those people were technical by definition > :) I certainly can't claim to know any sort of "secret" to teaching, nor have I done the curriculum for a class on my own. My suggestions are based on taking and TA'ing classes and also what I like to see in documentation (I absolutely _love_ simple working examples that a user can just paste in and start playing with :-) ). A few other things on the "teaching" front. While in a class students might not like questions at the end of a section describing something, since they often end up being homework, I've heard from a number of people that they like having suggestions at the end of a section for the reader to try implementing some variations on what was just discussed. I think this can be a good way to give some general information, an example or two and then have the user learn a bit about the system by trying to apply things. (i.e.: so now you know how to turn LEDs on and off, now implement a function that will make a binary display of a number you enter). I would be careful with making too much of a jump between covered concepts and these suggestions though (i.e.: they should neither be dumb nor almost impossible for someone who is looking at this stuff for this first time). I also think the "teaching by stealth" approach should be nice as well. I wouldn't make the language the focus, but rather what you can do with it (teach by example). Some things may require a bit of extra explanation if they extend beyond calling functions and assigning values to variables, but I would point them towards existing things like PIL or LRM. > That said I'd go with the approach suggested by James: start with > stuff than even a beginner could easily grasp (setting up the board, > running samples, on/off LEDs, switches, timers, UART + basic Lua > (variables, functions, tables, modules)) then gradually get more > advanced at user level (PWM, ADC, SPI, I2C, networking, remote file > systems + using advanced Lua concepts such as metatables or manual > control of the GC) and _maybe_ going very advanced, beyond user level > (modify the eLua configuration and recompile it, how to use the > platform interface to extend it, how write regular modules in C, how > to write dynamically loadable modules in C and so on). The latter part > might well stay in a wiki instead of the book itself, I have no idea > if it should be it the book (and it's not my decision anyway :) ). > Also I wouldn't include a datasheet. Not printed at least. I would > burn in to a CD that I'd sell with the book if I could figure out if a > CD is really needed. > One question: do you plan to make this a standalone computer or not? > My idea was to hook it to a VGA monitor or TV screen on one side and > to a PS/2 keyboard on the other side (maybe via an IR link or > something equally wireless) and use a simple but functional on-board > editor to write programs. It would be a pity if this thing would need > a PC to function. > > Best, > Bogdan > >> >> M >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
2011/1/10 Martin Guy <[hidden email]>
Hi! one suggest i want to give for this eLua and Mizar32 book, is to make it smart! with Webcams or Android Phone the users can easily read the printed QR Codes(maximum 4.296 characters). We can also make use in combination URL shortner, like goo.gl, for many benefict like the moving of the text resource, easy coping on browser, as well as to see how many peoples have access to the piece of code/example, having some feedback of the more preferred/liked and the disliked/unused. A more tight paper/Web work, without to sacrifice the reading in a sofa. Sergio _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Dado Sutter
On 13 January 2011 17:48, Dado Sutter <[hidden email]> wrote:
>> Well, ok, some explanation of tables when we first hit them. > > Yeah. And once they all (above) hear about Lua tables, they'll quickly > become great programmers ! :) ..or run away screaming.. ;) M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Jan 14, 2011 at 13:34, Martin Guy <[hidden email]> wrote:
:) :) Not if you don't tell them they are associative arrays, tuple sets, key-value pairs, ...., but a very simple plain text syntax to define incredibly complex things :) I think this is the main goal of your book idea; to leave the technical info sources for those who want/need them and to offer a simpler scenario for your target audience. I hope they run away screaming: Wow ! This is great ! I didn't have that in my old Arduino world ! :P
Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Sergio Sorrenti
On Fri, Jan 14, 2011 at 2:49 AM, Sergio Sorrenti
<[hidden email]> wrote: > 2011/1/10 Martin Guy <[hidden email]> >> >> Hi! >> We're writing a book for a tiny computer that runs eLua natively and >> want to sell it as a free gift included in a book which explains how >> to use it. > > one suggest i want to give for this eLua and Mizar32 book, > is to make it smart! > > with Webcams or Android Phone the users can easily > read the printed QR Codes(maximum 4.296 characters). > > We can also make use in combination URL shortner, > like goo.gl, for many benefict like the moving > of the text resource, easy coping on browser, > as well as to see how many peoples have access > to the piece of code/example, having some feedback > of the more preferred/liked and the disliked/unused. This is a great idea! QR codes w/ short urls below them could be placed in the text :-) Taking this into consideration it would also be a good idea to ensure that whatever is linked to is nicely readable on phone and tablet devices in addition to desktops. I'm not sure what shortener might be the most stable over time, but I would assume google's would be as stable as any over time. Heck, they even generate QR codes for you: http://goo.gl/info/GNwct > > A more tight paper/Web work, without to sacrifice > the reading in a sofa. > > Sergio > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Dado Sutter
On Fri, Jan 14, 2011 at 10:04 AM, Dado Sutter <[hidden email]> wrote:
> > > On Fri, Jan 14, 2011 at 13:34, Martin Guy <[hidden email]> wrote: >> >> On 13 January 2011 17:48, Dado Sutter <[hidden email]> wrote: >> >> Well, ok, some explanation of tables when we first hit them. >> > >> > Yeah. And once they all (above) hear about Lua tables, they'll quickly >> > become great programmers ! :) >> >> ..or run away screaming.. ;) > > :) :) > Not if you don't tell them they are associative arrays, tuple sets, > key-value pairs, ...., but a very simple plain text syntax to define > incredibly complex things :) > I think this is the main goal of your book idea; to leave the technical > info sources for those who want/need them and to offer a simpler scenario > for your target audience. > I hope they run away screaming: Wow ! This is great ! I didn't have that > in my old Arduino world ! :P I don't think tables are too bad. Associative arrays are a native datatype in quite a few languages: Perl, JavaScript, Python, Ruby, etc.. It might make sense to make one or two points about the merged array/dictionary nature, but I would focus on making use of them and describing in that context rather than pulling the reader aside for a lesson about all the ins and outs. There's plenty of documentation they can be referred to on that front. Of course, I don't know what the long-term plans are, but I suspect if feedback suggests that one thing or another should be covered in more detail in text, future revisions can always address that. > >> M > > Best > Dado > > >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by jbsnyder
On Fri, Jan 14, 2011 at 2:57 PM, James Snyder <[hidden email]> wrote:
Ugh, no. A readable "long" URL like, for example, to link to the snippet called ShortName in Chapter 3, http://www.simplemachines.it/mizar32/notes/3/ShortName or, even better, http://notes.mizar32.c0m/3/ShortName (Note that the .com version of this name is available! You should register it right away.) would be hugely preferable to becoming slaves to Google. If you're publishing a book, it might be better to get a domain name specifically for the book. This way, you can not only guarantee that the URLs are valid indefinitely, you avoid issues with Google changing their links, you can distribute an archive containing these notes, etc. etc. etc. Also, as long as you note the name of the snippet in the text somewhere, a reader without a smartphone that does QR codes can still find the snippet. I do see that the current URL for the board is the ugly and hard-to-type http://www.simplemachines.it/index.php?option=com_content&view=article&id=13&Itemid=24 but this isn't how all URLs look. eluaproject.net is much more attractive, readable, and memorable than http://goo.gl/info/GNwct. If you're really constrained by the length, build your own URL shortener at mizar32.c0m. -- Kevin Vermeer _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On 14 January 2011 21:36, Kevin Vermeer <[hidden email]> wrote:
> On Fri, Jan 14, 2011 at 2:57 PM, James Snyder <[hidden email]> wrote: >> http://goo.gl/info/GNwct > > Ugh, no. A readable "long" URL like, for example, to link to the snippet > called ShortName in Chapter 3, > http://www.simplemachines.it/mizar32/notes/3/ShortName > or, even better, > http://notes.mizar32.c0m/3/ShortName Agreed, both for the capital i / lower case L (as well as O/0/o issues) and for the name itself to have some kind of logical sense. Adding another layer of redirection is not useful unless we expect the target page to move around unpredictably. > I do see that the current URL for the board is the ugly and hard-to-type > http://www.simplemachines.it/index.php?option=com_content&view=article&id=13&Itemid=24 > but this isn't how all URLs look. Yes, the URLs of the CMS used to build simplemachines.it's website are not good. In email, I have to tell people to go to simplemachines.it -> Mizar32 rather than the "RESTful" form of "simplemachines.it/mizar32" How about making some short fake web pages on the home site, like "simplemachines.it/mizar32" which redirect to the appropriate page under the CMS? M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Jan 14, 2011 at 2:49 PM, Martin Guy <[hidden email]> wrote:
> On 14 January 2011 21:36, Kevin Vermeer <[hidden email]> wrote: >> On Fri, Jan 14, 2011 at 2:57 PM, James Snyder <[hidden email]> wrote: >>> http://goo.gl/info/GNwct >> >> Ugh, no. A readable "long" URL like, for example, to link to the snippet >> called ShortName in Chapter 3, >> http://www.simplemachines.it/mizar32/notes/3/ShortName >> or, even better, >> http://notes.mizar32.c0m/3/ShortName > > Agreed, both for the capital i / lower case L (as well as O/0/o issues) > and for the name itself to have some kind of logical sense. > Adding another layer of redirection is not useful unless we expect the > target page to move around unpredictably. Fair enough on depending on external URL shorteners, and they're being a bit ugly as urls. The redirection can however be useful if you wanted to condense the length of the URL beyond the main structure. So one could get to: http://www.simplemachines.it/mizar32/notes/3/ShortName by typing in: http://notes.mizar32.com/3/ShortName Or, you could make them even shorter than that: http://n.mizar32.com/3/shortname One point of consideration on the "typing on a smartphone" front, it might be nice if the urls wouldn't have any capitalization in them as well. After all this is yet another keystroke for each capital letter. > >> I do see that the current URL for the board is the ugly and hard-to-type >> http://www.simplemachines.it/index.php?option=com_content&view=article&id=13&Itemid=24 >> but this isn't how all URLs look. > > Yes, the URLs of the CMS used to build simplemachines.it's website are not good. > In email, I have to tell people to go to simplemachines.it -> Mizar32 > rather than the > "RESTful" form of "simplemachines.it/mizar32" > > How about making some short fake web pages on the home site, like > "simplemachines.it/mizar32" which redirect to the appropriate page > under the CMS? > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado, is it ok to use most of
http://wiki.eluaproject.net/Projects as the basis for one chapter of the book? Cheers M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Wed, Jan 26, 2011 at 14:34, Martin Guy <[hidden email]> wrote: Dado, is it ok to use most of Other than the fact that I always have the impression we could find unlimited time to better document the projects and refine their code, I think this is a great idea and I don't have anything against it. We may filter off some and also add some others targeting the Book. And also as a preview of what will be officially announced soon (upon v0.8 launching), pls note that I've migrated all the projects' repos to Github under the "organization" (their nomenclature) eLua. James Snyder wrote a MoinMoin macro that renders the source code directly from Github repos in the MoinMoin Wiki pages. I've updated all (or almost, it needs a revision...) the wiki pages to include it and it seems to be working very well (Thanks James !!!). For those not familiar with online version control systems (if there is still such species :), I've also added Download Links that bring ZIP files with the project's source code. The source code "box" on the wiki (MoinMoin) also allows one to mark and copy source code, to be pasted on users studies and test scripts. There is a (very small) link on the top of the boxes to hide the line numbers to help with this. Please let us know if something should be added to the projects specially for the Book. Best Dado Cheers _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi again
I've created a github project for this book at https://github.com/eLuaOnMizar32Book/eLuaOnMizar32Book and there's also a mailling list for discussion specific to the book, whose subscription/archive page is at http://groups.google.com/group/elua-on-mizar32-book and the email address for messages to this group is [hidden email] The admin owner of these sites is "[hidden email]" which redirects to me, for adding collaborators to the github project etc. I've shared its password with Sergio and Dado in case I finish under a bus. My first question, which I guess we should discuss there, not here, is "What copyright should we put on it?" Our model, the Lua Cookbook, is using CC-BY-3.0, which allows all use, including commercial. https://github.com/lua-cookbook/lua-cookbook/blob/master/COPYRIGHT M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |