Bill, what is the relative speed of the C++ parser/conduit to the current
Python parser?
I ask because I have written several cross-platform multithreaded TCP/IP
servers (and clients) and could perhaps take a good shot at making it
cross-platform. Unless there's a LOT of MFC, usually it's pretty
straight-forward in terms of code changes.
But if the speed is nearly the same, the project momentum is much more
important.
Tony McNamara
At 08:55 AM 9/24/2002 -0400, Bill Nalen wrote:
>FWIW, I did a lot of work a while back translating the Python code to C++.
>This is all done on Windows with VS 6.0. I've got a stand alone parser and
>a complete Palm conduit working using this code. We use it every day in
>production where I work. I started this to have a real conduit that would
>work for Palm users who only know how to press the hotsync button. We
>looked at remotely preparing the content and having them sync the pdb, but
>it would have been more complex for the users. Since Windows users are
>typically less sophisticated than *nix users, we need to keep things as
>simple as possible and as standard as possible. I think *nix developers
>drastically under estimate the simplicity needed for Windows users (but not
>developers ;-).
>
>There's a couple of drawbacks to this approach though. The code base is
>using Python so it would be up to me to keep it in sync with the Python
>code, not difficult, but not trivial either. It also adds one more option
>to the Plucker project that probably doesn't need to be there. Also, aside
>from the Windows conduit produced (and probably Mac as well), the code
>would be useless to the other developers.
>
>I think the work that Bill J (?) is doing on getting a Java version of the
>parser built directly from the Python code is GREAT. This would solve a
>lot of problems for me. I wouldn't have to keep the C++ code in sync and
>it could be built directly into a parser. I think this would become the
>parser of choice on Windows. I'm looking forward to getting the latest
>version to start working on a conduit from it. Once the Java version is
>stable, I'll drop my C++ conduit in favor of it. I think a good conduit
>option is the only thing missing from Plucker (well for most Windows users
>to really use it easily).
>
>When I ported GKrellM to Windows it took me a long time (probably a week)
>to get all the libraries needed and to get a clean build. A build on
>Windows had never been done, so I wasn't surprised that it took me that
>long. I feel the same way about Plucker. I would expect it to take a long
>time to build since (almost?) no one seems to develop on Windows. I've
>stayed away from the viewer code simply because I know it would take some
>time to get it running and others seem to be doing a great job of
>fixing/updating the code. I don't blame them for not having the correct
>imports and stuff in there if they don't know what to put. It's up to the
>Plucker Windows developers to get it working and tell them what to add.
>
>For example, Bill J (again ?) has made a GTK viewer on *nix. Since the GTK
>libraries have been ported to Windows, I took a shot at compiling it under
>MS VS 6.0. I needed to make a bunch of import/define changes to get it to
>compile and run (found a couple bugs too :-) I have yet to get back to
>Bill with the required changes, but I will when I see the next version
>released. This is the way most projects I've been involved with go. It's
>a frustrating build process, but hopefully only one person will have to go
>through it.
>
>Bill
>
>
>_______________________________________________
>plucker-dev mailing list
>[EMAIL PROTECTED]
>http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
