Posted by Scott Hughes
Fri, 17 Mar 2006 00:51:00 GMT
Since posting my OneWireViewer App+Source for Mac OS X last August, I still see fairly regular downloads of it in my stats. I also still see lots of hits from google searches for “1-wire” and “mac osx”. I thought I’d let any interested parties know that we are gearing up to release our 1-Wire Public Domain Kit (C code) very soon (likely this month). I put in some effort for this release to create a specific Serial (DS9097U) and USB (DS2490/DS9490) build for Mac OS X. The release will include full source and a build file, as well as pre-built Universal Binaries of all of the example apps. Those without much programming knowledge looking to integrate 1-Wire into bigger systems should appreciate that.
Learning how to build the Universal Binaries was a bit of a chore, but once you get the hang of it it’s fairly simple. The biggest complication was building a Universal Binary for libUSB and since I wanted my libUSB-dependent app to be Universal, I had to jump through hoops to get it to work. I was able to get 0.1.12 to build an Intel library just fine on my Intel Mac (though <= 0.1.11 didn’t work for me, so mind your sources). I couldn’t get it to build the Universal binary due to it’s use of ‘ar’ and ‘ranlib’ (which, according to this tech note from Apple does bad things to Universals). I’m not a configure or makefile whiz and I got a little stumped on the parts of the makefile where gcc was being used to generate new makefiles dynamically (wasn’t aware of this feature before). Apparently when using -MT (to generate new makefile rules) you can’t pass multiple architectures along with your compile command (i.e. “-arch i386 -arch ppc”). I ended up doing things the hard way and just compiling the PPC binary on a PPC mac, and then merging the two with lipo (i.e. “lipo -create -output uni.lib ppc.lib intel.lib”). After all that, I discovered a nice pkg installer for a Universal libUSB that someone else was nice enough to pre-build and distribute for us. I recommend this installer for the easiest path to a Universal binary of libUSB.
My next task is to recompile my Java-to-libUSB-to-1-Wire solution (for OneWireViewer and the rest of the examples in the 1-Wire API for Java) as a Universal Binary. I also need to put a little effort into making it work with libUSB on Linux, so I can update the “live” WebStart version of OneWireViewer with virtually out-of-the-box support for every platofrm. The 1-Wire API for Java was scheduled for release this quarter (ending in 2 weeks), so I hope to have all this done in time to ship out the door with the release.
Posted in 1-Wire, Code | Tags 1-Wire, iButton, MacOSX | 7 comments
Posted by Scott Hughes
Mon, 28 Nov 2005 19:50:00 GMT
My old friend P.O. Boykin recently took a look at Ruby (and other scripting languages) and came up with a very interesting post: Performance of Programming Languages
After spending time with so called “scripting languages” (a term that I feel is not a terribly well defined or useful), I have found that I enjoy programming in languages like Ruby, Python, and Boo more than languages like C, C++, Java, or C# (though C# is getting better and better as they improve the language). My question is: how much performance do I loose by adopting one these laguages. To answer this question I took a look at the Language Shootout site.
I hadn’t heard of the Language Shootout site; that’s a very interesting link. They compare the implementations of your favorite programming languages (and are very careful not to say they compare the actual language, just the implementation) and produce a whole lot of “at-a-glance” graphs.
I’m a very recent fan(atic) of Ruby. I still don’t “think” in Ruby, just because I don’t have enough trench time with it. But I subscribe to the Google group RSS feed for comp.lang.ruby, and it’s very common to find code snippets (usually in response to a question) that just make me smile. Since more than half of the work I do at my job is using a PC to communicate with a significantly slower device (parallel FPGA, usb or serial Micro, or a 1-Wire device), I try to sneak scripting solutions in wherever I can. If the PC takes 100x more cpu time to compute a message that is going to be put on a slow bus (several orders of magnitude slower than the cpu) noone is going to notice the loss of a few extra nanoseconds. That said, I usually need to hand code off to other people (those so-called “paying customers”) and using a more popular programming language (C or Java) makes that hand-off much easier.
But for some of my tasks, Ruby’s elegance outweighs any of the performance penalties. Ruby is still fairly young, so I’m hoping that in the near future it will reach a good level of general acceptance and gain some significant performance improvements (thanks to all the eyes it now has on it). Also, I think it’d be interesting to run the same benchmarks the Language Shootout guys did, but using either YARV [1] or RB2C [2]. Seems that if those projects don’t do better than vanilla Python, they should re-think their solution. It’d be nice to see if they are able to tighten the large margins between the Java or .NET runtime.
[1] YARV: Yet Another Ruby VM - http://www.atdot.net/yarv/
[2] RB2C : a Ruby to C converter http://www-lab09.kuee.kyoto-u.ac.jp/~hiwada/ruby/rb2c/
Posted in Code | Tags benchmark, Code, ruby | 4 comments
Posted by Scott Hughes
Tue, 08 Nov 2005 14:34:00 GMT
Last night, I updated this Typo install to the latest svn trunk (rev 725). I had been running at rev 586 for a while now, but I was hesitant to upgrade as I noticed there were a few database changes. Turns out that, thanks to Rails Migrations, the database changes were simple (for me anyways, maybe not for the author of the migrations). While I was at it, I went ahead and updated Typo to run the latest Edge Rails also. Here’s the procedure I used on Dreamhost to install these:
# Get Latest Typo
$ svn co svn://leetsoft.com/typo/trunk typo-edge
# Get Latest Rails
$ cd typo-edge/vendor
$ svn co http://dev.rubyonrails.org/svn/rails/trunk rails
$ cd ..
$ rake update_javascripts
$ rake add_new_scripts
# Copy My Typo Configuration
$ cp ../{old-typo}/config/database.yml config/database.yml
$ cp -r ../{old-typo}/themes/globalreset themes/globalreset
$ vi config/environment.rb #forced RAILS_ENV='production'
# Update link I use to point to a version of Typo
# My setup expects web root at this link/public
$ rm typo
$ ln -s typo-edge typo
Then I opened my browser and navigated to /admin and was immediately prompted with a list of necessary Database Migrations, which must be performed on my existing database to be compatible with this version of Typo. I clicked affirmatively, and after a few seconds I was running the latest and greatest Rails and Typo.
Make sure you backup your database before attempting this. The web-based phpMyAdmin that Dreamhost provides is suitable for this. I’ve seen a couple of users report on the Typo-ML that they had some migration issues. I don’t know if those issues ended up in a wedged database or not, but better safe than sorry.
Posted in Code | Tags Rails, ruby, RubyOnRails, Typo | 4 comments
Posted by Scott Hughes
Sun, 06 Nov 2005 06:06:00 GMT
I’ve finally gotten around to creating a source tarball for the work I did to get the Public Domain Kit support files for libUSB running under the 1-Wire API for Java. 80% of the work here was figuring out what to do, so you’ll find there isn’t a lot of code to glue them together. It would be pretty easy, for example, to swap out the PDK files for libUSB with the DS1410E link-level files for Linux. Then you could have parallel port support using the 1-Wire API for Java under Linux as well as the USB port.
The Makefile is geared towards Mac OSX. Everything else, including the C source in the ‘native’ folder, is platform independent and should compile everywhere libUSB does. Using Sun’s reference on how to build JNI libraries for the various platforms, you should be able to modify the Makefile to support your platform. If you have any suggestions for improving the build process, especially if you can help make it a cross-platform Makefile, then please let me know.
PDKAdapterUSB.tar.gz (444kb)
Posted in Code, 1-Wire | Tags 1-Wire, Code, DS2490, Java, usb | 1 comment
Posted by Scott Hughes
Sat, 15 Oct 2005 00:13:00 GMT
RubyConf 2005 is underway and I’m hoping that the slides from the presentations will be available soon. I found that Kevin Clark is live-blogging RubyConf and is doing a pretty good job of it (Thanks, Kevin!).
His notes from the progress report on YARV: Yet Another Ruby VM are an especially interesting read. Maybe YARV will finally help answer the question, “Does RubyOnRails Scale?”
Thanks to Ezra Zygmuntowicz, you can start listening in on some presentations as well.
Update: Matz’s slides from his keynote speech on the future of Ruby are now available online. He talks about a lot of cool ideas that are going to keep Ruby 2.0 very fun. There’s even a video(198mb).
Posted in Code, Technology | Tags Code, ruby, rubyconf | no comments
Posted by Scott Hughes
Thu, 22 Sep 2005 16:33:00 GMT
I happened upon this amazing story (via Wired). The incredible Graphing Calculator application, which is included with Macintosh computers, was actually a clandestine, rogue project at Apple. A contractor, whose project was cancelled, continued to sneak into the building and work on the application.
I asked my friend Greg Robbins to help me. His contract in another division at Apple had just ended, so he told his manager that he would start reporting to me. She didn’t ask who I was and let him keep his office and badge. In turn, I told people that I was reporting to him. Since that left no managers in the loop, we had no meetings and could be extremely productive. We worked twelve hours a day, seven days a week.
Thanks to all his hard work, Graphing Calculator was bundled in with the OS and was initially shipped on more than 20 million machines. That’s a pretty good sized audience.
When we had a test Mac at my first co-op job, I wasted a few hours playing around with Graphing Calculator. It was almost enough to make me ‘switch’ back then… Though, college students who are paying their own way through college have a hard time affording a Mac (until the Mac Mini anyways). Wondering why he didn’t ship a version of it with Windows?
We wanted to release a Windows version as part of Windows 98, but sadly, Microsoft has effective building security.
Posted in Code | Tags Code, programming, skunkworks | no comments
Posted by Scott Hughes
Sun, 11 Sep 2005 18:57:00 GMT
I’ve been working on my own RubyOnRails app for the past week: Freeloader. The idea is sort of like Delicious Library, except it’s web-based and it’s a form of folksonomy. Like Delicious Library, Freeloader will allow you to create a library of all the movies you own and it will track who you’ve lent those movies too and whether or not those movies are overdue. Unlike Delicious Library, friends who you’ve designated as contacts can browse your collection online and request to borrow any movie(s) they see of interest. Registered users can help ‘tag’ movies and rate/review movies or other users. i.e. “I recommend this movie if you like such and such” or “Scott sucks, he never returns my stuff on time”.
My immediate goal is to create a very narrow folksonomy, as in a private install with a private group of friends. The project is open and (much like Typo) your free to install your own version of it to help coordinate your circle of movie-borrowing friends.
I do have a test site setup that anyone can try out. I will nuke the database periodically, so don’t spend much time inputting your library. Right now, the only features that work are registering a new user, searching/adding new movies, adding any existing movie to your own collection, viewing your collection, viewing the collection of any user, and adding/removing ‘friends’. When I’m ready to start using the project regularly, the test site will become ‘invite-only’, though anyone is still free to browse the collections.
Freeloader Demo
If you want to try out the code for yourself, you can browse the source and see other project details at the Trac wiki and svn repository.
Freeloader - Trac
Freeloader - anonymous SVN
If you’d like to contribute anything to the project or need help installing what’s currently there, let me know.
Update - if the test site doesn’t seem to work (i.e. you get an Application Error), just hit refresh a couple of times. For some reason, my fcgi processes are having trouble staying alive on Dreamhost tonight.
Posted in Code, Movies, Technology | Tags RubyOnRails | no comments
Posted by Scott Hughes
Fri, 26 Aug 2005 13:25:00 GMT
Thanks to Ted Neward, I just read about this interesting new Java Specification Request: JSR 277
The specification of the Java Module System should define an infrastructure that addresses the above issues. Its components are likely to include:
- A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources. The metadata would contain information about a module, the resources within the module, and its dependencies upon other modules. The metadata would also include an export list to restrict resources from being exposed outside the module unintentionally. The metadata may allow subset of exposed resources to be used by other modules selectively.
- A versioning scheme that defines how a module declares its own version as well its versioned dependencies upon other modules.
- A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support.
- Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules.
- A set of support tools, including packaging tools as well as repository tools to support module installation and removal.
We also expect the Java Module System to expose the public J2SE APIs as a virtual module in order to prevent unwanted usage of the private APIs in the implementation.
Modules with metadata about their dependencies sounds like just what the doctor ordered. It’s crazy that Java has such a large and pro-active userbase, yet it is so slow in catching up to the fledgling .NET. Item #1 and #2 should’ve been implemented a long time ago, and Sun knows it. I agree with Ted as well when he says:
About the only thing I *wish* we could do that’s out-of-scope to the JSR is to fix the javac compiler to cease emitting .class files directly, but instead consider .class files to be the moral equivalent of C/C++-compiled .obj files, and automagically do that final step and turn it into a .jar file right out of the box. (Out of curiosity, is there anybody out there who doesn’t immediately jar up your .class files?)
I know I immediately jar mine up, except in the cases where I’m prototyping with a single .class. If Javac auto-jarred, that wouldn’t bother me in that case.
Posted in Technology, Code | Tags Code, Java | no comments
Posted by Scott Hughes
Sat, 20 Aug 2005 23:44:00 GMT
Always one to chase after the shiny new technology, I’ve moved my blog over to Typo from Wordpress. Typo is a recent blogging engine developed using the latest buzzworthy web framework Ruby on Rails. I’ve been meaning to experiment with Ruby on Rails for a while now, and I guess Typo is a good start. One of the first differences you’ll notice is that Typo is AJAX-ified with a handy “Live Search” dialog over there on the right-hand side. This provides a pretty nifty instant search interface, with a transparent round-trip to the server. So you get something that looks somewhat like a local application, much like most of GMail’s functionality. Getting Typo running on Dreamhost wasn’t nearly as straightforward as Wordpress. Here’s the steps I followed:
- Used Subversion to do a checkout on my local Mac of the latest Typo source (svn co svn://leetsoft.com/typo/trunk trunk).
- Used the Dreamhost Web Panel to add the IP address of my local Mac to the allowed IP addresses that can access my mysql database.
- Used CocoaMySQL to make a dump of my existing database (in case I screwed anything up) using the Export->”CocoaMySQL Dump” menu option.
- Used CocoaMySQL to import the schema required for Typo (I imported it into the same database as my Wordpress install) using the Import->”CocoaMySQL Dump” menu option and selecting the db/schemas.mysql.sql file.
- I used Cyberduck to ftp the Typo files into mywebsite/typo folder.
- Made some necessary files executable (chmod +x script/* public/*).
- Browsed to http://mywebsite/typo/public to configure the installation.
- Ran db/converters/wordpress.rb to import my Wordpress database into Typo.
- Made a backup of the Wordress blog php files (moved /blog to /blog2).
- Used the Dreamhost Web Panel to make a new subdomain (blog.globalreset.org).
- Moved the Typo installation into the subfolder for blog.globalreset.org.
- Remapped the domain to point to blog.globalreset.org/typo/public as the root folder for the website.
I fought for a while with getting Typo to work under my /blog subfolder of my domain, but it didn’t like it. I followed on the directions on the Rails wiki and in the Dreamhost forum, but couldn’t get it to grok the urls. I gave up and just went with a new subdomain, which Rails apps seem to like.
Also, I couldn’t find any themes I liked for Typo yet, so I started mucking with the default one. I’m not terribly happy with what I’ve ended up with here, but it’ll do for now.
Technorati Tags: RubyOnRails, Typo
Posted in Code, Technology | Tags CocoaMySQL, Dreamhost, RubyOnRails, Typo | no comments
Posted by shughes
Tue, 05 Jul 2005 03:10:00 GMT
Take a look at this screen capture to see how I spent my 4th of July vacation weekend.
I ended up taking the libusb build of the 1-Wire Public Domain Kit and creating a JNI-wrapper around it. Now I’ve got a nice USB Adapter driver for the Java API (and hence for OneWireViewer). I’m going to look into modifying the WebStart download so that it will deliver the new USB adapter and the binary (JNI) portion of it. Possibly, I can sneak the libusb drivers along with that as well, without causing too much confusion. Maybe make 2 builds, one that includes libusb for people who aren’t cmd-line savvy enough to build their own and one that doesn’t.
The good news is that this should work on Linux, Mac OSX, and Windows. Windows users will have to install a .inf file first, but it will be a single-click application for Linux and Mac.
Update (7/10/2005): I used JarBundler to create a nice .App bundle of this for Mac OS X users. It’s pretty nice to have a installable .App of OneWireViewer that supports both the USB Adapter (DS9490) and the Serial Adapter (DS9097U) on Mac OS X. Unfortunately, I don’t have a good place to host it.. I’m not sure in it’s current form if it’s suitable for an official release to go up on the dalsemi ftp servers. So, if you’d like to try it, just leave a comment and include your email address (not in the comment, but in the regular email address field, where I will be able to see it but noone else will) and I can email you a copy of the app. It’s 2.3mb compressed.
Posted in 1-Wire, OSX, Code | Tags 1-Wire, iButton, MacOSX | 9 comments
Posted by shughes
Mon, 06 Jun 2005 15:56:00 GMT
I’ve finally hit a pretty big roadblock in my switch over to the Mac. I am having trouble getting a good set of tools to help me offload video from my TiVo. I’ve been back and forth on this since I bought the TiVo, where I’d go from constantly downloading video for archiving to not really thinking about it at all. Since I picked up the PSP, one of my goals has been to get a nice workflow going to grab episodes of shows that Nicole won’t watch with me (X-Play, Smallville, and Deep Space 9) and take them along with me. Unfortunately, Dell has been delaying my order for a 1GB memory stick pro duo, so using the PSP as my mobile video player is still bottlenecked by the storage problem. I’d like to cancel my order from Dell and just grab it from Amazon (1 GB Memory Stick Pro Duo) for a few dollars more, but why bother if I can’t get the tools in place to make it convenient on the Mac? This makes me a very sad man…
Here’s what I’ve tried so far…
TiVo-mplayer Had pretty good success with this on the PC, though I had a lot of audio-sync problems. Given that it’s at 1 version number greater than what I last tried on the PC, they may have fixed it (though I’m not too hopeful). In any case, I always had to correct an error in one of the .c files (variable declared in the middle of a function, rather than at the top of a scope) just to get it to compile on Windows. On the Mac, I gave up after correctly nearly a dozen compile errors. If anyone would like to provide a binary of this for Mac OSX 10.4.1, I’d sure like to give it a shot.
MPlayer / MPlayerOSX / ffmpegX Unfortunately, none of these incorporated the above changes to support TiVo’s .ty files. So, they are mostly useless for my purposes. However, if I could get my hands on a TiVo-mplayer binary, ffmpegX would still function as a front-end for that command-line tool. (Update 6/9/2005) I discovered that the mencoder portion of the ffmegX binaries does include the demux code for ty files. I also discovered that, just like the last time I used mencoder on the PC to transcode, I still get major audio sync problems. I assume if I just demux the video and use another tool to remux it (with some manual adjustments to audio sync) it will work fine… But that’s too much work. I’m spoiled by the easy TyTool for Windows. Unfortunately for me, he won’t share the source for it so we can try to port it to OSX.
TyStudio These guys have built, what looks like, a fantastic tool. Unfortunately, it has never worked for me. They have an OSX version (requires X11 be installed) and it seems to function nicely once you get ”dlcompat” installed. I couldn’t get Fink or DarwinPorts to install dlcompat for me, so I ended up just checking it out of CVS and building from source. Seems the easiest way to get the libs in the right folder so that TyStudio can see them anyways. Once I got this tool running, I selected a local “.ty” file I had sitting around. Amazingly, this tool performs on Mac OSX exactly as it performed on the PC… That is to say, it got exactly halfway through indexing the .ty file before crashing heinously. I believe it might be because my .ty files came from a series 2 TiVo, because their website only has info about a series 1 server component.
From here, I’m kind of at a loss. I guess my options are: 1) forget about getting video on the PSP memory stick and just buy UMD movies to keep myself entertained, 2) use the PC for video extraction/editing since I already have a good toolset to use, 3) “get cracking” on porting the other PC tools over to the Mac.
Aside: Whenever I have to code up my own solution instead of waiting on someone else to provide me with one, I love using the phrase “get cracking.” It comes from an email conversation a buddy of mine had at Ga Tech. He was using a system tray CD-player app, but he felt it was missing a feature or two. He emailed the author of the app to let him know what was missing, and the author gave him the succint reply: “Get cracking!” :)
Technorati Tags: Apple, MacOSX, TiVo
Posted in TiVo, OSX, Code | no comments
Posted by shughes
Sun, 29 May 2005 23:51:58 GMT
For my own benefit (and maybe yours), I’d like to try an collect all the info available for getting 1-Wire apps running on Mac OSX Tiger (10.4). Eventually, I’d like to see a Cocoa application that functions much like OneWireViewer. That’ll be my next fun project, after I complete my “Learning Cocoa and Objective-C” project.
Technorati Tags: 1-Wire, Apple, iButton, MacOSX
Public Domain Kit Applications
The public domain kit includes 2 relevant builds: ulinuxgnu and libusblinux. Though both of these builds have “linux” in the title, ulinuxgnu should really be called uPosixSerial. Libusblinux should just be called the libusb build, as it will work on any libusb platform. I tested with version 3.00 of the Public Domain Kit and got both builds to work perfectly on a near clean installation of Mac OSX 10.4. Both of these builds required the optional XCode install that came with Mac OSX, so that your system will have the GNU C Compiler (gcc) available.
For serial port access, I used a Keyspan serial-to-USB adapter, part number USA-19HS. The drivers included with the adapter worked fine, though you might check Keyspan’s website for the latest drivers. After installing the drivers, I plugged in the serial adapter and used Keyspan’s installed Serial Assistant application to find out the device name of the adapter. In my case, it was USA19H5b14P1. The next step is to connect a DS9097U serial adapter to the Kespan serial-to-USB adapter. Now you can optionally attach a probe or Blue-Dot receptor to the DS9097U and attach any 1-Wire or iButton devices you may have. Otherwise, the only 1-Wire device we are going to see is the 64-bit ID chip embedded in the DS9097U.
For USB access, I used the DS9490R USB adapter and a Blue-Dot receptor. To allow the Public Domain Kit to have access to a USB device, we need a user-land (as opposed to kernel-land) USB driver. That is what libusb provides for us. The easiest way to get libusb is to first install Fink. Fink is a smart package management app that makes it easy to install open-source software on Mac OSX. Soon, a binary installation of Fink will be available for OSX 10.4 users. For now though, follow the “bootstrap” instructions on Fink’s homepage. After fink is installed, type: “fink install libusb” in the terminal. You now have the libUSB drivers installed.
The Public Domain Kit serial and USB builds worked almost “out-of-the-box”. In version 3.00, the ownet.h file optionally defines some types based on platform. Mac OSX isn’t one of the platforms that ownet.h knows how to handle. The next release of the Public Domain Kit will fix this, but for now, I modified the block around “#define OW_UCHAR” to look like the following:
#ifndef OW_UCHAR
#define OW_UCHAR
typedef unsigned char uchar;
typedef unsigned long ulong;
#include <sys/types.h>
#endif
Now, running “make linux” will build all of the Public Domain Kit serial apps. We have to make one more adjustment for the USB build to work. Essentially, Fink “sandboxes” all of the apps and libs that it installs, to keep it from conflicting with other apps that the user may have installed without Fink’s help. So, you’ll need to point the makefile to Fink’s copy of the libusb library files. At the top of the makefile, you’ll find a definition for compiler flags and linker flags, labeled CFLAGS and LFLAGS respectively. Modify them to look like the following:
CFLAGS = -DDEBUG -c -I/sw/include
LFLAGS = -DDEBUG -g -o $@ -L/sw/lib
You are now ready to run “make linux” to build both the serial build and the USB build. In the directory where you built the serial build, type “./tstfind /dev/tty.USA19H5b14P1.1” with you’re serial adapter device name (not mine, USA19H5b14P1). This should give you a scrolling list of all the 1-Wire devices connected to your adapter. To run the same app in the USB build, in the directory where you build the usb build, type “./tstfind DS2490-1” where the number after the dash simply selects which DS9490R or DS9490B adapter you wish to select if you have more than one. To exit both of these applications, type “Ctrl-C”.
1-Wire API for Java Applications
The 1-Wire API for Java is currently waiting for a good RXTX build, version 2.1.7pre19 or later. After installing the RXTX_Jag.pkg included in the current snapshot, I had to edit /etc/groups file to manually add my username to the “uucp” group. I believe the install script should have handled this, but it appears that it didn’t. This got me past a “PortInUseExcpetion”, but now I’m stuck with a “Bus Error”. I believe this is due to a memory management issue in the native layer that is fixed in 2.1-7pre19.
Web-based 1-Wire Applications
A part of the owfs project, owhttpd is a webserver application which allows one to interact with 1-Wire devices. Unfortunately, the owfs app does not itself work on Mac OSX because of the lack of FUSE support. However, owhttpd should work. To set up owhttpd, I first downloaded the “Source only” package for owfs 2.1.0. Then ran, “./configure” and “make”. Configure failed for me when it starting configuring the swig module. I tried to ignore this and cd’ed into the module/owhttpd folder and ran “make” from there. No dice. Looks like the configure script is broken. Hopefully it gets fixed soon as owhttpd looks like a handy application.
Posted in Code, OSX, 1-Wire | 1 comment
Posted by shughes
Fri, 27 May 2005 03:42:31 GMT
On the very successful front, I have had some luck getting 1-Wire apps to build and run on Mac OSX. I tried for far too long to get rxtx working, so that I could run OneWireViewer. That still fails, but I think it’s for an old reason. I had been having problems with rxtx on Win32 and Linux, but they are fixed in the CVS head revision… Unfortunately, I can’t build the CVS head revision for the Mac yet.
Eventually, I gave up on rxtx/Java and turned to our 1-Wire Public Domain Kit. The ulinuxgnu build (which maybe should be renamed the “posix_serial” build), built and ran perfectly. Using a keyspan USB-to-serial adapter and a DS9097U serial-to-1-Wire adapter, I had 1-Wire connectivity! The only modification I had to make was to the ownet.h file, where it was defining certain data types based on platform (and this platform wasn’t one of the ones it knew about).
I also got the libUSB build to compile, though it threw a lot of ugly warnings. I had to first ask the very cool Fink to “install libUSB.” Unfortunately, I am without a USB-to-1-Wire adapter at home, so I was not able to test if it’s actually going to work. :( But I have every confidence that it’ll work or, if it doesn’t, I’ll get it working.
Technorati Tags: 1-Wire, MacOSX
Posted in Code, OSX, 1-Wire | 2 comments
Posted by shughes
Thu, 26 May 2005 15:24:18 GMT
I have to make a correction to my previous post. I said that application developers get “easy” access to basically add Spotlight search capabilities “for free”.
“Easy” and “for free” did not take into account the energy said developer would have to expend to learn Cocoa (Apple’s version of Microsoft MFC). As odd as MFC was in terms of some of the design choices, at least it’s back-end was in the very popular C++. Apple’s code-behind is Objective-C.
My GUI development (which, btw, has always been terrible as I really have only an Engineer’s eye) has moved beyond the Cocoa/MFC style, where I actually prefer to create my UI at runtime (changing it up as appropriate). I’m referring to Java Swing style or the newer Microsoft .NET visual designers. I use a visual designer to get a grasp of the initial layout, and then use code to manipulate the layout based on runtime properties. This could explain why my GUI’s always look like crap. :)
If anyone knows of any good references on Cocoa (from a .NET/Java user’s perspective), I’d appreciate it. Although there are wrapper interfaces available from .NET and Java, you still have to understand Cocoa before you can use these and you still have to use XCode/InterfaceBuilder to layout your GUI (and all of it’s events/actions) ahead of time.
Technorati Tags: Apple, MacMini, MacOSX
Posted in Code, Personal, OSX | no comments
Posted by shughes
Mon, 23 May 2005 05:24:52 GMT
I asked Fink to install Subversion. Just like apt-get on Debian, or yum on Fedora, Fink is pretty smart and knows where to get stuff.
Problem is… I asked Fink to install Subversion 4 hours ago. Seems that even though I told Fink that I would prefer binary packages where available, it’s only found source packages so far. And Subversion depends on a lot of stuff, including Apache’s huge APR codebase not to mention 53 other libraries. So, I’ve been looking at ‘configure’ and ‘gcc’ output scroll down my terminal for quite a while now.
Could be that no one is maintaining binaries for OSX 10.4, and I’m stuck with source for a while. I guess that’s okay… Sure would save a lot of time if I didn’t have to deal with it though.
Update (5/27/05): Many thanks to Christian Schaffner! He’s the maintainer of Subversion fink package. He pointed me to this resource, which I can use to find out if a binary package is available for OSX 10.4 (at least until 10.4 binaries become common):
Fink Package Database
Update (6/1/05): Fink now has a binary of Subversion available, according to the package database. Unfortunately, it’s only at version 1.1.4 (just like the source version I installed a few weeks ago). I’d like to upgrade the servers at work to 1.2, but maybe I’ll wait until the 1.2 client is available on Fink.
Update (6/14/05): According to the Fink Package Database and my own verification with the cli, the subversion 1.2 client is now available in the unstable packages. Switching to “fink unstable” is quite easy with Fink Commander
Posted in Code, OSX | no comments
Articles Only
