> Ah, I found the 4.0 tar file on the Palm site. Color me
> short-sighted...
Stay short-sighted..
I found out that the POSE sources that Palm provides on their site
are *ALL DIFFERENT* in the .zip, .sit, and .tar.gz files. I assumed the
"Full sources" tarball meant _ALL_ the so
Well, I've figured out enough of Jython to compile the parser into a
jar file, and I can now pluck (without images) using only Java 1.2.
To tell you the truth, I'm flabbergasted that this stuff works this
well.
Here's what a typical command line looks like:
java -classpath plucker-build.jar pluc
Ah, I found the 4.0 tar file on the Palm site. Color me short-sighted...
Bill
Even better, they only supply the SDK in various .exe, .sit, or .rpm
versions, none of which work on my Solaris machine. Till someone can
tar up a real version of the SDK and send it to me, I'm stuck.
Geeesh!
Bill
> On Thu, Feb 28, 2002 at 06:35:49PM -0800, Bill Janssen wrote:
> > Hmm, I can n
Adam,
Do I need the whole SDK, or can I just grab the .h file? Do you know?
Bill
Well, the autoconf is still there, and works pretty well. Yes, I'd
suggest extending it to cover these cases. And maybe
--enable-redhat-python-fix, too :-). I've never been fond of automake,
but if you must...
Bill
> > I suppose it would be nice to maintain backward compatibility and
> > prov
> I suppose it would be nice to maintain backward compatibility and
> provide the option not to build VFS support with the viewer. a la
> ./configure --disable-vfs
At one point, we had a proper autoconf/automake configure system,
built by Mike and myself.. which now begs the question, sh
On Thu, Feb 28, 2002 at 06:35:49PM -0800, Bill Janssen wrote:
> Hmm, I can no longer compile the viewer. os.c cannot include
> VFSMgr.h. Where does that come from? I didn't notice any changes to
> the REQUIREMENTS doc?
VFSMgr.h is from v4 of the palm SDK... grab that and it should work.
I sup
>
> > What I looked for was a way to protect the document, assuming only minor
> > changes to the viewer or the document itself by an attacker.
>
> Given the recent "awareness" of security issues lately, driven
> mostly by the media, let's choose terms a bit differently here. How about
> "
Hmm, I can no longer compile the viewer. os.c cannot include
VFSMgr.h. Where does that come from? I didn't notice any changes to
the REQUIREMENTS doc?
Bill
> What I looked for was a way to protect the document, assuming only minor
> changes to the viewer or the document itself by an attacker.
Given the recent "awareness" of security issues lately, driven
mostly by the media, let's choose terms a bit differently here. How about
"obscure" the
Terence,
I've been through this with a number of security researchers. There
is no way short of a full public key system (and probably not even
then) to more strongly protect a document that's in a documented
format displayed via open-source software. What I looked for was a
way to protect the
Mike, please send me a copy of your urllib.py file, would you? Thanks.
It should be at /usr/lib/python*/urllib.py.
Bill
2/28/02 7:55:05 PM, Michael Nordström <[EMAIL PROTECTED]> wrote:
Hi Mike,
Thanks for giving it a kick on the tires.
>> Thus the file configuration class had an extra style added, and the
>> patched files put in the patch_wx directory.
>
>You forgot to include confbase.h in fileconf.cpp -- it won't
"Branko" == Branko Strok <[EMAIL PROTECTED]> writes:
Branko> Did anyone notice that the default icon (when set) for user
Branko> created database tends to dissapear leaving empty space on the
Branko> pda screen? This is not the
Yes, IMHO this are an Bug in the Launcher, together with the bug tha
2/28/02 7:55:05 PM, Michael Nordström <[EMAIL PROTECTED]> wrote:
>On Sun, Feb 24, 2002, Robert wrote:
>
>> Thus the file configuration class had an extra style added, and the
>> patched files put in the patch_wx directory.
>
>You forgot to include confbase.h in fileconf.cpp -- it won't compile
>
On Thu, Feb 28, 2002 at 04:28:04PM -0800, David A. Desrosiers wrote:
> It's fine, let's keep it, but a shorter icon title would be nice.
Plkr-sony, and PlkS good?
--
Adam McDaniel
Infrastructure Technology Consultant
M-Tech Mercury Information Technology, Inc.
> I'll re-do that prc to only do Plkr right now...
AAAH! Then it _WILL_ clobber the existing Plucker. PlkS is fine, it
doesn't conflict with any registered CreatorID that Palm knows about (though
that's not a guarantee that it won't clobber an app that has _NOT_
registered it's CrID with
> Installing it wont overwrite your existing copy of Plucker, It will
> create a new icon for Plucker-sony.
I just realized something. Installing this clobbers the icon
title itself, so that Plucker and Plucker-sony look identical.
Perhaps a shorter title on the icon?
Sony... Pl
On Thu, Feb 28, 2002 at 04:22:54PM -0800, David A. Desrosiers wrote:
> > Installing it wont overwrite your existing copy of Plucker, It will
> > create a new icon for Plucker-sony.
>
> EEK! I just checked Palm's database, and luckily we didn't clobber
> any existing CreatorID, but perhaps w
> Sounds like we have a beta-testing volunteer :)
The more the merrier!
> Installing it wont overwrite your existing copy of Plucker, It will
> create a new icon for Plucker-sony.
EEK! I just checked Palm's database, and luckily we didn't clobber
any existing CreatorID, but per
Hello,
Did anyone notice that the default icon (when set) for user created database
tends to dissapear leaving empty space on the pda screen? This is not the
case with the viewer (same) icon. I'm using OS 3.5.
Branko
_
Chat with
On Fri, Mar 01, 2002 at 10:49:58AM +1100, Harry Ohlsen wrote:
> The problem is that when I put them in the memory stick, Plucker doesn't seem
> to see them. I don't know whether there's magic involved in seeing into the
Sounds like we have a beta-testing volunteer :)
> I'm happy to have a go a
> I'm happy to have a go at writing the code myself, but I thought I'd see
> if anyone is working on this at the moment and get some advice on where
> I might start if noone is.
There are two branches in the Plucker cvs currently that you may be
interested in testing/contributing/helping
On Friday, March 1, 2002, at 08:02 , Bill Janssen wrote:
> The current setup XOR's the owner-id with the beginning of each
> zlib-compressed segment. This makes it (cryptographically) fairly
> easy to get the owner-id out of the document. A better scheme would
> be to construct a sequence of ha
I just subscribed, so maybe this has been discussed before, but I didn't
notice anything in the archive. My apologies if there is, and can you just
give me a link to the right messages.
I just bought a Clie 615 (wonderful device!) and I also bought a 128MB memory
stick, thinking that one of t
On Thu, Feb 28, 2002, Bill Janssen wrote:
> I've come up with a better way of encrypting the owner-id information,
> so I'd like to hold up any release till I put it in.
Go ahead. As long as the included RH fix breaks the parser on my non-RH
system I can't honestly consider the current version re
I've come up with a better way of encrypting the owner-id information,
so I'd like to hold up any release till I put it in. I'll try to do
it tomorrow.
The current setup XOR's the owner-id with the beginning of each
zlib-compressed segment. This makes it (cryptographically) fairly
easy to get t
On Sun, Feb 24, 2002, Robert wrote:
> Thus the file configuration class had an extra style added, and the
> patched files put in the patch_wx directory.
You forgot to include confbase.h in fileconf.cpp -- it won't compile
without it.
After fixing a few other problems in the code I was able to
As soon as all platforms are using JDK 1.4, we can consider using the
features in it. Right now I'd suggest JDK 1.2 is more of a standard.
What's in debian-stable?
Bill
Hi,
JDK 1.4 implements image encoders too... I was wondering : why not alter
JIU to use this new feature?
.: marcelo :.
| Hello,
|
| JDK 1.4 implements pipe: java.nio.channels.Pipe
| so easy to use. JDK1.3 implements another way, via
| pipedWriter, etc, but 1.4 is easier.
|
| But... isn
31 matches
Mail list logo
