Recent Updates RSS Hide threads | Keyboard Shortcuts

  • Should Fortran be taught to Undergraduates?

    jbsnyder 11:39 am on June 11, 2009 | 0 Permalink | Reply

    The following post has some very good thoughts about what languages to teach undergrads:

    Walking Randomly » Should Fortran be taught to Undergraduates?.

    Essentially he suggests starting with Python, NumPy & matplotlib which are both excellent and free.  He briefly mentions MATLAB in the post as well, but doesn’t say much about whether or not to use it.  I would suggest that people NOT use it, unless it specifically has some sort of built-in functionality that you need and can’t easily get elsewhere.  It’s a member of a class of tools that while quite easy to get started with and providing decent performance lock you into a closed toolchain which you either have to pay quite a bit of money for or lose the value of the tools you’ve built on top of it.  For basic numerical work, there’s not really much of an argument for needing to have MATLAB.  Python, NumPy & matplotlib are free, quite easy to work with, and expose you to the wonderful world of Python modules, where chances are someone has put together some quality groundwork for you to build upon for numerical work, networking, database, and a lot of other areas which are somewhat beyond the central expertise provided by tools like MATLAB.  Heck, you can even get support for it if you want to: Enthought.

     

  • LuaRPC Update Jun 6, 2009

    jbsnyder 3:42 pm on June 6, 2009 | 0 Permalink | Reply

    LuaRPC has grown a few additional features again.  We are now able to handle calling functions that are registered on tables and not just in the global environment.  This is crucial to be able to use modules where where functions are registered at something like modulename.function or modulename.subtable.function.  I’ve also stripped out some now unneeded code that did some remote error handling since the functionality it was used for was just adding an extra static buffer.  We also are now set up to be able to register additional commands that can be issued to the remote side beyond function calls.  Initially this will be used to provide methods to serialize data on the remote server and return this data locally, other functionality may follow.

    I also struck up a conversation on the Lua List about how one might go about treating a remote lua universe as just another table (do function calls, get data, handle metamethods, etc..), and there appear to be a number of problems in the way of doing all of that simply.  I think that the added command extensions will be used to add some sane portions of this functionality, and more complicated-to-implement functionality will be tabled until solutions can be found that aren’t miserably hackish.  If you’re interested in reading the exchange, you can find it here.

     

  • LuaRPC Update Jun 1, 2009

    jbsnyder 11:41 pm on June 1, 2009 | 1 Permalink | Reply

    I’ve got a few more issues to attend to before I’m going to put the LuaRPC code into the eLua trunk.  One thing that I’m thinking about that I’ve not yet come up with a satisfactory solution for is dealing with connection state.  The original code used sockets, and therefore the protocol makes some assumptions that, in most cases, data arrives in order with no errors, unless some exception is thrown.

    One advantage of all of this is that the code is reasonably simple and is minimal on CPU usage.  However, I think it’s a little too minimal to handle serial communications where a client might hangup or one simply gets a bad read, and there are only the TXD and RXD lines to indicate physical/data link state.  So far what I’ve done is padded out each buffered read & write (one or many bytes) with a header and tail byte (different) so that either the client or server can complain and jump back to waiting for fresh requests on error.  I may consider following HDLC a little more closely in terms of asynchronous framing, but this may be OK for now.

    It should be easy to layer checksums, addressing, retransmission or other assurances on top of this implementation by simply wrapping the functions that read and write chunks of data.

     

  • LuaRPC Update

    jbsnyder 2:00 pm on May 28, 2009 | 0 Permalink | Reply

    I’ve now both gotten it working on 5.1.4 and have abstracted out the transport layer.  As it stands which “transport” one uses is a compile-time option set by enabling or disabling some defines in config.h, but both serial (using pty to simulate real serial) and socket connections seem to be working at the moment for desktop use.  It’s still somewhat rough around the edges, and I’d like to be able to support multiple transports from a single compilation, but I’ve not decided how I might want to do that yet (multiple modules?  function pointers that allow switching within a single module file?).

    The existing module uses C-based exceptions to deal with transport-layer errors (take a look at luarpc_rpc.h if you’re interested).  I know we’re not really using exceptions for most of the eLua modules, but I’m wondering whether I should leave that in place, or change that in order to be friendly to porting.  As it is set up, it doesn’t have to derive from errno codes defined by system libraries (not sure whether Newlib provides an errno global), so if custom codes or strings are needed they can be set up.  I think, though, with the current flow, some exceptions will need to be thrown in order to enable connection resets when the client disappears, or if bad data is sent/received.

    Additionally, argument handling for connection setup that varies between transports is included in the “transport” side of the code, so the API to the transport layer includes a few functions that want a lua_State.  This feels a bit undesirable to me since some of them push stuff onto the stack depending on what args are given to them, and that number has to be passed back up the chain of called functions, since none of the transport layer functions are called directly from Lua.

    Also, beyond whatever was included in the original code, I’ve not done anything special security-wise to prevent clients from doing nasty things.  That said, if you were letting someone connect to a LuaRPC server, you were already letting them run arbitrary code on your server (unless you disable loadstring), so… :-)

    I think I’ll have an eLua serial backend going sometime in the near future, and I’ll certainly mention that when it’s ready to be abused.

     

  • RPC over {TCP/IP, Serial, Full Duplex FIFOs}

    jbsnyder 12:21 am on May 13, 2009 | 0 Permalink | Reply

    I’ve tinkered a bit further with Lua-RPC, but I’ve still not settled on how I’d like to deal with multiple lower level layers over which it can operate.  Inherently, it should be fairly simple because all the modalities mentioned in the title can be treated like files on UNIX/POSIX.  This means that once setup is complete, so long as no errors are encountered, all of these links should essentially look the same.  With error handling included, perhaps this can be somewhat simplified if we can look up error messages depending on which type of link is in use.

    The main point of interest, I think, is in allowing any one of these link types to be configured for the same library.  Perhaps the best way to handle this is to have a set of different handle creators (one per link layer), and each one of these takes parameters appropriate for configuration of that link, while leaving a handle that can be used by a common set of utility functions that read and write to the file descriptor set up when the handle was created.

    Currently there is one RPC_open function for opening client-side connections to a server.  If the namespacing were adjusted so that we have an rpc table, and function entries corresponding to different link types, our adjusted set of “open” functions could look like:

    h_sock = rpc.open_socket(address,port)
    h_ser = rpc.open_serial(serial_port, baud, etc..)
    h_fifo = rpc.open_fifo(file_path)

    I’m not sure if after setting up the file descriptor that when read() or write() are subsequently called that anything special need be done to ensure that those functions are the ones that know how to work with the link type that has been set up.  I would assume that at least for the serial and fifo situations, where an actual “file” exists to be read and written to that this isn’t too much of a problem, but for the socket there’s no file or fake file to represent the open socket.  Does POSIX/UNIX take care of this for you?  I suppose I’ll just have to check :-)

     

  • Lua-RPC

    jbsnyder 10:11 pm on May 11, 2009 | 0 Permalink | Reply

    I’ve been contributing to the eLua project since early this year, and have really enjoyed digging into some low-level details for implementing drivers and higher level functionality for an embedded dynamic language.  While many people would toss out the possibility of running a full distribution of a dynamic language (especially one typically used on desktops) on a microcontroller, Lua fits quite well.  You won’t be writing any extensive applications in an environment like this, but many small and medium-sized projects should fit pretty well within the resource limitations imposed by these devices, even with the overhead of a dynamic language.

    One thing that I’ve started working on recently is a resurrection of Lua-RPC, which is a simple client-server RPC library for Lua.  In general it seems to provide two main services:

    1. Calling remotely defined functions, and serializing the input and output values of these functions.
    2. Calling remote functions in a protected environment that allows errors to be returned to the client that made the call in the first place.

    With a set of minor adjustments in place to account for changes between the Lua 4.x and 5.1.x API, it now seems to work fairly well as a module in a current version of Lua, handling remote procedure calls over sockets.  It also now works as a loadable module, so one can use it within scripts or at the Lua REPL.

    Now that a basic port has been made, the next step I’m working on is getting it up and running over not just sockets but other link types, like serial.  The concept of socket use is pretty well embedded in the design of Lua-RPC, but there’s enough abstraction that it isn’t necessary to rewrite much of the Lua-facing side of the code (those C functions that are registered with Lua), mostly what is needed is establishment of some sort of common interface that will work for not just socket communications, but much less feature-laden link types like RS-232.  I think I have a general path laid out for this, and will likely make some comments as this process goes along.

    For those interested in the code, you can check out the GitHub project here (no guarantees about any particular commit working well until a release is made, which will be after the link-layer abstraction is working).

     

  • Pipe Mac OS X Audio to a Linux Box

    jbsnyder 11:19 am on May 4, 2009 | 0 Permalink | Reply

    Instructions on how to use Soundflower & esound to pipe all the audio output on your Mac to a Linux box (and the other direction if you want): http://rolf.haynberg.de/?p=14

    Latency is about 500ms, which could be better, but it’s an improvement over what I’ve gotten with Airfoil.

     

  • ARM EABI Toolchain

    jbsnyder 6:38 pm on April 16, 2009 | 0 Permalink | Reply

    I’ve put up some instructions on how to build an ARM EABI toolchain on Mac OS X machines using CodeSourcery’s versions of GCC, GDB, Newlib & binutils.

    Hope they’re helpful to someone who hasn’t been able to get a toolchain going on their Mac.

     

  • Interview on FLOSS Weekly With Massimo Banzi of Arduino

    jbsnyder 7:22 pm on March 21, 2009 | 2 Permalink

    “Massimo Banzi is the co-founder of Arduino with partners David Cuartielles, Gianluca Martino, Tom Igoe, and David Mellis. Banzi is the CTO of Tinker.it!. He has worked in Milan and London on projects for companies such as Prada, Artemide, and Adidas. For four years he functioned as an associate professor at the Interaction Design Institute Ivera. Beyond his private endeavors, he has been a guest speaker and teacher of workshops throughout Europe.”

    FLOSS Weekly No. 61

     

  • Arduino + Python

    jbsnyder 10:51 am on March 19, 2009 | 0 Permalink

    Here’s a talk I did at the Chicago Python Users’ Group (ChiPy) back in February. It starts a little ways in, and there’s a section where the video hangs, but it’s mostly there:

    Special thanks to Carl for doing captures and posting the ChiPy talks on blip.tv.

    Here are also some notes that got sent out after the talk to the ChiPy list:

    Main Arduino Project Page:
    http://www.arduino.cc/

    Arduino Playground (lots of hardware/software examples):
    http://www.arduino.cc/playground/

    Firmata:
    http://www.firmata.org/wiki/Main_Page
    http://arduino.cc/en/Reference/Firmata

    Pyduino:
    http://code.google.com/p/pyduino/

    Places to Get Kits and Hardware:
    http://www.adafruit.com/
    http://www.sparkfun.com/
    http://liquidware.com/ (I’ve not bought anything from them personally, but they have some interesting Arduino compatible boards)

    Also if you’re interested in some of the code used during the talk, I’ve posted some of the demos I did at the end up on github:
    http://github.com/jsnyder/jbsnyder_tools/tree/master

    You’ll probably need to install a few modules to make them work including wx, multiprocessing, matplotlib and numpy (in addition to pyduino from above).

    The mouse demo also uses a little Objective C program to move the mouse around, compile instructions for that are in the movemouse.m file.

     

Older Posts →

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
esc
cancel