Re: redef error when using 68k/hs.s headers
On Wed, Jun 29, 2005 at 04:44:09PM -0400, Scott Erickson wrote: > (In PalmTypes.h) > #define _OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR(table, vector, selector) \ > __attribute__ ((__callseq__ ( \ > "move.w #" _PalmTypes_OS_CALL_Str(selector) ",-(%%sp); " \ > "trap #" _PalmTypes_OS_CALL_Str(table) "; dc.w " > _PalmTypes_OS_CALL_Str(vector > > (In HsExt.h - redef location) > #define _OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR(table, vector, selector) \ > __attribute__ ((__callseq__ ( \ >"move.w #" _Str(selector) ",-(%%sp); " \ >"trap #" _Str(table) "; dc.w " _Str(vector > > I dont know much about what this define is used for, so I dont know if it is > safe to remove the one in Hs. What is the best way to deal with this > problem, or is it not going to be a problem at all??? The correct solution [1] is to wrap a #ifndef around these #defines, in both PalmTypes.h and HsExt.h: #ifndef _OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR #define _OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR([...]) [...] #endif Probably you always #include or so in your source files before any palmOne headers, so you could get away with only wrapping the one in HsExt.h. And in fact it's only a warning and isn't causing any other damage, which might constitute "not going to be a problem" for you. Alternatively, you could update to the 5.0 palmOne SDK released last week, which uses a dumb hack to avoid this warning (instead of avoiding it by using the infrastructure that's been added to PalmTypes.h for their benefit, sigh). It's interesting to look at how this situation has arisen. The ultimate expansions of both #defines are the same, so it doesn't matter which one you end up using. In the past, the definitions in both places were identical, so the redefinition was benign and didn't require a diagnostic (C99 section 6.10.3). The definitions became non-identical and the diagnostic required with the Fall 2004 Palm OS SDK, when someone renamed PalmTypes.h's _Str macro to _PalmTypes_OS_CALL_Str. This change could be cordially described as being an instance of "a little knowledge is a dangerous thing". _OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR used to be defined and used only in the palmOne (ne Handspring) headers. With the Fall 2004 update, Handspring's 5-way navigation functions have graduated to the platform SDK, and they and their _OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR (which is a mere implementation detail for most of us) are in the process of moving to the Palm OS SDK. During the transition, they appear in both sets of headers. Ideally HsExt.h would use the platform's definition of _OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR (from PalmTypes.h) if available and fall back to its own definition otherwise. Eventually, when the updated Palm OS SDK was ubiquitous, palmOne would remove the now unneeded definition from HsExt.h. Instead, they've renamed things in HsExt.h so that it's further divorced from the infrastructure in PalmTypes.h. This is unfortunate; that infrastructure was designed precisely so that this complex and limiting code wouldn't need to be duplicated into headers like HsExt.h. John [1] This is the correct solution for someone in Scott's position, hacking SDKs to get rid of spurious warnings. From PalmSource's point of view, I suspect the correct solution is for HsExt.h to #include *and* wrap its own definition of the macro. This reflects the longer term goal of PalmTypes.h providing this infrastructure cleanly. Wrapping the PalmTypes.h one would reflect the transitional state of moving the macro from HS headers to the platform ones, and it would be unfortunate if PalmTypes.h contained the detritus of this transition long after the transition was over. -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Newbie Question : POSE Mouse problem on linux
Aykut KOÇAK wrote: I have got a problem with the touch screen that is when I click mouse pointer inside the touchscreen area, it does not respond but ok for buttons such as power button or shortcuts. Your symptoms are consistent with the GCC 3.3.x miscompilation of Poser's EmPoint.cpp described in http://news.palmos.com/read/messages?id=153083 http://news.palmos.com/read/messages?id=189359 and fixed by the patches to be found in the patch area at http://sourceforge.net/projects/pose/ John -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: sprintf vs StrPrintF
Ralf Dietrich wrote: BTW: Anybody know if ANSI permit the same source/target ptrs in sprintf()? I presume everyone's gut feeling is that it would not, and that is indeed the case: ISO C90, 7.9.6.5: "The sprintf function is equivalent to fprintf, except that the [first argument] specifies an array into which the generated output is to be written [...] If copying takes place between objects that overlap, the behavior is undefined." (And similarly in C99, section 7.19.6.6.) John (PS for other language lawyers: I don't think it's astoundingly clear what "copying" means in this context, but the intent is pretty clear.) -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Palm OS 4.0 Source Code
Greg Wilson wrote:
To the best of my knowledge, it is no longer available.
If that is a statement of fact ("it is currently no longer available"),
we don't really need a PalmSource employee to tell us that -- we can
see it for ourselves :-). If that is intended as a statement of
PalmSource's intent ("it is and will be no longer available"), then it
conflicts with information earlier provided by another PalmSource
employee.
Back in December, Ben Combee wrote on his personal site [1]:
Access to seeding material and Palm OS source code isn't yet available
with the new [developer pavilion]. We are working on the revised legal
agreements to provide access to this, and I should be able to give
more information in early January.
Now to be sure something on a then-employee's personal web site is not
an official statement from PalmSource, but I think we all agree Ben has
a reasonably good reputation around here and he surely had a reason for
writing what he did.
Hopefully someone speaking officially for PalmSource will clarify
PalmSource's intentions (and the reasons for them) with regard to this
educational old source code.
John
[1] http://palmos.combee.net/blog/NewPalmSourceDeveloperSit.html
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: Error Messages
"Kaiser D" wrote: My question is does Palm have an API which when given the error code gives the corresponding error message in text. See http://prc-tools.sourceforge.net/errorcodes.html Or just type "palm os error" into Google. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Make Clean doesn't make clean bug in PODS 1.1
Benoit Cerrina wrote: The reason seems to be that make.exe loops through all .d files and checks references *prior* the .d files are deleted by "make clean all". Just to say that in our project which use make and prc tools we also generate dependency and have the same issue after renameing .h files. There is a standard trick for dealing with this, which you can find by looking up "clean" in the GNU Make manual's index. http://www.gnu.org/software/make/manual/html_node/make_93.html John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: John Marshall still doing Palm stuff?
Gregg Woodcock wrote: I know he was at Palm and then at enterprise.net I'd be curious to hear how you know that, considering that it is not true. Enterprise.net was merely an ISP that I used in the UK seven years ago (and thus _before_ I was at Palm). Somebody shoot me his email, please? You could ask Google, or look at my responses to your own questions on this very list back in late 2003. But I suppose you have your answer already :-) John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How to use prc-tools
On Mon, Jul 19, 2004 at 07:31:35PM +0200, John Marshall wrote: > On Mon, Jul 19, 2004 at 05:30:51PM +0200, Yann Garcia wrote: >>> /usr/share/prc-tools/include/PalmOS.h:15: warning: #warning [...] you >>> may need to run palmdev-prep [...] >> >> sdk-4 headers in 'include', libraries in 'lib' > > This is the expected output from palmdev-prep. And presumably you are > using m68k-palmos-gcc -palmos4 *after* having run palmdev-prep :-). And the moral of the story is: never presume anything :-). Yann sent me the -v output, and the problem was indeed the obvious one: palmdev-prep had not yet been run, despite the installation instructions and wording in the warning. Well, it's easily fixed :-). John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: PalmOS Character Map / Color Palette
On Mon, Jul 19, 2004 at 04:39:56PM -0700, Matthew Bevan wrote: > I'm looking for a scrollable character map utility upon which I can > tap and get ASCII, decimal, octal, and hexidecimal values for each > character. Oddly enough, noone's mentioned AsciiChart yet. (I was going to note that last time I looked it crashed my Treo (i.e. it didn't like OS 5), but I see that it's been updated recently, for the first time in four years. Fantastic!) > Now another thing I'm looking for is the PalmOS 256-color color map > for OS 4 devices and above. A palletted bitmap image would be perfect > (as there are a variety of palette formats, almost none of which I am > able to read. ;) The application you're looking for is McColors. Also PilRC comes with a set of color palette bitmaps in PPM format, but presumably that's one of the ones you're unable to read :-). (Google knows where to find these two applications.) John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How to use prc-tools
On Mon, Jul 19, 2004 at 05:30:51PM +0200, Yann Garcia wrote: > About palmdev-prep, the output is: > [EMAIL PROTECTED] root]# palmdev-prep > Checking SDKs in /opt/palmdev > sdk-4 headers in 'include', libraries in 'lib' This is the expected output from palmdev-prep. And presumably you are using m68k-palmos-gcc -palmos4 *after* having run palmdev-prep :-). (Is that *exactly* the palmdev-prep command you are using?) It's hard to say what's going wrong here. The next step is for you to show us the output from "m68k-palmos-gcc -v -c -o hello.o hello.c". (Rather than bore the list with it, feel free to send it just to me.) John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How to use prc-tools
On Mon, Jul 19, 2004 at 02:36:53PM +0200, Yann Garcia wrote: > /usr/share/prc-tools/include/PalmOS.h:15: warning: #warning use Pilot.h > if you really mean to use the 3.1 SDK or earlier; you may need to run > palmdev-prep or use a suitable -palmosN option -- see > "http://prc-tools.sourceforge.net/cgi-bin/info/palmdev-prep"; for details > > Anyone can help me to understand what happen? Was this warning difficult to understand? Was it difficult to understand the details at the URL in the warning? Did you have trouble following the "Post-installation setup" part of the installation instructions at http://prc-tools.sourceforge.net/install/rpm.html ? Please tell us what the difficulty was so that we can try to improve the documentation. Where is the SDK installed? What was the output when you ran palmdev-prep? It is palmdev-prep that generates a configuration file that tells GCC what -palmosN options mean, as noted in the documentation. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Getting started with PODS
On Fri, Jul 16, 2004 at 11:28:30PM +0200, John Marshall wrote: > Yes, that's why I said "to do with the debugger" rather than "in the > debugger" :-). Oops, wrong mailing list -- sorry. That conversation is actually going on over on tools-forum... John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Getting started with PODS
On Fri, Jul 16, 2004 at 01:41:45PM -0700, Keith Rollin wrote: > Actually, looking into this a little more deeply, I see that Ton's > patches patch the following in addition to gdb: > > [files outwith gdb] Yes, that's why I said "to do with the debugger" rather than "in the debugger" :-). > Am I incorrect in assuming that the above changes would affect the > actual generation of the application? The only one that might make a non-trivial difference to the generated bfd executable is the obj-coff.c patch. It may be a (partial?) fix to the "gas fails if one translation unit has more than 64K of code in it even when no single code section therein is larger than 64K" problem [1]; I don't recall. Ton? John [1] That problem can be worked around by splitting the huge translation unit, of course; and that'd often be an improvement in style anyway. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Segmentation error.
On Thu, Jul 15, 2004 at 09:01:06AM -, BrownB wrote: > Sorry to everybody, I found my STUPID ERROR: I didn't #include the > header containing the extern declariation of those functions... Indeed. Consider reading the documentation, which will tell you how to catch this stupid error at compile time: http://prc-tools.sf.net/cgi-bin/info/breaking+up+an+existing+application John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: PODS-Problem Building a multi-section app
On Tue, Jul 13, 2004 at 06:00:49PM -0500, Ben Combee wrote: > The PODS 1.0 beta isn't adding the Sections.def file to the command > line for build-prc, which makes the build just group all of the code > sections into the main section. No. As the diagnostic message says, spurious code sections are *ignored*, which means that they don't get copied to the output PRC file at all. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: PODS-Problem Building a multi-section app
On Tue, Jul 13, 2004 at 09:56:36PM -, Richard Dumais wrote:
> OK, the only problem left now is that build-prc still gives me the
> message "MyApp:segment2: warning: spurious code section ignored"
This message means that the code section "segment2" is not listed in the
definition file given to build-prc. It's _spurious_ in that it was found
in the executable, but build-prc was not expecting it.
> ===Sections.def=
> application { "MyApp" }
>
> multiple code { segment2 }
But your definition file most certainly does list it; therefore it seems
most probable that the cause of your problem is that Sections.def was not
given as an argument to build-prc. (I myself have no idea what would
cause that in a PODS context.)
This information and more can be found in the palm-dev-forum archives by
searching for "spurious code section ignored".
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: passing pointers between functions in different segments.
On Tue, Jul 13, 2004 at 02:52:05PM -, BrownB wrote: > I found some problems passing pointers to allocated memory chunks > between functions located in different segments. I am aware of no particular problems in passing such pointers between functions in different sections. > In this example, when I call func2() from main() I get a runtime > error, while putting func2() in segment Seg1 (i.e. .TEXT segment...) > doesn't give any error. The code you have shown contains no main() function, so it is difficult to comment on what particular user error it is that you have made. But the declaration of func2() in this file (rather than in a header) suggests that it may be that no declaration of func2() is visible from this call site in the definition of main(), and that user error is the most common cause of this sort of problem. That fact is noted in the documentation, along with a recommendation to compile with -Wall and/or -Wmissing-declarations to detect your error. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Palm OS Developer Classes Coming in August
On Fri, Jul 09, 2004, Ben Combee <[EMAIL PROTECTED]> wrote: > Hello! Ben Combee from PalmSource DTS here. Hello! There was me thinking it was Ben Combee from the Techwood Broadcasting Foundation calling! ;-) > These classes are not free -- there's a nominal fee to cover materials, > instructor time, and the classroom -- but I think they are a great bargain Wow, USD 1700 is "nominal" on your planet?! I guess that exchange rate must have really tanked since last time I looked... John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: prc-tools
On Fri, Jun 18, 2004 at 10:06:31PM -0400, geoff wrote: > hey, im having trouble with prc-tools. I dont even know if this is the right > palce to post, but im desperate. Is it even possible to build it on windows > xp, why can't a website just build prc-tools then send out a built copy so i > don't have to go through with this. Thanks What, you mean like this website: http://prc-tools.sourceforge.net/ ? Perhaps in your desperation you could actually say something about the particular problems you think you are having. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: weird database problem
On Thu, Jun 10, 2004 at 03:27:37PM -0700, Mike wrote:
> dbID = DmFindDatabase (0,DBName);
> if(dbID)
> { // we found it
> hTempDB = DmOpenDatabase (0,dbID, mode);
[...]
> E:0216,
[...]
> How can DmFindDatabase return a valid ID, but DmOpenDatabase not be able to
> find it?
You don't say what _mode_ is, but, due to the fact that 0x0216 is
dmErrAlreadyOpenForWrites, you can probably guess what's going on.
See also http://prc-tools.sourceforge.net/errorcodes.html -- a new
build of which I must get around to releasing one of these days.
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: is 'B' going to be always right after 'A'?
On Tue, Jun 08, 2004 at 10:39:53AM -0400, jimrandomh wrote: > Paul Nevai wrote: >> I wonder how safe it is to assume that 'B' is going to be always right >> after 'A' as far as the Palm OS universe goes. > > Character literals with no qualifiers are defined to be ASCII by the C > standard. Interesting. What C standard are you reading? The one I'm reading (C99, section 5.2.1/3) merely requires that a certain set of characters (Latin letters, digits, and a large pile of punctuation) be present, and that the decimal digits '0' to '9' be contiguous. The O.P. should think about what interesting character collation sequences are coming along in the future. Hint: there's only one, and it has the Latin letters in the same places as ASCII does. In turn, I wonder how safe it is to assume that asking about the safety of such assumptions as the O.P. is doing is *always* indicative of a design mistake... John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Conversion between double and integer
On Wed, Jun 02, 2004 at 08:27:10PM +0400, Pierre Brial wrote:
> double ReturnDouble()
> { return 3.1416; }
>
> static void Go()
> {
> double d,e;
> int i;
> d=ReturnDouble();
> i=(int)d;
> e=(double)i;
> ...
> }
>
> after this, the values of the variables are : d=3.1416, i=3, e=0 !!!
> I don't understand why e cannot take the value of i.
You are using an old version of prc-tools that contains a bug related
to run-time int<->double conversions. The bug was fixed four years ago.
The solution is to update to a more recent version of prc-tools.
For details, see
http://www.escribe.com/computing/pcpqa/m44661.html
http://prc-tools.sourceforge.net/releases.html
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: PRC-Tools linker error
On Tue, Jun 01, 2004 at 11:29:09AM +0200, [EMAIL PROTECTED] wrote: > I think it's related to 'CODE' resource size, which should be less > than 64 kb. But the latest version I compiled without this error gives > a 54kb .prc file, which includes many resources (fonts, bitmaps ecc.) > so how can the 'code' resource be bigger than 64 kb?! By default, prc-tools produces diagnostics when code resources exceed 32K. See http://prc-tools.sourceforge.net/cgi-bin/info/special+projects for details as to why, and on changing this boundary to 64K if you want to. Use e.g. "m68k-palmos-objdump -h foo.prc" to see just how large various resources are. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: IDE
Pavel Szalbot <[EMAIL PROTECTED]> wrote: [On the SDK download page's "Unsupported Palm OS SDK R3 for PRC-Tools"] > "Unsupported" term really scares me - it sounds like "use at own > risk", not "we shouldn't be supposed to answer your question". I am > sorry to speak like that - I realize that my opinion could be wrong. I have been concerned for some time now that people will be put off by the alarmist wording on that web page, just as you have been. Now that PalmSource is using prc-tools as a component of PODS, one imagines that they will correct this text. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: GLibs with prc-tools (pointer problem?)
Jan Bandouch wrote: > I do compile with "-mown-gp" as in the example. Couldn't find anything > about it. What does it do? Where did you look? It is a GCC option that is specific to Palm OS, and is documented as such at http://prc-tools.sourceforge.net/doc/ . John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Font families with Pilrc
Alexander Lange wrote:
> if (densityCount < 2)
> Error("FontFamily must have 2 fonts with density 72 and 144.");
>
> So obviously it is not possible at the moment to create a font family with
> only a high-res member. Too bad. Maybe the Pilrc designers could rethink
> this in the future.
If you read the font family specification [1], I think you'll agree that
it requires the family to contain a low-density font. Thus if there is
any rethinking to be done, it really ought to be PalmSource issuing a
clarification of this specification.
John
[1] http://www.palmos.com/dev/support/docs/palmos/Font.html#1000390
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Font families with Pilrc
Ben Combee <[EMAIL PROTECTED]> wrote: > Thanks for the update... it seems that when we update the font support in > PilRC, we should derive metrics from the least-density member of the family. It already does that. Or at least it's intended too -- the support may well be buggy. (Well, it uses the metrics from the *first* one, but you ought to make that the least-density member or else you'll likely have other problems too.) Alexander hasn't said what version of PilRC he's using. Font families got a lot less buggy in 3.1, so if he's using an older one, he should certainly try it with 3.1 too. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Assembly on the Palm
Ben Combee wrote: >> [The ARM ARM,] which you generally have to buy in physical form > > If you get the evaluation CD version of ARM's RealView tools [...] I generally consider that CDs have a manifestation in physical form. :-) (Okay, perhaps "buy" is questionable.) John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Assembly on the Palm
Matthew Henry wrote: > 1 Understanding what I am seeing when the debugger steps into Palm OS Code > 2 Understanding the (68k) code that CodeWarrior is generating Go to http://www.motorola.com/ and type "m68000prm" into the search box at top right. This leads you to the 68K Programmer's Reference Manual (a 2.5Mb PDF), which is the canonical reference for 68K assembly language. The equivalent for ARM is the ARM Architecture Reference Manual (go to http://www.arm.com/ and search for "ARM ARM"), which you generally have to buy in physical form. You can also download a "reference card" PDF (search for "QRC"), but it's not a great way to learn ARM assembly language if you don't already know something about it. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Cobalt porting: No longer single prc for all OS versions
Linke, Andreas <[EMAIL PROTECTED]> wrote: > I've been programming Palm OS for 7 years now, but I can't remember > such a radical change. There seems to be no attempt at compatibility, > neither binary nor in source. It seems to me that one summary of the things you've noted is "this is a new operating system". > And, apparently just for fun, they've changed all the type names again > (e.g. UInt32 becomes uint32_t). There's nothing too exciting about these names; the idea is pretty trivial and any idiot could define a set of them for their own Palm OS application. The advantage in having them supplied to you is that it creates a common vocabulary that we all use. Using UInt32 etc supplied by a Palm OS SDK means that all the Palm OS programmers share a common vocabulary. Using uint32_t etc, which are defined by the C99 language standard, means that all C programmers [1] can share a common vocabulary. Or, put another way, by using uint32_t etc on Palm OS we're sharing the vocabulary that all the other C programmers are (or [c|sh]ould be) using. This change is a Good Thing IMHO. (BTW a has also been supplied by prc-tools since version 2.3.) However, I still think that it's unfortunate that they're still so heavily used on Palm OS; see also http://escribe.com/computing/pcpqa/m59451.html John [1] potentially; certainly all C99 programmers -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: (Palm) How to distribute new IDE..
Joe Siebenmann wrote re Cygwin's setup.exe: > If you aren't careful, the setup will try to UNINSTALL programs you > just tried so hard to put together. Oh, that's nice.. It needs > improvement.. Please describe the problem in such detail that it can be reproduced. Or file a bug report. Or take it up on the Cygwin mailing lists. Please. If you want to help improve it, then you need to provide this level of detail for your report to be helpful. Otherwise it's just vague innuendo. And that's pretty much the definition of FUD. EOT. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: (Palm) How to distribute new IDE..
Joe Siebenmann <[EMAIL PROTECTED]> wrote: > I haven't seen the 'Eclipse IDE' release, and I'm sure you're trying to > figure out how to distribute it.. I have a good idea. :-) I had the impression that they knew what form they wanted to distribute it in, but had not figured out where to find a network of mirror sites, such as Debian, Red Hat, or GNU have, at short notice :-). > Going through the whole Cygwin setup is frought with possible problems, > didn't get make, Oops.. have some previous attempt to get it, so it didn't > include file such-and-such Oops.. :-( People who want to throw Cygwin FUD around might as well throw valid FUD. "Didn't get make" is nothing to do with Cygwin or its setup.exe. It's just a straw-man: if I thought it was the right thing to do, I would have arranged the prc-tools.sf.net repository so that make was installed by default. But I don't think that. If PalmSource wanted to set up some Cygwin-based stuff in a fairly ideal way, they might consider allowing for the best of both worlds: * setting up a repository accessible via Cygwin's setup.exe, so that their packages interact well with existing Cygwin users' existing Cygwin installations * providing Palm OS SDKs as packages, which I would suggest would completely solve the remaining area of this installation that is fraught with any real difficulty * producing their own palmsource-setup.exe based on Cygwin's, which would contain preselected default answers to all those questions that Cygwin setup.exe asks that are oh so difficult to answer: PalmSource's repository preselected, a more complete (and less flexible) set of default packages, extra click-wrap license screens to taste, etc -- thus providing an installer that would look like what Windows users are used to, but still interoperate with any Cygwin installation that might already be present Because this is eminently sensible, it will never happen :-) > a nice .zip file with just the files you need is perfect! It would be imperfect because it would come with imperfect instructions that would inevitably be imperfectly followed. We've been here before: http://escribe.com/computing/pcpqa/m56756.html John (But please let's not have another Cygwin FUD thread. One in a week is tiresome enough, no?) -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Palm OS Developer Suíte - Now Available ?
Jim Cooper <[EMAIL PROTECTED]> wrote: >> It provides a substrate that makes it practical for volunteers to provide >> free tools to you on Windows. > > Plenty of people provide free tools without using cygwin. I've even done > it myself. Okay, a clarification: "...to provide these and similar free tools...". Or even longer: the practical way to port a GCC cross-compiler (and other tools with a similar heritage) to Windows is to use Cygwin. But don't take my word for it -- go and look at other such ports, such as the PS2 or Symbian ones. > No-one has yet answered my question, though, and you should be able to. > Why is cygwin required to **use** prc-tools? Do the tools rely on it > internally? You don't need me to answer that. Go to http://cygwin.com/ and find out what Cygwin is; then look at GCC and particularly its build infra- structure [1] and see what they want from a host OS. Run cygcheck on m68k-palmos-gcc.exe and think about the implications. If you're not willing to do those things, I don't see why you should expect better answers than "because that's the way it is" and "duh, yes". But in fact you've received several in any case... John "agreeing with Eron's nose" [1] The fact that it's largely the build infrastructure that really wants a Unix shell and tools makes the MinGW option vaguely feasible, but it's probably not a coincidence that none of me, Sony, Symbian, and now PalmSource have felt that the investment was worth it just to cut down on rants from people like you :-). -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Palm OS Developer Suíte - Now Available ?
Jim Cooper <[EMAIL PROTECTED]> wrote: > But what advantage is cygwin to someone who does **not** want to use the > command line? It provides a substrate that makes it practical for volunteers to provide free tools to you on Windows. And it's all the graciousness and gratitude from Windows users just like you, Jim, that makes the work seem worthwhile. Thanks, Jim! John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Compiling CryptoDrvr w/ PRC-Tools...
Joe Siebenmann <[EMAIL PROTECTED]> wrote: > I'm trying to build the sample Virtual Device Driver, CryptoDrvr, using > PRC-Tools.. 30 seconds of looking at the CryptoDrvr source code shows that a virtual device driver is just a lump of globals-less code in the 'code' #0 resource with the function DrvEntryPoint as its entry point. That means that you should treat it as what prc-tools calls _stand-alone code_. See http://prc-tools.sf.net/cgi-bin/info/stand-alone+code+resources particularly the tutorial section "Producing a stand-alone code resource". In short, you should add #include STANDALONE_CODE_RESOURCE_ID (0); somewhere, link with m68k-palmos-gcc -e __Startup__ -nostartfiles [...] (__Startup__ because that's what DrvEntryPoint gets #defined to), and the .def file merely needs to set the type and creator, so is pretty much irrelevant. (You should use the generic project kind, "database".) > I can't find the docs for .def files Where did you look? How can I make the documentation easier for you to find? John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Late night #define C question
David Webb <[EMAIL PROTECTED]> wrote: > #define MAX_DOWNLOAD_SIZE 46000 [...] > StrPrintF(msglabel, "%u", MAX_DOWNLOAD_SIZE); When ints are 16 bits, the integer constant 46000 has type _long_ int, so amusingly enough is not what StrPrintF is expecting when you say "%u". Even more amusingly, 0xb3b0 has type unsigned int under similar circumstances, so would work well with "%u". As Jan suggested, putting explicit suffices on your large integer constants is a good idea. The relevant part of the C99 standard is section 6.4.4.1. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: WinSetPattern problem
Dyekiss Emil Gergely <[EMAIL PROTECTED]> wrote: > warning: passing arg 1 of 'WinSetPattern' from incompatible pointer type See http://groups.google.com/groups?selm=a0uugq%24jqa%241%40zappa.falch.net John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: MIME type of a prc file
> [W]hat is the MIME type associated with a .prc file? "application/vnd.palm"; see http://www.iana.org/assignments/media-types/application/vnd.palm John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: [ANN] Multi Section Debugging for prc-tools-2.3
Douglas Handy <[EMAIL PROTECTED]> wrote: > However, it appears two of the files have a zero length: > >usr/m68k-palmos/bin/as.exe >usr/m68k-palmos/bin/ld.exe > > Unless my tar utility is failing me, both of the above are given as 0 bytes, > created 12/26/2003 at 21:04. They *do* have zero length in the archive. They are (hard) links to previous files in the archive. You don't say whether extracting the files actually failed, or it's just that you were surprised by what you saw when listing the archive. If the former, it is indeed because your tar utility is failing you. Cygwin's tar copes with these just fine. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: create 'nfnt' font family problem with PilRC 3.0
[EMAIL PROTECTED] wrote: > The problem is that one of your High Resolution Glyphs is not exactly > double the width of it's low resolution counterpart. > This is a bug in PilRC, because it should complain and notify you of the > problem (Constructer does). That would be a *bug* in the font, and a *deficiency*, not a bug, in PilRC. What you have is a feature request, not a bug report. > I already posted this problem, but it has not yet been rectified. Patches welcome. Otherwise, thank you for the suggestion, and I daresay we will get to it when we get to it. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: CodeWarrior: #IF SIZEOF(struct) == X ?
Peter Easton <[EMAIL PROTECTED]> wrote:
> I'm looking to receive some kind of compile-time notification if a structure
> size isn't what I'd expect it to be. Something like:
>
> #IF SIZEOF(MyStructType) != 100 DISPLAY "Oops, there's problem"
Sadly the sizeof operator is not available in the preprocessor (see also
question 10.13 of the C FAQ).
The usual trick is to try to cause a compilation error by doing something
like
char foo[sizeof (MyStructType) == 100];
except that that's not quite good enough ("char foo[0]" is a valid
declaration e.g. with GCC in the absence of -pedantic), so the following
is better:
char foo[(sizeof (MyStructType) == 100)? 1 : -1];
That was cribbed from the Poser source code -- Keith discovered that
"char foo[0]" had become valid at some stage and improved the macro he
was using for the thing you want to do. Look at COMPILE_TIME_ASSERT in
EmCommon.h for details.
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: GCC and trap calls
Joshua Richie <[EMAIL PROTECTED]> wrote: > I am trying to use the Garmin SDK with GCC Man, am I sick of SDKs that require you to register before you can download them :-(. Fortunately this one doesn't ask for too many details... > Anybody have any idea's how to fix this warning, or what it > means? warning: possibly bad __callseq__ `trap #15; dc.w = 0xA805' It means the usual thing: Garmin have followed an out-of-date sample of how to arrange shared library headers that doesn't support GCC developers out of the box. Happily it's very very easy for them (or you) to fix this so that the headers work with both CW and GCC just fine: http://www.escribe.com/computing/pcpqa/m47622.html It would appear that you've already done something like this (otherwise the warnings would be complaining about "trap #15; dc.w gpsLibTrapClose" and so on) and that you've changed GPSLibSysTrapNums.h's first entry to be something like #define gpsLibTrapClose = sysLibTrapCustom Clearly the thing to do is to get rid of the "=" :-). John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Compiler bug? Index error switching from static const "char" to "Char"!
Gregg Woodcock <[EMAIL PROTECTED]> wrote:
> John Marshall <[EMAIL PROTECTED]> wrote:
>> Hmmm. I noted my sources (ISO/IEC 9899:1999 6.7.8/11). What are yours?
>
> Those sections apply to scalars; we are talking about aggregates (arrays).
The text I quoted is actually from paragraph 14, which is in the part that
does apply to aggregates (as is obvious from the quote). Mea culpa. (The
same text appears as paragraph 14 in the FDIS you refer to.)
> #17 on page 138 of the PDF (page 126 of the document) says this:
> Each brace-enclosed initializer list [...]
>
> The key word is "list". [...] A list is essentially synonymous with
> an array.
What evidence do you have for this last statement about lists and arrays?
(Please quote chapter and verse from the FDIS.)
Consider that 6.1/2 says "initializer list" in the main text corresponds
to the "" nonterminal in the grammar in paragraph 1,
thus strongly suggesting that "list" in the main text is merely an
informal term referring to the syntax.
> #20 is more our case and it says this:
> If the aggregate or union contains elements or members that ar aggregates
> or unions [...]
(The aggregate in question is "const char threeChars[]" and it does not
contain any aggregate/union elements.)
This part of this thread started by trying to determine whether the
difference between the following definitions constituted Gregg's
essential problem:
static const char threeChars[] = {"123"};
static const char threeChars[] = "123";
It seems to me that the interesting thing to note here is that the
initializer has no effect on the type of the object being defined:
it's all determined to the left of the "=". Even if the values of
the two arrays differed, it would be surprising if that caused the
particular problem Gregg saw. Therefore it should be clear that this
minor syntactic difference isn't the essential problem.
On the other hand, it's no surprise that
static const char *threeChars = "123";
affects the essential problem, because the type of the object being
defined is different.
In fact, it turns out that, for historical reasons, you have a surprising
amount of leeway with braces in initializers -- see the examples after
section 6.7.8. So the values of the two arrays above are indeed the same.
This may well be an interesting discussion. But probably not here on
palm-dev-forum :-)
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Compiler bug? Index error switching from static const "char" to "Char"!
Gregg Woodcock <[EMAIL PROTECTED]> wrote: > You said, the 2 different definitions are "entirely different" [...] > In other words, the 2 are exactly the same There are *three* definitions under consideration. One is entirely different from the other two. >> No, it's a single dimensional array. > > No, it is a 2 dimensional array with a single element. Hmmm. I noted my sources (ISO/IEC 9899:1999 6.7.8/11). What are yours? John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Compiler bug? Index error switching from static const "char" to "Char"!
Gregg Woodcock <[EMAIL PROTECTED]> wrote:
> "Hildinger, Robert" <[EMAIL PROTECTED]> wrote:
>> Gregg's original code: static const char threeChars[] = {"123"};
>> Code from your reply: static const char threeChars[] = "123";
>>
>> Gregg's code may not be "perfect" C syntax, but it generates the same
>> exact code. The format of Gregg's definition for threeChars[] is
>> obviously NOT the essential problem.
>
> IT IS!!! I changed it to 'static const char *threeChars = "123";' and
> it works. The way I defined it initially DEFINITELY whacks out GCC
> compiler!!!
Your original code said "static const char threeChars[] = {"123"};",
which is an entirely different kind of thing.
The original one triggers the compiler bug Dave Lasker mentioned.
The other is entirely different and does not. A "GoodCoder" knows
the difference between these two instinctively; perhaps you want to
read the C FAQ or a book.
> My original definition is definitely wrong. It is defined as a 1
> dimensional array but is assigned a 2 dimensional array which has only 1
> element.
No, it's a single dimensional array. That initialisation is unorthodox
but not invalid. Here's what the C standard section on Initialization
has to say about this (C90 6.5.7; C99 6.7.8/11):
An array of character type may be initialized by a character
string literal, optionally enclosed in braces. [...]
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: publick acknowledge
kcorey <[EMAIL PROTECTED]> wrote: > I know I felt delicate the next morning after just 2 beers (maybe > 3?)...I can't imagine what your head must have felt like. And as Ken knows I was feeling rather delicate too, as was the carpet. :-) Thanks, Andrés, these sorts of emails are much appreciated! John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Change stack size in PiLRC
Caspar Heiden, vd <[EMAIL PROTECTED]> wrote: >> You can control the stack size with the "pref - Stack Size" setting in >> constructor. > > Could somebody please tell me how to do this in PiLRC? It's not particularly obvious why you would want to. If a stack setting resource is going to have any effect, it's because it's sitting alongside some executable code in a resource database that happens to be an application. That executable code came from somewhere. Most likely it came from Code Warrior, in which case it is apparently Constructor's job to put that stack size resource there, or it came from prc-tools, in which case it is build-prc's job. But perhaps you're using CW but not Constructor, or you're programming in assembler but not using CW or prc-tools's build-prc. In that case, you might want to search the PilRC manual for "stack". But see also http://www.escribe.com/computing/pcpqa/m63809.html John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: I admit to being a newbie, but this is driving me crazy. I have installed
David Barton <[EMAIL PROTECTED]> wrote: > I have performed palmdev-prep several times, and > *still* when I attempt to run m68k-palmos-gcc via the make file, I get the > "#error No genuine PalmOS.h" message, when it tells you "you may need to run > palmdev-prep". It turns out that Dave was in fact using palmdev-prep /usr/share/prc-tools and this was the cause of his troubles. Sadly, if one of those several times he had used just "palmdev-prep" by itself, everything would have been all right :-). /usr/share/prc-tools/include is already burnt into m68k-palmos-gcc's search path, and is searched *after* everything else. Telling palmdev-prep to look there added it at the _start_ of the search path, from where it was able to override the genuine headers in the SDK directories all the time, and everything went pear-shaped. In the next version of prc-tools, palmdev-prep will studiously ignore you if you tell it to look in that directory :-). John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: I admit to being a newbie, but this is driving me crazy. I have installed
Dave Lasker <[EMAIL PROTECTED]> wrote: > I got the identical error message when I tried prc-tools for the first time. > This was due to my installing SDK 5, but not noticing that the tutorial's > makefile includes the line: > > CFLAGS = -palmos4.0 $(DEBUGCFLAGS) Yes, but... While prc-tools 2.2 would give the "No genuine PalmOS.h found" message when you used a -palmosN option corresponding to an SDK that was in fact not installed, prc-tools 2.3 says m68k-palmos-gcc: Palm OS SDK requested via -palmosN could not be found While the "No genuine PalmOS.h" message was technically correct in this situation :-), prc-tools 2.3's message is hopefully more helpful. Dave L's theory is the most likely, but really only if Dave B is actually using prc-tools 2.2 rather than the current latest prc-tools (or if one of Dave B and me is mistaken about the message produced). If Dave B wants to send me his /usr/lib/gcc-lib/m68k-palmos/specs file, I will be able to make some more useful guesses as to what has gone wrong. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: I admit to being a newbie, but this is driving me crazy. I have installed
David Barton <[EMAIL PROTECTED]> wrote: > I have performed palmdev-prep several times What does palmdev-prep say when you run it? You want it to say something like Checking SDKs in /PalmDev sdk-5 headers in 'include', libraries in 'lib' When GCC is given no -palmos options, SDK '5' will be used by default (BTW the 5.0 R3 SDK is the most up-to-date one.) John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Telling if POSE running with debug ROM [Was: Migrating color indexes between screen depths]
Luc Le Blanc <[EMAIL PROTECTED]> wrote: > How can I detect I'm running under POSE, Well, I'm sure you know how to do that, or where to look in the Poser documentation or the archives to find out (e.g. type "detect" into the search box at escribe's emulator-forum archive). > and with a debug ROM? Look at sysFtrNumErrorCheckLevel in Core/System/SystemMgr.h. Hopefully it's set right on the ROMs you're interested in. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Array of struct - global vs local
Daniel Seifert <[EMAIL PROTECTED]> skrev: > Am Fr, 2003-11-21 um 16.32 schrieb Ton van Overbeek: >> If you compile your small test program with -S (=generate assembly) >> you see what is happening, For MAX=9 the cmd struct is initialized >> by code. For MAX=10 there is a copy in the .data section which gets >> copied to the stack at the start of the routine. > > Ah well, this explains everything. I seriously started to doubt my > sanity ;) Using -S and similar flags and *looking at what is actually going on* is a great last-ditch technique for saving your sanity. More people should use it more often :-). > Should I report this at prc-tools bug tracker? Sure. If you want to see me immediately close it as a duplicate of http://sourceforge.net/tracker/index.php?func=detail&aid=221845&group_id=4429&atid=104429 John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: GCC: Force 3rd party library into 2 different segments?
You still mean sections, not segments. Gregg Woodcock <[EMAIL PROTECTED]> wrote: > OK, now that you've had your fun (which is somewhat deserved), hopefully you > are willling to help me actually figure out WHY this does nothing for me. Dude, I have been helping you the whole time. (Meanwhile, you have not retracted or apologised for your "woefully inadequate" slight.) > Armed with the map file I can see that indeed, it is now (and actually > probably was in the beginning) creating a large(r) coderes segment as > evidenced by these 2 differences: > coderes 0x 0x8002 > coderes 0x 0xfcd0 Right, so in fact in all probability the thing you were casting aspersions at was working correctly all along. And happily we're now going to get on to the real problem. > The library itself is actually 23080 bytes but the author told me that > this gets trimmed by the linker (for my type of use) to about 4K (I am > only using 3 functions out of the 40 or so). The most likely reason for your problem is that the author is mistaken. Look at your library with "m68k-palmos-ar tv libfoo.a". If you see dozens of small .o files, corresponding more or less to the separate functions in the library, then the linker in prc-tools-m68k will be able to pull in only the .o files it needs and your executable will not become bloated with functions you are not using. If you see only one monolithic .o file, then the author does not know how to build a Unix-style static library. > So the REAL problem I am having is that the compiler is including ALL the > library instead of just the pieces I am actually referencing/using. Perhaps > I have settings of the linker so that it is not properly discarding unused > library code? In Code Warrior, a library is really just an object file. CW uses an object file format in which functions and function-static data and so on are stored in separate hunks within the object file. It is this arrange- ment into separate per-function hunks that allows CW's linker to strip unused functions and their data from inside an object file. To the GNU linker, as on Unix for decades, a library is a collection of object files. If several functions are in one object file, then they are all smooched together into the same sections. They are not separable. The linker used in prc-tools-m68k DOES NOT DISCARD UNUSED FUNCTIONS. Rather, it only pulls an object file in from a library if that object file provides a function (or a symbol) required to satisfy the link. The atomic unit is an object file, not a function [1]. Once an object file has been pulled in, any unused functions in that object file cannot be discarded, because there is no way to separate them from the other functions in the object file. Thus a badly built monolithic linker library causes the bloating effects you are seeing. The GNU linker does in fact support similar behaviour to CW on some platforms. A combination of GCC's -ffunction-sections flag and the linker's --gc-sections produces an explosion of separate sections that provide similar capabilities to CW's object format's hunks. But these flags are not supported on prc-tools-m68k at this time. > 1) Is there a way to specify which functions in a library go into which > segments (remember, all I have is the .h and .a file; it isn't my library)? > If I modify the .h file with the SECTION_X postfix, will that work? As noted in the documentation and in the archives many many times, the SECTION_X annotation needs to be visible (in particular) when the function to which it refers is compiled. If you annotate the .h file but do not recompile the .a archive, this will obviously not hold. No, that will not work. > 2) Is there way to force the compiler to evaluate which functions are > actually used BEFORE it stakes out space for them in the codres so that it > will not consider unused ones? Have the library built correctly. John [1] Well, really the atom is a section within an object file. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Makefile example using "-T text_64k" (PLEASE)?
Gregg Woodcock <[EMAIL PROTECTED]> wrote:
> Yes, however the documentation DOES NOT CONTAIN the referenced
> information/content! I challenge anyone to find it (I have looked deeply).
What are you offering as a prize in your challenge?
> In any case, the documentation should be updated to say that the switch
> should be added to the line that contains the -sections.ld parameter
> (not the line that contains the "-c" switch).
What the documentation you read says, in part, is "[use] the `-T script'
linker option". Apparently there are people in this world who do not
infer from this that the option should be given to the linker.
I've updated it to say "linker" several more times for the benefit of
such people.
> The missing content ("liker scripts" and "ld" dox) should be added to
> the html
Presumably you mean _linker scripts_ and the ld _docs_.
Actually they're already there. I've gone to a lot of effort to make
that general documentation available to you in HTML form. You can find
links to those manuals at http://prc-tools.sourceforge.net/doc/ , right
alongside "the html" you read. And if you install a prc-tools-htmldocs
package from http://prc-tools.sourceforge.net/install/ you'll have it
all locally in HTML form.
And if you are using a real operating system, you probably already have
it all installed locally in info format.
> and the "-T" (should be "-t") typo fixed.
As Ton noted, no typo.
It might be worth changing the suggested usage to "-Wl,-T,text_64k",
which would more reliably warn idiots who (mis)use it at compile-time,
but the advantage is offset by the probability of said idiot mistyping
all that punctuation and posting questions about that instead :-).
> Were it not for that typo, I'd have figured this out fairly quickly
> myself even without the missing content.
Sure :-)
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Palm SDK header files fail gcc -pedantic!?!
Gregg Woodcock <[EMAIL PROTECTED]> wrote:
> I cannot run gcc compile with "-pedantic" as the Palm SDK are non-compliant
> with strict ANSI C standards. The big offender is non-int enums declared
> like this:
> typdef enum { UP, DOWN, LEFT, RIGHT } DirectionType;
> instead of like this:
> typdef enum { UP = (int)0, DOWN, LEFT, RIGHT } Direction Type;
> so as to explicitly confirm to ANSI standard of enums as "int".
I have no idea what you are talking about. Your example is entirely
compliant (modulo typos), and your suggested fix would have no conceivable
effect even if it were not.
Presumably you are referring to
warning: ANSI C restricts enumerator values to range of `int'
which appears 11 times when you compile the 5.0 R3 headers with -pedantic.
(This would have been *so* much easier if you had just *shown us* the
diagnostic message that was of concern.)
There is a point of view that says this warning should not appear for
code in a system header (in the absence of -Wsystem-headers). Indeed,
later versions of GCC do suppress this warning in system headers, like
they suppress other similarly trivial warnings in system headers. So
this could be construed as a bug in the 2.95.3 GCC we are using on m68k
Palm OS; perhaps someone will look into it, and certainly the diagnostic
would go away with a new compiler version.
The code in question is of the form
enum { foo = 0x8000 };
and the warning refers to the fact that, in portable C, enumerators can
be no bigger than ints, and in the m68k Palm OS ABI ints are 16 bits.
But, when it comes from the Palm OS SDK headers, this is not an especially
interesting warning because code that uses the Palm OS SDK headers is not
particularly portable beyond Palm OS, and all Palm OS C compilers in fact
support the extension of allowing larger enumerators. And the Palm OS SDK
headers depend on this -- in 11 places.
Now let's look at the value of such an enumerator:
long bar() { return foo; }
This function returns 32768, of course. But when compiled with -pedantic,
GCC 2.95.3 emphasizes the undefined behaviour by having bar() return 0.
Thus using -pedantic has changed the meaning of your program. This is,
to be sure,... surprising. But it means that using -pedantic on Palm OS
in production builds is probably a mistake, especially if you use any of
those 11 enumerators.
Welcome to Palm OS. Doctor, it hurts when I use -pedantic. Well, don't
do that then.
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Makefile example using "-T text_64k" (PLEASE)?
[I am unsure which of "PLEASE" in the subject line and "woefully inadequate" makes me less inclined to help you. Nevertheless...] Gregg Woodcock <[EMAIL PROTECTED]> wrote: > The only dox/info I can locate online are woefully inadequate: > http://prc-tools.sourceforge.net/doc/prc-tools_3.html > > As I understand it, this allows the primary code segment (#1) to grow (more > or less) up to 64K (instead of the default 32K). Does this apply to all > code segments? You mean code sections, not code segments. You are using neither Code Warrior nor ELF, so there are no segments anywhere. I think it is clear from the documentation that this particular linker script affects only the main, default code section, namely .text. If you think about where the sizes of other code sections are specified (namely in the .ld file generated by multigen), this becomes even more obvious. > I gather/assume it > goes on the compile line (although I don't understand why it is called a > liker script parameter if that is correct) and have been using it like this: > > m68k-palmos-gcc -T /PalmDev/PRC-Tools/usr/m68k/palmos/lib/text64k -c myapp.c The documentation you have found says the "maximum size of the main code section is specified in the linker script and enforced during linking". The "-c" on your command line means that you are only compiling, not linking. > Is there a way I can know for sure the linker script is being run? -v -Wl,--verbose -Wl,-Map,foo.map In general, you would only expect a linker script to be of interest during linking, not compilation. For example, that is why the documentation you have found suggests that you read about linker scripts in the linker documentation if you are confused. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Static functions
Michael Yam <[EMAIL PROTECTED]> wrote:
> I think the C standard defaults to static function declarations.
Uh, no. But there is potential for confusion between the requirement
for a declaration, and a function's staticness.
// Translation unit a.c
int foo() { return 1; }
int bar() { return 2; }
static int baz() { return 3; }
// Translation unit b.c
extern int bar();
extern int baz();
int PilotMain() { return foo() + bar() + baz(); }
All is well with bar(). You will probably get a diagnostic in b.c that
there is no declaration for foo(); this is an error in C++ and possibly
also in C99, but was allowed back in the prehistory of K&R C. But it's
always been considered bad style.
OTOH baz() will fail to link. Effectively the baz() declaration at
the top of b.c refers to a different (non-existant) baz() from the
file-static one defined in a.c.
> For calls from other programs, you'll need to remove the static
> declaration and declare the function extern in a header file.
s/other programs/other translation units a.k.a. source files/
> "rguevara" <[EMAIL PROTECTED]> wrote
>> A little question, is obligatory the declaration of static of the
>> handlers functions?
Short answer: the handler function's name is only used in the nearby
FrmSetEventHandler() call, so it might as well be file static. This is
just the normal C meaning for a static function, and it doesn't really
make too much difference here. You see this idiom frequently on Palm OS
because it silences a Code Warrior warning. For us GCC users, it doesn't
matter -- GCC's warnings here are designed differently, and we avoid the
spurious warning even without the hint.
Long answer: for your reading pleasure, I have looked in the archives
and found Neil's canonical answer to this question. If you are reading
this message at escribe.com, you can find it via the simple expedient of
clicking on "All messages in this Thread"; otherwise the direct link is
http://www.escribe.com/computing/pcpqa/m31329.html
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: MutliSegment question, again....
(You still mean "multi-SECTION", not "multi-segment".) rguevara <[EMAIL PROTECTED]> wrote: > according to page of the PRCtools, the Pilotmain and the functions > that calls directly must go in the first segment, but single those of > first level of call. Because but all the program would go in the same > segment and segmentacion would not have sense. Some idea? Here is the quotation from the documentation: [Y]ou must not attempt to call between different sections when globals are not available. In particular, all functions in your application called while processing a launch code that doesn't give you globals must be in the main code section. This always includes PilotMain, which is always called by the startup code for all launch codes. What you are missing is *while processing non-globals launch codes*. Yes, the whole program used while processing non-globals launches must all go in the same (main, default) section. There's no surprises there. (And Dave's belief is simply a restatement of that quotation.) John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: MultiSegment code
Aaron Ardiri <[EMAIL PROTECTED]> wrote: > free compilers sometimes require you to think. Unfortunately expensive compilers have the same requirement about equally often. Ditto non-free compilers. Rguevara should go back to the original makefile and my first response, which did contain a fairly explicit clue to the one word that needs to be added to the original makefile to make it work. (My second response even shows which line that one word needs to be added to.) John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: MultiSegment code
rguevara <[EMAIL PROTECTED]> wrote: > $(APP): $(SRC:.c=.o) $(SECTIONS).ld >$(CC) $(CFLAGS) $^ -o $@ If it should happen that you don't know what this means, then I suggest that you write it out using simpler make constructs -- for example, two simple lists of the .o files and other files (namely AdmnDI-sections.ld) that need to be presented to the linker. You would then find the mistake easier to see. > This is based in the multiapp example Makefile If it were indeed based on the multiapp makefile in the prc-tools samples available from http://prc-tools.sourceforge.net/, then it would be half the length it is and much clearer. I suggest you study that makefile and yours and the documentation to which you have been pointed, so that you can find the significant difference between that makefile and yours. You have been given all the information you need to find the mistake in your makefile. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: MultiSegment code
(You mean "multi-section code", not "multi-segment code".) rguevara <[EMAIL PROTECTED]> wrote: > the file .ld generated is: > > /* DO NOT EDIT! > This file was automatically generated by m68k-palmos-multigen v2.2 > from AdmnDI.def */ > >.file "AdmnDI-sections.s" No, that's the ".s" file, and you've neglected to do anything with it. > AdmnDI.o: In function `PilotMain': > AdmnDI.c:1876: undefined reference to `__text__adm' Not including it in the link causes the problems you are seeing. Look at the documentation or a sample to see what you should be doing with it. http://prc-tools.sf.net/cgi-bin/info/breaking+up+an+existing+application > i don't find one example of multisegment code with the handler functions There is one available at http://prc-tools.sourceforge.net/ . John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Why won't this work?
Dave Ellis <[EMAIL PROTECTED]> wrote: > Any ideas? Evening classes? John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Initializing gadget data with a struct
Ben Combee <[EMAIL PROTECTED]> wrote: > At 09:55 PM 11/11/2003, Luc Le Blanc wrote: >> Can I do the same to read the gadget data with FrmGetGadgetData or do I >> absolutely have to use a union? I don't understand. Why *wouldn't* you want to use a union? > Try > > UInt32 data = (UInt32) FrmGetGadgetData( ...); > UInt16 val1 = data >> 16; > UInt16 val2 = data & 0x; > > to extract the values. You can do that bit-twiddling everywhere manually, or you can use a union and have the compiler do it for you. What's the downside? (Yes, you should probably add "assert (sizeof (struct GadgetData) == sizeof (void*))" somewhere, but you need to do that with the manual alternative too.) John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Define OS
Anders Rahm-Nilzon <[EMAIL PROTECTED]> wrote: > What flag do I use to check if I'm running on PalmOS or Windows s/running on/compiling for/ presumably. See http://prc-tools.sourceforge.net/faq/ ; and you'll find something more or less similar in the CodeWarrior documentation if that's what you're using. Or just predefine something suitable in your project's build systems: after all, your makefiles and their equivalents select different compilers depending on what you're building, so they can certainly select different -D options and/or prefix files too. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: MultiSegment Assistance needed
James Zatorski <[EMAIL PROTECTED]> wrote: > $(PRC): bin.stamp $(APP) $(DEF) >$(BUILDPRC) $(DEF) $(APP) # [Your mistake is here] [...] > bin.stamp: $(RCP) $(APP).bmp smallicon.bmp >$(PILRC) $(RCP) $(BINDIR) >touch bin.stamp Look carefully at your makefile. This was nothing to do with 32K limits or multiple code resources; it's just that you made a mistake while changing your makefile. This part of your makefile would become clearer if you joined the 21st century and used PilRC's -ro flag: $(PRC): $(APP) $(DEF) $(APP).ro build-prc $(DEF) $(APP) $(APP).ro $(APP).ro: $(APP).rcp $(APP).bmp smallicon.bmp $(PILRC) -ro $(APP).rcp It might look even clearer if you got rid of even more make variables, but I digress... :-) John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Initializing gadget data with a struct
Luc Le Blanc <[EMAIL PROTECTED]> wrote:
> typedef struct
> {
>UInt16 color;
>UInt16 resID;
> } GadgetData;// same size as a void *
[...]
> GadgetData data;
[...]
> FrmSetGadgetData( form, FrmGetObjectIndex( form, PrefsTraceColorGadget
> ), ( void * ) data );
>
> But the CW 8.3 compiler refuses this explicit cast to void *. What's
> wrong?
This has nothing to do with Palm OS, of course.
If you asked on whichever of comp.lang.{c,c++}.moderated is appropriate
for the language you're asking about, they might tell you that cast is
in fact not all-powerful, and that the operand of the kind of cast you
are using must be of a scalar type (and your struct is, of course, not
a scalar).
They might also suggest that you use a union instead:
union { GadgetData gd; void *vp; } u;
u.gd = data;
FrmSetGadgetData (form, FrmGetObjectIndex (...), u.vp);
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Tell GDB not to break in PilotMain?
Dave Lasker <[EMAIL PROTECTED]> wrote: > Do you have an online pointer to the pilot.programmer.gcc thread "GDB and > POSE's Gremlins"? If I had had, don't you think I would have posted it? ;-) However I've been home and looked at my archives now, and the Poser 3.5 patch is quite simple: In SrcShared/EmException.cpp: Remove the Hordes::Stop() call in EmExceptionEnterDebugger::DoAction() This prevents the gremlin from stopping when it sees the debugger continue over the fake PilotMain() breakpoint. Hopefully it doesn't also prevent the gremlin from stopping when you drop into the debugger for real; it's been a long time and I don't remember. > Do you have any equivalent advice for users of the Simulator? Perhaps I would care more about the Simulator if it were available for my platform of choice, but I digress... :-) > I have not been able to figure out how to attach GDB to the simulator > after a gremlins run has started, due to the need to enable gdbpanel. All that GDB Panel really does is set a particular feature, as described in the documentation. Perhaps you could use the Simulator's scripting interface to set it at an appropriate time via a Perl script or so. Or add to your own PilotMain() to set it on the 15th invocation or whatever. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: What's wrong?
Edmund <[EMAIL PROTECTED]> wrote: > I really don't think the castings are needed, because from > the function declaration the compiler should have enough infomation on > the data type of the parameters! If you think the compiler should have enough information from the function declaration, then you should check that the compiler has seen the function declaration. (Hint: it hasn't.) Better still, you should get the compiler to check that it has seen your function declarations. > Could anybody give me some advice? Turn some compiler warnings on. Always. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Tell GDB not to break in PilotMain?
Laurens <[EMAIL PROTECTED]> wrote: > How can I tell the GDB debugger (PRC Tools) not to break in PilotMain? http://prc-tools.sf.net/cgi-bin/info/Palm+OS-specific+GDB+features > I'm running Gremlins in POSE to stress test my app. One bug occurs > somewhere between step 2000 and 3000 and I want to pinpoint the line > where it happens. However, the Gremlin taps the Find function (in the > silkscreen area) at least two dozen times before I get to the bug, > forcing me to manually "continue" everytime the OS calls PilotMain. Once you're using "handle SIGSTOP nostop", GDB won't require manual assistance every time through PilotMain(). Unfortunately you may find instead that the *gremlin* stops each time, requiring a manual tap on "resume" in Poser's dialog box. At http://www.escribe.com/computing/pcpef/m4386.html you'll find a pointer to a one-line Poser patch that stops the gremlin from tripping over each time, and also a clever trick which can be summarized for you as "only attach GDB after 1950 or so events, so hopefully it'll only go through PilotMain() a couple of times (but more than zero) while the debugger is connected". > Alternatively, is there a way to disable the Find function in POSE, or > instruct the Gremlin not to tap there? #ifdef DEBUG_BUILD if (HostGremlinIsRunning () && event_is (vchrFind)) eat_event (); #endif or words to that effect, probably. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
New news server broken
Régis St-Gelais wrote:
> Since the October 19 shutdown my news reader is no longer able to
> connect to the news server
The problem is at least two-fold.
$ host news.palmos.com
news.palmos.com has address 216.91.57.210
news.palmos.com is an alias for palm.lyris.net.
palm.lyris.net has address 64.62.197.105
The 216.x.y.z address refuses NNTP connections, but the 64.x.y.z one
does have a news server on it. So you can connect directly to either
palm.lyris.net or that IP number until the DNS records get sorted out.
But once you connect to it, you may find that you cannot authenticate
yourself. The news server now replies to AUTHINFO USER with 281 ("go
ahead") when it really means 381 ("password required too"). This is
a violation of RFC 2980, and is a serious bug in Lyris. It will prevent
any correctly written NNTP client from being able to authenticate itself
via the original authinfo method.
If you can select a different authentication method and Lyris understands
it, then you may be able to get on. Otherwise we're all screwed until
Lyris fixes this bug or we kludge our clients.
This is not the only new bug in the news server since the weekend's
upgrade. It also replies to the STAT command with 220 instead of 223,
which is a violation of RFC 977. On the other hand, RFC 977's "current
article pointer" now finally works in Lyris, so I'll be sending a lot
fewer STAT commands.
I'm getting pretty tired of rewriting my scripts to work around Lyris's
bugs :-(. The amount of money PalmSource has donated to the Lyris
corporation by now could have bought Amy an awful lot of INN training!
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Palm SDK
Mark Lenz <[EMAIL PROTECTED]> wrote: > I went to the Palm Source website to see if there was an updated SDK. Look again. There is now a 5 R3 SDK there that includes PalmOSGlue etc for prc-tools. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Globals, StrPrintF, StrIToH
Brian Smith <[EMAIL PROTECTED]> wrote: > [I'm using PRC-Tools 2.3 and it s]eems that a type cast from double > to Int32 is what's causing the problem (adding about 3k of code and > apparently a global or two). A conversion from double is involved: no surprises there :-). See particularly http://www.escribe.com/computing/pcpqa/m58918.html and also part of http://www.escribe.com/computing/pcpqa/m59465.html and some of the background here may also be interesting: http://www.escribe.com/computing/pcpqa/m35274.html John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Tungsten T2 Linux programming & Bluetooth
Jan Bandouch <[EMAIL PROTECTED]> wrote: > I want to develop under Linux. I know that there's the PRC-Tools > (Compiler + Debugger), and a couple of emulators, but I'm searching for > something to easily create GUIs for the Palm. I suspect that most people on Unix, believe it or not, just lay out their GUIs by writing text descriptions directly in the .rcp language. > But how can I write Bluetooth applications for PalmOS under Linux using > gcc from PRC-Tools? As far as I understand this, the official Bluetooth > SDK from Palm isn't available for Linux. The current official SDK to use for Bluetooth is the 5.0 R3 SDK. You can download a zip archive of it, unpack it on Linux, and convert the line termination, and you'll have the header files -- which are all you need to do Bluetooth stuff. And a little bird tells me that using the 5.0 R3 SDK on Unix will get even easier in the not too distant future. (Oh, and please don't crosspost :-).) John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: GDB and Palm Simulator
Scott Thibault <[EMAIL PROTECTED]> wrote: > I can't seem to get GDB to work the Palm Simulator. It works fine with > POSE, but when I run it with the simulator it does not seem to understand > address. The following is noted in the manual [1]: * The Palm OS Emulator (version 2.1d22 or greater) sets [something up that's important for GDB] * GDB Panel, in the prc-tools samples [2], is a small Palm OS application which [also sets that something up]. You need to use it or something similar when debugging on a real device or on the Palm OS Simulator. John [1] http://prc-tools.sourceforge.net/cgi-bin/info/using+a+debugger [2] http://sourceforge.net/project/showfiles.php?group_id=4429 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Error in PilRC ??
Jeff Collett <[EMAIL PROTECTED]> wrote: > Would > # pragma once work? Of course not. The problem here is that PilRC contains only a rudimentary preprocessor. That's not too surprising, because PilRC's interests lie in being a resource compiler, not a preprocessor. "#define" is about the most commonly used feature in this preprocessor, and the problem that's been encountered is that PilRC supports only a subset of the expressiveness of the full C preprocessor's #define. "#pragma once" is an obscure directive supported as an extension by a few C preprocessors, and you can be sure that PilRC does not support it, nor IMHO should it. It'll probably be worth extending PilRC's subset so that "#define blah" is accepted, even though "#define blah 1" is an entirely adequate work- around. Then next month someone will want macros with parameters. And next year someone else will want #pragma once. Where does it all stop? IMHO it would be a waste of effort to try to add a full preprocessor to PilRC; and if you're going to use PilRC's approximation of a preprocessor you probably need to learn to live with its limitations. People who want the full C preprocessor know where to find it. For example, with prc-tools 2.3 and a recent enough PilRC (a 3.0 beta from within the last couple of weeks) you can write m68k-palmos-gcc -c foo.rcp to have foo.rcp passed through a *real* preprocessor before it is given to PilRC. And that's the proper division of responsibilities! :-) John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Warnings and Errors while trying to use CollapseUtilSony.cpp (Dynamic Input Area, GCC/PRC-tools on Windows)
Ralf Zimmermann <[EMAIL PROTECTED]> wrote: > For this test, I am using GCC/PRC-tools on Windows under CygWin. [...] > In file included from /PalmDev/sdk-5/Incs/libraries/SonyLibPublic.h:28, > from /PalmDev/sdk-5/Incs/SonyClie.h:29, > from CollapseUtilsSony.c:2: > /PalmDev/sdk-5/Incs/libraries/SonyHRLib.h:203: warning: possibly bad __callseq__ > `trap #15; dc.w HRTrapGetAPIVersion' [...] > What am I doing wrong? You are doing nothing wrong; this is a bug in Sony's SDK. It's been there for several years, so you would think they would have been able to fix this by now :-(. http://www.escribe.com/computing/pcpqa/m47622.html John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: build-prc.exe error!!
On Sat, Sep 20, 2003 at 03:21:31AM +0800, Mohammad Afshari wrote: > I'm kinda dying here, beacuse i cant get my build-prc.exe going. [...] > "the procedure entry point __getreent cuold not be located in the dynamic > link library cygwin1.dll" This is not a build-prc problem. It is a Cygwin problem: you have several cygwin1.dlls installed and the one that has been found is really really old. Don't do that. http://cygwin.com/faq/faq_4.html#SEC51 John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: ClipboardGetItem and StrNCopy
Jan Slodicka wrote: > I thought that a check for cmdptr!=NULL was redundant as cmdptr is obtained > from a non-NULL handle. You're right of course -- I was thinking of checking hCmd != NULL, which you are indeed doing. Sorry, it was a late night last night! > (The string on the clipboard was non-empty.) I would have thought you would get "access past end of chunk" in that case rather than "low-memory access", but yeah, any way you slice it the current StrNCopy is not going to work in that case either. So my suggestion wasn't very helpful -- sorry. My analysis three years ago was better; maybe I had slept the night before I posted it :-). > Strange - I searched the forum for ClipboardGetItem string before posting, > but did not receive the links you list bellow. The more recent one (which is a good read, if I say so myself :-)) was on emulator-forum. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: ClipboardGetItem and StrNCopy
Jan Slodicka wrote: > MemHandle hCmd = ClipboardGetItem( clipboardText, &cmdLength) ; [...] > StrNCopy( cmd, cmdPtr, cmdLength ) ; // This fails on accessing > low memory address [...] > The problem is that StrNCopy() accesses cmdPtr[cmdLength]. The cure to > the problem is to replace StrNCopy by MemMove. Or to check that cmdptr/cmdLength are non-NULL/0 before calling StrNCopy, perhaps? > I guess if StrNCopy was implemented differently (if the test on the > string length preceded the terminator test), there would not be any > problem. Yes; one could paraphrase this fix as "make StrNCopy act more like strncpy" (details in my reply to the more recent thread below). This issue last came up three years ago: http://www.escribe.com/computing/pcpef/m1998.html and the previous time was apparently two years before that: http://www.egroups.com/message/palm-dev-forum/2812 John "stay tuned for a reappearance in 2007? :-)" -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
ANN: prc-tools 2.3 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Version 2.3 of prc-tools has been released. Source code and binary packages (for x86 Linux and Microsoft Windows) are available from http://prc-tools.sourceforge.net/ New features include a substantially rewritten (partial) standard C library, new utilities and updates to various existing ones, and an update to the current releases of binutils, GDB, and, on the ARM side, GCC. For further details, see http://prc-tools.sourceforge.net/releases.html The various packages available have the following MD5 checksums: efd6ba91d23b5f5e67b3b2217dd74894 prc-tools-2.3-1.i386.rpm ae1d0e0b2aad3ceeb163c4170f322a2c prc-tools-2.3-1.nosrc.rpm fb7bef9542d3ce6957535fd8315fcf0f prc-tools-2.3-cygwin.tar.bz2 038a42a71a984fee6f906abc85a032ec prc-tools-2.3.tar.gz dad8cf5ea0a3fdf0c4973fbee628a1e5 prc-tools-arm-2.3-1.i386.rpm 3bc19ac45a9aaee9f790b67f63f8cf97 prc-tools-arm-2.3-cygwin.tar.bz2 982e9fad55c81b90fecfd27fb51e8a6b prc-tools-htmldocs-2.3-1.noarch.rpm bfe8f60a69b5ccfa3d247567150d463a prc-tools-htmldocs-2.3-cygwin.tar.bz2 92ad5fa75398894d0d9e4614b66b711a prc-tools-htmldocs-2.3.zip The RPM packages and this announcement have been signed with the PGP/GPG key 1024D/AC686552, which is available from, amongst other places: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xAC686552 http://prc-tools.sourceforge.net/misc/jmarshall.asc (Followups to tools-forum, please.) John -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/amo8mnA+caxoZVIRAjY6AJsEk6xewJQzIeXTm/co9x6eD2RDiwCdH/vs c1kAYnGh2pP3VOFVfEUbg1Q= =RcZn -END PGP SIGNATURE- -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Developing a launcher
Lance Gregory <[EMAIL PROTECTED]> wrote: > Is there a way to make my launcher run instead of the default palm > launcher? So I typed "launcher" into the search box at the escribe.com palm-dev-forum archives, and sure enough... Lance, I'm not sure you're taking full advantage of the resources already at your fingertips! :-) Sadly, of the three answers given back in July only Dave Carrigan's was especially correct. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Developing a launcher
Lance Gregory <[EMAIL PROTECTED]> wrote: > I am not familiar with what HB++ is. I appreciate your answer. So I typed "HB++" into Google, and sure enough... John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: HostFEOF() doc error?
On Mon, Sep 08, 2003 at 12:22:06PM -0500, [EMAIL PROTECTED] wrote: >[HostFEOF()] Returns 0 if the specified file is at its >end, and a non-zero value otherwise. > > But I observe the opposite behaviour. I.e., HostFEOF() returns 0 is *not* > at end and non-zero if at end. > > Can somebody confirm this? You can confirm it yourself; such is the wonder of free software :-). A quick look at the Emulator's HostControl.cpp shows that (surprisingly enough) HostFEOF() just calls through to your host's C library's feof(). Taking as read the assumption that your host is not completely insane, we can conclude that HostFEOF() returns an indication of truth (i.e., non-zero) when the file is at EOF, as you have observed, just like every other variant of feof() in the C universe. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: .bss full?
On Thu, 21 Aug 2003, Khaki Wizard <[EMAIL PROTECTED]> wrote: > /usr/m68k-palmos/bin/ld: region datares is full > (xx section .bss) [...] > Why is .bss full? It is the datares region that is full, and this fact has been detected when an item in .bss was pushed out past the limit. But these facts do not necessarily imply that .bss is full. The datares region consists of .data (initialised data) followed by .bss (uninitialised data). It is more likely that .data is too large. This might just have happened behind your back; for example, the reasoning behind the suggestion to "drop C++" can be found at http://prc-tools.sourceforge.net/faq/ (dropping C++ entirely would be an overreaction to the problem). If it is in fact .bss that is too large, the solution is very simple. Your code contains an uninitialised global array: int my_huge_global_variable[1]; You need to change it to be dynamically allocated instead: int *my_huge_global_variable; ... my_huge_global_variable = MemPtrNew (1 * sizeof (int)); ... MemPtrFree (my_huge_global_variable); You don't even have to change any of the code that accesses it. > Is it because there is too many > reloc entries. As I know, they should be in .data > section. On m68k Palm OS, the only relocations that are of interest after linking are those in the .data section. Starting with version 2.0, prc-tools stores them after linking in a format that takes up a constant (and in fact trivial) amount of space regardless of the number of relocations. So no, there are not too many relocs. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange problem with multi-section
On Thu, 21 Aug 2003, Khaki Wizard <[EMAIL PROTECTED]> wrote: >John Marshall wrote: >> These are messages from build-prc, not m68k-palmos-g++. >> Congratulations; this diagnostic is not easy to produce. > > Actually it is the output of obj-res. Ah. Well, that would be the *easy* way to produce this diagnostic. As you have found, there is not enough information available to obj-res for it to correctly process an executable with multiple code sections. That is why the manual tells you to use build-prc directly on the executable, rather than via obj-res, if you are building something with multiple code sections. > Could you tell me how to figure out where is > something like ".data+0x1998". I can't find it in the > objdump output. Or I may use some options? You want to look at the symbol table with "m68k-palmos-objdump -t". However that listing is not in a particularly legible format, so it is probably easier to look at the link map produced by linking with "-Wl,-Map,foo.map" or to look at the symbol table with m68k-palmos-nm. "m68k-palmos-nm foo | grep ' [dD] '" will show you just the symbols that are defined in the initialised data section. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange problem with multi-section
On Wed, 20 Aug 2003 11:45:44 -0700 (PDT), Khaki Wizard wrote: > When I multi-sectioned my C++ program, g++ has some warnings like: > g2palm:.data+0x1998: warning: reloc relative to > strange section 'SECT2' These are messages from build-prc, not m68k-palmos-g++. Congratulations; this diagnostic is not easy to produce. The most likely way to get it is via putting a section attribute on something that is not code. (Because the name of the technique is "multiple *code* sections", it's not easy to imagine why anyone might do that :-).) You probably also have to initialise some other global variable to point to that something. Where do your "SECT1" and "SECT2" section annotations appear? Only on functions, one hopes (and conceivably on constant data, but here there be dragons). You can track this down even more quickly by using objdump or nm to find out which of your global variables is at .data+0x1998, and looking at its initialiser. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: prc-tools question
On Fri, 08 Aug 2003 08:04:29 -0500, Mark Slagell <[EMAIL PROTECTED]> wrote: > # palmdev-prep > Checking SDKs in /opt/palmdev > sdk-4 headers in 'include', libraries in 'lib' [...] > When GCC is given no -palmos options, SDK '4' will be used by default [...] > Next 'make' had the same "no genuine PalmOS.h found" error. *Read* that error message. Your samples' makefiles contain -palmos options for some SDK that you do not have installed. > I had tried to install prc-tools from sourceforge before I went to > palmos.com -- so maybe it's still trying to use the failed sourceforge > install. You didn't mention a failed Sourceforge install. And in fact you might notice that the palmos.com page sends you straight to sf.net. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Build-prc: multisegmented code
Madhav Pulapaka wrote: > This took care of the linker errors but now build-prc is not able to > process my BFD executable, showing me the following: > >build-prc myapp.prc myapp.def myapp *.bin >myapp.prc: resource 'code' #1 is missing You need to reread what the instructions say about definition file use requiring the use of the new-style build-prc syntax. You mean "-o myapp.prc"; or just omit it, because that will be the default. Admittedly I'm surprised that that was the particular error message you got! That might warrant looking into. > OBJS = file1.o file2.o file3.o MathLib.o myapp-sections.o > CFLAGS = -Wl,-Map -Wl,myfile.map (If he wants to get a map file, that's great -- although I never know why people don't use -Wl,-Map,myfile.map if they're going to use the comma syntax :-); he *is* using myapp-sections.s as well.) John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Starting up, sorta
On Mon, Jun 23, 2003 at 01:32:07PM +0100, Paul Johnson wrote: > Crap, one other thing I meant to ask. Is there a compiler #define I > can pick up from somewhere to tell that I'm targetting a palm device ? Please consider reading the FAQ and documentation, available at http://prc-tools.sourceforge.net/>. > Even better if it has the o/s version munged into it. The buzzword to look for in the documentation here is NewTypes.h. > I'm using falch.net devstudio if it makes a difference. It does. It's always good to mention what tools you are using when you are asking questions about what your tools provide :-). John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Setting custom file attributes?
On Tue, Jun 03, 2003 at 02:58:49PM -0700, Jeff Ishaq wrote: > I advised that if the files are in the PDB format, then that custom flag > may be stored in the appInfo block; if the files are in raw format [...] Thanks for the summary; I did actually read your posting. It seemed to me that the O.P.'s "it would make a section of code I'm writing *much* simpler" comment suggested that he was well aware that he could store his flag somewhere else (necessitating some form of lookup) in various ways, and IMHO a response merely telling him to do just that could be construed as condescending or something... :-) I thought the original question was kind of interesting, y'see. He didn't actually tell us what these files are. If they're a bunch of internal files that only his application accesses, perhaps he can (ab)use one of the existing attributes for his nefarious purposes, or even encode the bit into judicious filename modifications. But probably these files are user-visible or used by other applications, and these tricks would have undesired side-effects. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Setting custom file attributes?
On Mon, Jun 02, 2003 at 09:32:02PM -0400, Richard Coutts wrote: > I'm wondering if I can use VFSFileGet(Set)Attributes to set my own custom > flag for a file. The attributes is a 32-bit number, but the OS only seems > to be using the lowest 8-bits or so and the rest are undefined (according to > the "File and Directory Attributes" list). (Unlike Jeff, let's look at your actual question :-)) The interesting question is not so much whether VFSFileSetAttributes() will allow you to specify random unassigned bits out of those 32 bits, but whether the particular physical file system underneath the VFS will remember them. The answer for the file system you are no doubt interested in, namely FAT, is of course no. As noted in the documentation, there's not even a guarantee that any particular file system will even understand and remember all of the attributes that *are* defined. You might want to try your idea on a debug ROM (possibly even before posting :-)): Invalid attributes passed to VFSFileAttributesSet ...which is a little bit surprising (what if a later OS revision defines more bits?). John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: non-editable text in a table
On Thu, Apr 03, 2003 at 01:14:54PM -0500, Dave Lippincott wrote:
> I wouldn't work with the field attributes directly. This will not work with
> OS 5 or newer versions. Try running this code in Pose and see how many
> complaints you get.
Er, none? :-) Or probably one, but for a different reason (below).
This has come up here several times before; see for example
http://www.escribe.com/computing/pcpqa/m48109.html
> "Jeff" <[EMAIL PROTECTED]> wrote:
>> {
>> Boolean temp;
>> FieldAttrPtr ptrFieldAttr;
>>
>> temp = editable;// for debug
>> if(row < TABLEROWS)
>> {
>> FldGetAttributes(fld, ptrFieldAttr);
>> ptrFieldAttr->editable = 0;
>> ptrFieldAttr->underlined = noUnderline;
>> FldSetAttributes(fld, ptrFieldAttr);
[...]
Of course, you do have the standard C newbie problem of "it wants a
pointer, so I just gave it a pointer, whaddayamean I'm supposed to give
it the address of some actual writable memory?".
Hint: m68k-palmos-gcc -O -Wall on this code gives you
warning: `ptrFieldAttr' might be used uninitialized in this function
It'd probably help if the documentation for functions like
FldGetAttributes() were more explicit, saying something along the lines
of
<- attrPAddress of a variable of type FieldAttrType
into which the result is to be written
but basically you're supposed to Just Know. And in fact this is not an
unreasonable expectation. A useful habit to get into is: whenever you
pass a pointer (to a function), *think about* who owns the memory pointed
to, who is going to write to it and read from it, who was responsible for
allocating it, and whether that ownership is transferred by the function
call.
John "what Neil said :-)"
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Include MathLib in a project
On Tue, Apr 01, 2003 at 08:57:40AM +0300, Dan Patrutiu wrote: > Ben Combee <[EMAIL PROTECTED]> wrote >> Actually, the Lesser GNU Public Licence (LGPL) is more stringent than >> that. One of the goals of the LGPL is that you must give the user freedom >> to update the library and "relink" the program to a modified library. > > I understood, but the thing is I don't suppose to change it! The point is that I, as one of your application's users, might want to change it. For (an unlikely) example, suppose a new version of MathLib came out with a new sin() function in which a bug had been fixed. The LGPL ensures that I can update my copy of your application to use the new MathLib, *even without your help*. Or you might prefer this phrasing: even without bugging you about it :-). Or I might be experimenting with improving the sin() function myself, and want to try your application with my experimental MathLib. And you really don't want me to bug you about doing that; it's much better that the LGPL ensures that I can just get on with it myself. > Can I simply include the code for those functions in my project and > put the credits in the about box, or what should I exactly do? If you want to redistribute code from MathLib that is licensed according to the LGPL, you must do so according to the LGPL [1]. To find out exactly what you should do, you should (surprisingly enough) read the LGPL. You'll find it and a FAQ at http://www.fsf.org/. The short answer to your question is no -- as we've been telling you, this involves more than just the about box. Furrfu. > So let's say I need 5 functions from the library. That's all. [...] > The project will be commercial and I cannot release any API's of it or > something like that. Then it seems to me that you want to do the other thing that has been suggested to you in this thread: find implementations of your five functions that are in the public domain or are otherwise licensed such that you can just pilfer the code. Or, to be absolutely sure, you could study some numerical analysis textbooks and implement the functions you require yourself. Since you have "commercial" resources behind you, I'm sure this won't be very difficult. Of course, if I can't play with the sin() function you're using, I'm less likely to be interested in your application :-). John [1] Yes, I'm oversimplifying. See for example section 3 of the LGPL, but I think that's right out for this person. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Multi-section apps / calling functions
On Mon, Mar 24, 2003 at 08:13:01PM -0700, Eddie Ludema wrote: > SRC=$(APP).c section1.c section2.c > SECTIONS=$(APP)-sections > CC=m68k-palmos-gcc > MULTIGEN=m68c-palmos-multigen ...you would think that the typo here was a signal that $(MULTIGEN) is not in fact being used... > $(APP): $(SRC:.c=.o) $(SECTIONS).ld > $(CC) $(CFLAGS) -o $@ $^ ...and this misses out myMain-sections.o. >> section2.c:12: undefined reference to '__text__section1' >> collect2: ld returned 1 exit status The __text__ symbols are defined in -sections.s, as generated by multigen. If they are undefined, it is because that file has not been assembled and included in your link. And indeed, according to your overcomplicated makefile, it has not been. > Could somebody point me to some good solid source code examples that > implement multiple segments using PRC-Tools? Study the multiapp makefile from the prc-tools samples. You might complain that it is a simple makefile for a trivial application, but the fact is that it contains the solution to the problem you are experiencing. > I've already searched the archives for this list, > Palm's knowledge base, PRC-Tools documentation, manuals for > gcc/multigen/build-prc/etc as well as faqs on falch.net. Don't just search them; *read* them. Reread http://prc-tools.sf.net/cgi-bin/info/breaking+up+an+existing+application this time paying attention to steps 4 and 5. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Recompiling prc-tools under Falch's DevStudio's Cygwin?
On Fri, Mar 21, 2003 at 12:16:29PM +, kcorey wrote: > Basically, the current set of Build instructions for PRC-Tools doesn't > seem to be working with the current version of cygwin... Actually what you mean is "...with the current version of Cygwin, in the way I have it installed on my machine, and with the underlying version of Windows on my machine". At least one of those things is outside the scope of the prc-tools build instructions. > /cygdrive/c/Program Files/Cygwin/bin/install -c -d /usr/m68k-palmos/lib > make[1]: *** [install] Error 255 (This should be obvious to any Unix old hand. :-)) People (not necessarily Ken) complain that they don't know what "make error 255" means. If they care to look in the make documentation, what they'll find is that make is simply reporting an error code returned by some other program, and you'd hope that the other program has already given a more useful error message. Sadly the shell Ken is using has not; but when I configure things on Linux similarly to what Ken is doing I get make[1]: Leaving directory `/home/johnm/build/prc-tools-m68k/crt/mown-gp' /home/johnm/Program Files/Cygwin/bin/install -c -d /tmp/m68k-palmos/lib make: /home/johnm/Program: Command not found make: *** [install] Error 127 thus making it clear that Ken's problem is that he has not followed Cygwin setup.exe's recommendation to avoid choosing a root path for Cygwin that includes spaces. > When I try to build both m68K and arm support, I get varied errors, > compiler not working, etc. Simply too many problems to mention them all > here. And I guess in reply I have too many answers and too much helpful advice to mention them all here :-). Suffice it to say "works for me". Perhaps much of this is more fallout from your mistake above. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Re: floats in syslib shared library under prc-tools 2.2?
On Mon, Mar 10, 2003 at 02:10:39PM -0600, Ben Combee wrote: >>float a,b; >>a=2.0; >>b=3.0*a; >> >>This was enough to generate the "global data ignored" message from >>build-prc. If I comment out the third line, the message goes away. > > It is likely that the compiler is generating the 8-byte double values for > "3.0" in the data section Nope, can't happen. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: floats in syslib shared library under prc-tools 2.2?
On Thu, Mar 13, 2003 at 07:06:09AM -0700, Dave Ek wrote: > Ton van Overbeek wrote: >> As soon as you do some floating point operation the code pulls in the >> simulated floating point condition code register (fpCCR). Yes indeed. >> So what needs to be done is to somehow get the fpCCR in the syslib >> globals. Right now I cannot tell you how to do that. Suggestions welcome Yep. The quickest and easiest way to do something equivalent is to use a different fp library that stores its CCR somewhere else. Like the New Float Manager, for example. -lnfm to the rescue! > I could only find one other instance of this problem being reported in > pilot.programmer.gcc, and none in this forum. That's because you didn't know what keywords to use -- although I expect "fpCCR" would have brought up the posting I have in mind. http://www.escribe.com/computing/pcpqa/m58918.html John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Alarm Image (symbolAlarm)
On Thu, Mar 06, 2003 at 02:36:20PM -0700, Scott Heffron wrote: > I found this in some code and noticed that it is an alarm clock on the > application. I am trying to find out what other images are available. Type "AsciiChart" into Google or http://www.escribe.com/computing/pcpqa/ > szBuf[0] = symbolAlarm; [...] > Can someone also explain what this code is doing. I have looked in some > books, but found nothing on the sybolAlarm. $ grep -rl symbolAlarm /opt/palmdev/sdk-5 /opt/palmdev/sdk-5/include/Core/System/Chars.h Start looking there... John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Newbie gdb and Palm OS 5 Simulator debugging question
On Thu, Mar 06, 2003 at 07:36:16AM -0800, Daryl Huff wrote: > Thanks, that did the trick. I went back and read the documentation at > http://prc-tools.sourceforge.net/doc/prc-tools_5.html#SEC29 and the > documentation there still looks to me like you only need to do this on > "real device". You are reading it as "need gdbpanel => using a real device", but what it actually says is "using a real device => need gdbpanel". It does not mention the Simulator explicitly. That is not surprising, because the Simulator's existence was not known when it was written. > The bullet above that states that the Emulator (and thus > I assumed Simulator) would do this automatically. Bad assumption. I don't understand why so many people confuse the Emulator and the Simulator -- the words look quite different to me :-). In any case, I have already changed this documentation to mention the Simulator explicitly. It'll show up on the web version soon and in the next prc-tools release sometime thereafter. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Newbie gdb and Palm OS 5 Simulator debugging question
On Thu, Mar 06, 2003 at 12:05:31PM -0600, Ben Combee wrote: > Ton, why doesn't GDB just use the RPC interface to call FtrSet to setup > thie 'gdbS' before it downloads the application to the device/emulator? Patches are welcome :-). But the better solution is to change GDB so that it is not dependent on the initial breakpoint and 'gdbS' feature at all. John -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
