I understand your comment about re-using SDL on larger platforms. The discussion in the annual report of using executable specifications to implement TCP/IP etc was intriguing. In tiny but able systems, it may be useful. Skimming the results of Picobit ( http://www.ccs.neu.edu/home/stamourv/papers/picobit.pdf), a hand-rolled stack S3 was 3.1kB of bytecodes vs 10kB of machine code for uIP, implying the benefits of using higher level languages on tiny platforms with potentially no or miniscule OS support. Using executable specifications may yield even more impressive results. And understandable systems, as Iliya noted.
David On Mon, Aug 5, 2013 at 6:44 PM, Ian Piumarta <[email protected]> wrote: > Iliya, > > Norman summarised things well. > > FYI, the version of Maru in the Nile repository is usually a clone of: > http://piumarta.com/hg/maru > > The various 'lib*.k' files in there show one approach for dealing with > bindings to external libraries using Maru's simplistic built-in foreign > function mechanism. Adding bindings for the most commonly-used parts of > X11 or SDL could be done with little work by following the same pattern. > Most of the work would be enumerating (or generating) the accessors for > event structures. > > Keyboard events seldom exist in isolation. Your choice of output medium > might suggest the most convenient library or OS interface for key events. > Applications outputting to X11, Quartz, DirectX, or SDL have keyboard > events handed to them by the framework. A console application writing to > stdout could put the terminal into raw mode to receive key presses as they > happen. On Linux, if you are writing pixels to /dev/fb then you can use > ioctl()s on /dev/console or /dev/tty to synthesise down and up events > containing raw keyboard scancodes. In your own replacement kernel on XO > hardware you might leave OpenFirmware active after you've booted and call > its low-level drivers to receive keyboard input (which, I think, is what > NetBSD did for many years). UEFI might be able to provide similar > "drivers" for you. At least one BIOS manufacturer (Phoenix, IIRC) has a > web browser that runs directly on the BIOS, with no OS needed, and if you > want to create a few bindings to Qt that might be a pl > atform for applications packaged as browser plugins when they depend only > on keyboard, mouse, framebuffer and network. > > In a perfect world it would be easy to deal with any hardware directly. > In the real world overwhelming complexity and/or proprietary interfaces > often prevent that. A compromise between perfection and pragmatism has to > be made. Running on top of third-party firmware, drivers, OS services or > framework libraries is the pragmatic way to make progress on things you are > more interested in. That said, you should feel good about running your > system on lower levels within that hierarchy because you are closer to the > hardware and eliminating bloat while gaining control. You should also feel > good about running on higher levels of that hierarchy because you are > reusing rather than reinventing and gaining potential for platform > independence. > > FWIW as I get older I get lazier and less idealistic and more pragmatic > and would be tempted to start any new CHI project using SDL, for portable > access to both a framebuffer and OpenGL as well as audio and several input > devices. (At least until something better and integrated with libnile is > bundled on Windows-X, Mac OS Y and Ubuntu Zealous Zebra. :^) > > Hope some of that was useful. > > Regards, > Ian > > On Aug 5, 2013, at 03:15 , Iliya Georgiev wrote: > > > Hello, > > > > I am using version 2.4 of Maru programming language [1]. It has a lot of > functionality and with code length less than 100 pages in format A4, it is > like a textbook for programming. Does anyone experiment to add > functionality to Maru for dealing with keyboard events? I mean to get > information when a key is pressed and released. Other Lisp implementations > use external libraries [2, 3]. I suppose this topic will be addressed as > pointed in the STEPS Report 2011 [4]. The report suggests a complete system > that may replace the linux kernel and it has to deal with keyboard events. > But anyway, I am interested to write such an extension to Maru. > Unfortunately my research suggests that implementing this in Maru is not > possible without using external library. I will be glad if you can give me > some directions. > > > > Regards, > > > > Iliya Georgiev > > > > References: > > 1. Maru code repository - http://piumarta.com/software/maru/maru-2.4/ > > 2. Lisp SDL bindings - > http://code.google.com/p/lispbuilder/wiki/UsingLispbuilderSDL#Keyboard_Events > > 3. Lisp implementation of X Window System client - > http://common-lisp.net/project/cmucl/doc/clx/12_1_Introductions.html > > 4. STEPS Report 2011 - http://www.vpri.org/pdf/tr2011004_steps11.pdf > > > > _______________________________________________ > > fonc mailing list > > [email protected] > > http://vpri.org/mailman/listinfo/fonc > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
