onboardc-project — Main list for discussing needed features, fixes, and development strategies

Re: [Onboardc-project] Multi seg progress...

[Steve L. <ste...@gm...>]

On Mon, 28 Mar 2005 06:01:04 -0500, Nick Guenther <ko...@gm...> wrote:
> Oooh, the way you put it there makes it sound like PnGraph would work
> well since it has three segs. I always thought it was rather large
> though. I'll send it to you once I get it compiling again 

That would be great, thanks!

> (after
> mangling it trying to make it work with the previous new multiseg OnBC
> you sent out ;))

Sorry about that... That's what you get for volunteering to beta test
i guess. Perhaps it would be an idea to back up your code somewhere
when it's in a known good state? Or is that too sensible? ;-)

Speaking of the last version, you pointed out this problem in an email:

> Also, I don't know if this means anything, in the assembly code of the
> linker functions each assignment goes
> lea offset,a0
> move.l a0,[number](a5)
> And in segment 1 [number] contains a negative number starting at about
> -412 and moving towards -200, but in segments 2 and 3 [number] is
> always 0.

This was indeed a bug, and is one of the main things I've fixed since
that version. It was incorrectly fixing up references to global
variables for everything except segment 1. Tended to cause things to
crash quite basly. Ooops...

I'm not sure about the other problems you found with the order of
#include and #pragma segment statements, since they're harder to
reproduce without seeing the code.  Hopefully if you get PnGraph
compiling with v2.5.1 then send it to me, I can take a look at
converting over to the new multiseg style.

Thanks,

Boz

Re: [Onboardc-project] Multi seg progress...

[Nick G. <ko...@gm...>]

Oooh, the way you put it there makes it sound like PnGraph would work
well since it has three segs. I always thought it was rather large
though. I'll send it to you once I get it compiling again (after
mangling it trying to make it work with the previous new multiseg OnBC
you sent out ;))

-Nick


On Mon, 28 Mar 2005 10:28:11 +0100, Steve Little <ste...@gm...> wrote:
> > Yes! Very good! Thankies! I was wondering where you'd fallen off the
> > earth to for a while there.
> 
> Actually, I fell off into the land of work commitments mostly...
> 
> > I don't think anyone has a small multiseg app lying around, on account
> > of that the reason for multisegging is if the program is too large...
> 
> :-) Well, I did think about that as I was wriiting that email. What I
> was after was an app that is perhaps only 2 or 3 segs, not  7 like the
> one i've been using to test lately! (Thanks, Peter M, it's great to
> have a nice big project to test against!)
> 
> What I'm looking for is something to test migrating an app from the
> old style to the new. The 7 segment one I have can't use the new style
> yet, since there's a limit to how many source files you can put in a
> single OnBC project. (This is on my list to fix too, but...)
> 
> > but I could write a short thing. Maybe.
> 
> That would be useful if you had time.
> 
> Thanks,
> 
> Boz
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> onboardc-project mailing list
> onb...@li...
> https://lists.sourceforge.net/lists/listinfo/onboardc-project
>

Re: [Onboardc-project] Multi seg progress...

[Steve L. <ste...@gm...>]

> Yes! Very good! Thankies! I was wondering where you'd fallen off the
> earth to for a while there.

Actually, I fell off into the land of work commitments mostly...

> I don't think anyone has a small multiseg app lying around, on account
> of that the reason for multisegging is if the program is too large...

:-) Well, I did think about that as I was wriiting that email. What I
was after was an app that is perhaps only 2 or 3 segs, not  7 like the
one i've been using to test lately! (Thanks, Peter M, it's great to
have a nice big project to test against!)

What I'm looking for is something to test migrating an app from the
old style to the new. The 7 segment one I have can't use the new style
yet, since there's a limit to how many source files you can put in a
single OnBC project. (This is on my list to fix too, but...)

> but I could write a short thing. Maybe.

That would be useful if you had time.

Thanks,

Boz

Re: [Onboardc-project] Multi seg progress...

[Nick G. <ko...@gm...>]

Yes! Very good! Thankies! I was wondering where you'd fallen off the
earth to for a while there.

I don't think anyone has a small multiseg app lying around, on account
of that the reason for multisegging is if the program is too large...
but I could write a short thing. Maybe.

-Nick


On Sat, 26 Mar 2005 16:59 -0300, Peter Thorstenson <pe...@un...> wrote:
> This is GOOD news! :) Thanks for the work you are putting down!
> /Peter
> 
> ...... Original Message .......
> On Sat, 26 Mar 2005 19:48:34 +0000 Steve Little <ste...@gm...>
> wrote:
> >Hi all,
> >        Just a quick update on the progress with the new multi-seg
> >support I've been working on:
> >
> >Thanks to those who volunteered as beta testers, several bugs were
> >unearthed, and I've just about finished fixing them all.
> >
> >Notably, old style multiseg apps seemed to often generate bad code
> >which would crash instead of running normally. Not Good. I've fixed
> >this now
> >
> >Also, there were some problems with old style multi-seg apps
> >incorrectly reporting "unknown identifier __codeN". Also fixed.
> >
> >I'm aware of one remaining bug: The new version doesn't always set the
> >flags correctly for new PRCs it generates. I'm working on a fix for
> >this at the moment.
> >
> >Once that's done, I need to finish some work on auto-generating the
> >necessary bootstrap code (opening and locking each code segment).
> >Currently you need to write this code yourself.
> >
> >Oh, and on that note, I've done some more work on documenting the new
> >multi-seg support, how to use it, and how to port apps written in the
> >old way.
> >
> >Does anyone have a relatively small multiseg app that I could use to
> >experiment with converting to the new style?
> >
> >Anyway, just wanted to let people know that things are progressing,
> >albeit slowly, due to other commitments. More news when I have some...
> >
> >Cheers,
> >
> >Boz
> >
> >
> >-------------------------------------------------------
> >SF email is sponsored by - The IT Product Guide
> >Read honest & candid reviews on hundreds of IT Products from real users.
> >Discover which products truly live up to the hype. Start reading now.
> >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >_______________________________________________
> >onboardc-project mailing list
> >onb...@li...
> >https://lists.sourceforge.net/lists/listinfo/onboardc-project
> >
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> onboardc-project mailing list
> onb...@li...
> https://lists.sourceforge.net/lists/listinfo/onboardc-project
>

Re: [Onboardc-project] Multi seg progress...

[Peter T. <pe...@un...>]

This is GOOD news! :) Thanks for the work you are putting down! 
/Peter

...... Original Message .......
On Sat, 26 Mar 2005 19:48:34 +0000 Steve Little <ste...@gm...> 
wrote:
>Hi all,
>        Just a quick update on the progress with the new multi-seg
>support I've been working on:
>
>Thanks to those who volunteered as beta testers, several bugs were
>unearthed, and I've just about finished fixing them all.
>
>Notably, old style multiseg apps seemed to often generate bad code
>which would crash instead of running normally. Not Good. I've fixed
>this now
>
>Also, there were some problems with old style multi-seg apps
>incorrectly reporting "unknown identifier __codeN". Also fixed.
>
>I'm aware of one remaining bug: The new version doesn't always set the
>flags correctly for new PRCs it generates. I'm working on a fix for
>this at the moment.
>
>Once that's done, I need to finish some work on auto-generating the
>necessary bootstrap code (opening and locking each code segment).
>Currently you need to write this code yourself.
>
>Oh, and on that note, I've done some more work on documenting the new
>multi-seg support, how to use it, and how to port apps written in the
>old way.
>
>Does anyone have a relatively small multiseg app that I could use to
>experiment with converting to the new style?
>
>Anyway, just wanted to let people know that things are progressing,
>albeit slowly, due to other commitments. More news when I have some...
>
>Cheers,
>
>Boz
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>onboardc-project mailing list
>onb...@li...
>https://lists.sourceforge.net/lists/listinfo/onboardc-project
>

[Onboardc-project] Multi seg progress...

[Steve L. <ste...@gm...>]

Hi all,
        Just a quick update on the progress with the new multi-seg
support I've been working on:

Thanks to those who volunteered as beta testers, several bugs were
unearthed, and I've just about finished fixing them all.

Notably, old style multiseg apps seemed to often generate bad code
which would crash instead of running normally. Not Good. I've fixed
this now

Also, there were some problems with old style multi-seg apps
incorrectly reporting "unknown identifier __codeN". Also fixed.

I'm aware of one remaining bug: The new version doesn't always set the
flags correctly for new PRCs it generates. I'm working on a fix for
this at the moment.

Once that's done, I need to finish some work on auto-generating the
necessary bootstrap code (opening and locking each code segment).
Currently you need to write this code yourself.

Oh, and on that note, I've done some more work on documenting the new
multi-seg support, how to use it, and how to port apps written in the
old way.

Does anyone have a relatively small multiseg app that I could use to
experiment with converting to the new style?

Anyway, just wanted to let people know that things are progressing,
albeit slowly, due to other commitments. More news when I have some...

Cheers,

Boz

Re: [Onboardc-project] OnBoard Assembler - out of memory (14)

[Steve L. <ste...@gm...>]

> Tried those suggestions - still no luck. 

Damn. I thought you might have done, but it's always worth checking. 

> I had tried "delete object code" already, but not deleting the app. I also deleted 
> the old OnBoardC completely, and did a fresh install.
> 
> I could mail you a copy of the source code ? Its not huge.

Sure. Send a copy and I'll try. Have you tried under POSE? If you can
recreate it under a clean POSE session with just OnBC, it sounds like
an OnBC problem. If you can't, it must be something odd on your
device.

Very odd that it worked under the old version of OnBC, either way.
Like I say, send it over and I'll dig.

> I am going to open it up anyway once I have a clean port to OBC.

Cool. More open source software for the palm is always good.

Thanks,

Boz

Re: [Onboardc-project] OnBoard Assembler - out of memory (14)

[Andy R. <an...@wi...>]

On Fri, 18 Mar 2005, Steve Little wrote:

> Hmmm, doesn't sound good. That particular error occurs if OnBA has
> trouble creating a code0 resource for your app. Can't think so many
> reasons why that would happen.
> 
> Have you tried deleting the existing version of your app before compiling?
> 
> Also try hitting "delete object code".
> 
> If neither of those work, report back and I'll take a closer look...

Tried those suggestions - still no luck. I had tried "delete object
code" already, but not deleting the app. I also deleted the old OnBoardC
completely, and did a fresh install.

I could mail you a copy of the source code ? Its not huge.

I am going to open it up anyway once I have a clean port to OBC.

Cheers,  Andy!

> On Fri, 18 Mar 2005 16:12:16 +0200, Andy Rabagliati <an...@wi...> wrote:
> > 
> > OnBoard Assembler - out of memory (14)
> > 
> >  What could be wrong ?

Re: [Onboardc-project] OnBoard Assembler - out of memory (14)

[Steve L. <ste...@gm...>]

Hmmm, doesn't sound good. That particular error occurs if OnBA has
trouble creating a code0 resource for your app. Can't think so many
reasons why that would happen.

Have you tried deleting the existing version of your app before compiling?

Also try hitting "delete object code".

If neither of those work, report back and I'll take a closer look...

Boz

On Fri, 18 Mar 2005 16:12:16 +0200, Andy Rabagliati <an...@wi...> wrote:
> Folks,
> 
>  Just got myself a new Zire 31, and have picked up OnBoardC again. I
>  have a game ( http://www.wizzy.com/owari/ ) that I moved a while back
>  from prctools to OnBoardC.
> 
>  However, the latest (Mar 5) release, on even trivial programs,
>  complains after build :-
> 
> OnBoard Assembler - out of memory (14)
> 
>  What could be wrong ?
> 
>  My program is not even segmented.
> 
>  The Zire has 16Meg RAM, with about half free. That should be enough, no ?
> 
> Cheers,    Andy!
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> onboardc-project mailing list
> onb...@li...
> https://lists.sourceforge.net/lists/listinfo/onboardc-project
>

[Onboardc-project] OnBoard Assembler - out of memory (14)

[Andy R. <an...@wi...>]

Folks,

  Just got myself a new Zire 31, and have picked up OnBoardC again. I
  have a game ( http://www.wizzy.com/owari/ ) that I moved a while back
  from prctools to OnBoardC.

  However, the latest (Mar 5) release, on even trivial programs,
  complains after build :-

OnBoard Assembler - out of memory (14)

  What could be wrong ?

  My program is not even segmented.

  The Zire has 16Meg RAM, with about half free. That should be enough, no ?

Cheers,    Andy!

Re: [Onboardc-project] SrcEdit doesn't compile under PODS/PRC-TOOLS

[John W. <or...@ru...>]

It works fine!
Thanks.

/John

> Ok, found the problem. It seems that the WideTallApp.h file
> (originally from the AlphaSmart Dana SDK) isn't compatible with
> sdk-5r4, as PalmOS changed the definition of the macro _Str() to be
> _PalmTypes_OS_CALL_Str().
>=20
> I've fixed up the WideTallApp.h in CVS, and it now works for me on sdk5 o=
r 5r4
>=20
> Marcelo, John, can you test and see if this works fine for you too?
>=20
> Thanks,
>=20
> Boz
>=20
>=20
> On Sat, 26 Feb 2005 17:21:11 +0000, Steve Little <ste...@gm...>=
 wrote:
> > Hmmm, seems the problem is with sdk5r4, since when I install it i get
> > the problem too.
> >=20
> > I can't find the old version of sdk5 on the PalmOS site, but I could
> > send you a copy Marcelo.
> >=20
> > Alternatively (and a better idea, IMHO) I'll attempt to fix SrcEdit to
> > compile with the latest sdk version...
> >=20
> > Now that I can recreate this locally I can shopefully tart figuring
> > out what's wrong...
> >=20
> > Boz
> >=20
> >=20
> > On Fri, 25 Feb 2005 18:48:52 -0300, Marcelo Alves <so...@gm...> w=
rote:
> > >  Err... Where can I find the SDK 5?
> > >
> > >
> > > > I have recently stumbled over the exact same thing. It's some thing=
 with the SDK5r4 that isn't compatible with SDK5.0. I suggest you do as I d=
id: Create a uniqe folder for each sdk. (One for sdk-5, and one for sdk-5r4=
 aso)
> > >
> > > -------------------------------------------------------
> > > SF email is sponsored by - The IT Product Guide
> > > Read honest & candid reviews on hundreds of IT Products from real use=
rs.
> > > Discover which products truly live up to the hype. Start reading now.
> > > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> > > _______________________________________________
> > > onboardc-project mailing list
> > > onb...@li...
> > > https://lists.sourceforge.net/lists/listinfo/onboardc-project
> > >
> >
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> onboardc-project mailing list
> onb...@li...
> https://lists.sourceforge.net/lists/listinfo/onboardc-project
>=20

Re: [Onboardc-project] SrcEdit doesn't compile under PODS/PRC-TOOLS

[Steve L. <ste...@gm...>]

Ok, found the problem. It seems that the WideTallApp.h file
(originally from the AlphaSmart Dana SDK) isn't compatible with
sdk-5r4, as PalmOS changed the definition of the macro _Str() to be
_PalmTypes_OS_CALL_Str().

I've fixed up the WideTallApp.h in CVS, and it now works for me on sdk5 or 5r4

Marcelo, John, can you test and see if this works fine for you too?

Thanks,

Boz


On Sat, 26 Feb 2005 17:21:11 +0000, Steve Little <ste...@gm...> wrote:
> Hmmm, seems the problem is with sdk5r4, since when I install it i get
> the problem too.
> 
> I can't find the old version of sdk5 on the PalmOS site, but I could
> send you a copy Marcelo.
> 
> Alternatively (and a better idea, IMHO) I'll attempt to fix SrcEdit to
> compile with the latest sdk version...
> 
> Now that I can recreate this locally I can shopefully tart figuring
> out what's wrong...
> 
> Boz
> 
> 
> On Fri, 25 Feb 2005 18:48:52 -0300, Marcelo Alves <so...@gm...> wrote:
> >  Err... Where can I find the SDK 5?
> >
> >
> > > I have recently stumbled over the exact same thing. It's some thing with the SDK5r4 that isn't compatible with SDK5.0. I suggest you do as I did: Create a uniqe folder for each sdk. (One for sdk-5, and one for sdk-5r4 aso)
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > onboardc-project mailing list
> > onb...@li...
> > https://lists.sourceforge.net/lists/listinfo/onboardc-project
> >
>

Re: [Onboardc-project] SrcEdit doesn't compile under PODS/PRC-TOOLS

[Steve L. <ste...@gm...>]

Hmmm, seems the problem is with sdk5r4, since when I install it i get
the problem too.

I can't find the old version of sdk5 on the PalmOS site, but I could
send you a copy Marcelo.

Alternatively (and a better idea, IMHO) I'll attempt to fix SrcEdit to
compile with the latest sdk version...

Now that I can recreate this locally I can shopefully tart figuring
out what's wrong...

Boz


On Fri, 25 Feb 2005 18:48:52 -0300, Marcelo Alves <so...@gm...> wrote:
>  Err... Where can I find the SDK 5?
> 
> 
> > I have recently stumbled over the exact same thing. It's some thing with the SDK5r4 that isn't compatible with SDK5.0. I suggest you do as I did: Create a uniqe folder for each sdk. (One for sdk-5, and one for sdk-5r4 aso)
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> onboardc-project mailing list
> onb...@li...
> https://lists.sourceforge.net/lists/listinfo/onboardc-project
>

Re: [Onboardc-project] SrcEdit doesn't compile under PODS/PRC-TOOLS

[Marcelo A. <so...@gm...>]

  Err... Where can I find the SDK 5? 


> I have recently stumbled over the exact same thing. It's some thing with the SDK5r4 that isn't compatible with SDK5.0. I suggest you do as I did: Create a uniqe folder for each sdk. (One for sdk-5, and one for sdk-5r4 aso)

Re: [Onboardc-project] SrcEdit doesn't compile under PODS/PRC-TOOLS

[John W. <or...@ru...>]

Marcelo,

I have recently stumbled over the exact same thing. It's some thing with th=
e SDK5r4 that isn't compatible with SDK5.0. I suggest you do as I did: Crea=
te a uniqe folder for each sdk. (One for sdk-5, and one for sdk-5r4 aso)

/John

> On Thu, 24 Feb 2005 10:11:06 +0000, Steve Little <ste...@gm...>=
 wrote:
> > > > :-( Odd, it compiles fine under plain old prc-tools for me.
> > >
> > > Doesn't compile under prc-tools / cygwin / windows xp.
> >=20
> > Curiouser and curiouser. That's what I'm running. m68k-palmos-gcc
> > --version reports 2.95.3-kgpd on my system. Are you using the makefile
> > from cvs, or have you rolled your own for use in PODS?
>=20
>=20=20=20
>   Same gcc version, I've just changed the palmos version, from
> "palmos4" (or "palmos5") to "palmos5r4".
>=20
> >=20
> > >   __GNUC__ is defined :(
> >=20
> > Then I can't think what else might be wrong. Might be interesting to
> > edit WideTallApp.h and put a #error just before each of the macros is
> > defined, make sure the compiler is reaching those. If so, maybe it's
> > getting upset about something else, perhaps the __attribute__ ((
> > __callseq__ <etc> that it eventually translates to...
> >=20
> > Not sure what else to suggest, maybe you can give me some clues about
> > your config and I can try to recreate it?
>=20
>   Hmm, maybe using PalmOS 5r4 SDK (Garnet)?
>=20
> >=20
> > I'll have a play around and see what I can discover...
> >=20
> > Boz
> >=20
> >=20
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> > _______________________________________________
> > onboardc-project mailing list
> > onb...@li...
> > https://lists.sourceforge.net/lists/listinfo/onboardc-project
> >
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> onboardc-project mailing list
> onb...@li...
> https://lists.sourceforge.net/lists/listinfo/onboardc-project
>=20

Re: [Onboardc-project] SrcEdit doesn't compile under PODS/PRC-TOOLS

[Marcelo A. <so...@gm...>]

On Thu, 24 Feb 2005 10:11:06 +0000, Steve Little <ste...@gm...> wrote:
> > > :-( Odd, it compiles fine under plain old prc-tools for me.
> >
> > Doesn't compile under prc-tools / cygwin / windows xp.
> 
> Curiouser and curiouser. That's what I'm running. m68k-palmos-gcc
> --version reports 2.95.3-kgpd on my system. Are you using the makefile
> from cvs, or have you rolled your own for use in PODS?

  
  Same gcc version, I've just changed the palmos version, from
"palmos4" (or "palmos5") to "palmos5r4".

> 
> >   __GNUC__ is defined :(
> 
> Then I can't think what else might be wrong. Might be interesting to
> edit WideTallApp.h and put a #error just before each of the macros is
> defined, make sure the compiler is reaching those. If so, maybe it's
> getting upset about something else, perhaps the __attribute__ ((
> __callseq__ <etc> that it eventually translates to...
> 
> Not sure what else to suggest, maybe you can give me some clues about
> your config and I can try to recreate it?

  Hmm, maybe using PalmOS 5r4 SDK (Garnet)?

> 
> I'll have a play around and see what I can discover...
> 
> Boz
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> onboardc-project mailing list
> onb...@li...
> https://lists.sourceforge.net/lists/listinfo/onboardc-project
>

Re: [Onboardc-project] SrcEdit doesn't compile under PODS/PRC-TOOLS

[Steve L. <ste...@gm...>]

> > :-( Odd, it compiles fine under plain old prc-tools for me.
> 
> Doesn't compile under prc-tools / cygwin / windows xp.

Curiouser and curiouser. That's what I'm running. m68k-palmos-gcc
--version reports 2.95.3-kgpd on my system. Are you using the makefile
from cvs, or have you rolled your own for use in PODS?

>   __GNUC__ is defined :(

Then I can't think what else might be wrong. Might be interesting to
edit WideTallApp.h and put a #error just before each of the macros is
defined, make sure the compiler is reaching those. If so, maybe it's
getting upset about something else, perhaps the __attribute__ ((
__callseq__ <etc> that it eventually translates to...

Not sure what else to suggest, maybe you can give me some clues about
your config and I can try to recreate it?

I'll have a play around and see what I can discover...

Boz

Re: [Onboardc-project] SrcEdit doesn't compile under PODS/PRC-TOOLS

[Marcelo A. <mar...@xf...>]

Steve Little wrote:
> Hi Marcelo,
> 
> 
>> SrcEdit from OnBoardSuite242.zip or CVS doesn't compile under
>>prc-tools installed by PalmOS Developer Suite. 
> 
> 
> :-( Odd, it compiles fine under plain old prc-tools for me.

Doesn't compile under prc-tools / cygwin / windows xp.

*snip*

>>This error leads to an "EXTERNAL_TRAP" define, but I don't know how to fix this.
> 
> 
> Hmmm, indeed each of those lines features EXTERNAL_TRAP, so I guess
> there must be a problem with that macro.
> 
> It's defined in WideTallApp.h, which is included by Screen.h, but I
> don't see anything unusual about the definition. The only thing I can
> think of is that __GNUC__ might not be defined under PODS, in which
> case the definition of _AS_CALL_WITH_16BIT_SELECTOR() may be skipped.
> (it's used by AS_TRAP(), used by EXTERNAL_TRAP...)
> 
> Maybe have a quick play and try to work out if __GNUC__ is set? I'd
> usually do that like this:
> 
> #ifdef __GNUC__
> #error "__GNUC__ is defined"
> #endif
> 
> Hope that helps,

   __GNUC__ is defined :(

:: marcelo.alves

Re: [Onboardc-project] SrcEdit doesn't compile under PODS/PRC-TOOLS

[Steve L. <ste...@gm...>]

Hi Marcelo,

>  SrcEdit from OnBoardSuite242.zip or CVS doesn't compile under
> prc-tools installed by PalmOS Developer Suite. 

:-( Odd, it compiles fine under plain old prc-tools for me.

>It stops with the error
> 
> make[1]: Entering directory `/home/xfer/cvs/OnBSuite242/SrcEdit'
> make  -C Src
> make[2]: Entering directory `/home/xfer/cvs/OnBSuite242/SrcEdit/Src'
> m68k-palmos-g++ -c -O2 -DHIRES_SUPPORT -Wall -g -mdebug-labels Led.cpp
> In file included from LedGlobals.h:6,
>                 from Led.cpp:13:
> Screen.h:95: parse error before `('
*snip*
> make: *** [SrcEdit] Error 2
> 
> This error leads to an "EXTERNAL_TRAP" define, but I don't know how to fix this.

Hmmm, indeed each of those lines features EXTERNAL_TRAP, so I guess
there must be a problem with that macro.

It's defined in WideTallApp.h, which is included by Screen.h, but I
don't see anything unusual about the definition. The only thing I can
think of is that __GNUC__ might not be defined under PODS, in which
case the definition of _AS_CALL_WITH_16BIT_SELECTOR() may be skipped.
(it's used by AS_TRAP(), used by EXTERNAL_TRAP...)

Maybe have a quick play and try to work out if __GNUC__ is set? I'd
usually do that like this:

#ifdef __GNUC__
#error "__GNUC__ is defined"
#endif

Hope that helps,

> :: marcelo.alves, trying to compile the entire suite under PODS.

Cool :-) Hope you manage it soon!

Boz

[Onboardc-project] SrcEdit doesn't compile under PODS/PRC-TOOLS

[Marcelo A. <so...@gm...>]

Hi,

  SrcEdit from OnBoardSuite242.zip or CVS doesn't compile under
prc-tools installed by PalmOS Developer Suite. It stops with the error
:

make[1]: Entering directory `/home/xfer/cvs/OnBSuite242/SrcEdit'
make  -C Src
make[2]: Entering directory `/home/xfer/cvs/OnBSuite242/SrcEdit/Src'
m68k-palmos-g++ -c -O2 -DHIRES_SUPPORT -Wall -g -mdebug-labels Led.cpp
In file included from LedGlobals.h:6,
                 from Led.cpp:13:
Screen.h:95: parse error before `('
Screen.h:101: parse error before `('
Screen.h:108: parse error before `('
Screen.h:114: parse error before `('
Screen.h:120: parse error before `('
Screen.h:126: parse error before `('
Screen.h:132: parse error before `('
make[2]: *** [Led.o] Error 1
make[2]: Leaving directory `/home/xfer/cvs/OnBSuite242/SrcEdit/Src'
make[1]: *** [Src] Error 2
make[1]: Leaving directory `/home/xfer/cvs/OnBSuite242/SrcEdit'
make: *** [SrcEdit] Error 2

This error leads to an "EXTERNAL_TRAP" define, but I don't know how to fix this.

:: marcelo.alves, trying to compile the entire suite under PODS.

Re: [Onboardc-project] RE: Massive CVS updates (from the Forum)

[Joey B. <dr...@nb...>]

I agree.  I'll probably start pestering you shortly after you announce th=
e new release ;-)

John Wilund wrote:
>>This is a great suggestion.  I was planning on making a branch, but I w=
as still trying to=20
>>figure out the best way to merge that branch back in to the main one wi=
th as little=20
>>mess as possible.  The one thing I really don't want to do is to mess u=
p the work that > some of the "real" developers are doing  with bug fixes=
 and enhancements. =20
>=20
>=20
>>I think I'll still do it one subdirectory at a time, and probably start=
 with SrcEdit first,=20
>>since the development work on it should slow down with the release comi=
ng in March.
>=20
>=20
> This sounds just great! We'll have to establish contact while you're wo=
rking on the SrcEdit sources, though.
>=20
> /John
> or...@ru...
>=20
>=20
>>Steve Little wrote:
>>
>>>[from Wade, who was having some trouble posting this message:]
>>>
>>>
>>>
>>>>Hi all.  I thought I would post a question before actually doing anyt=
hingto
>>>>the CVS repository.  [...] I just want to be sure that when I start c=
omitting
>>>>the code cleanup, I don't cause others to have to re-edit the files t=
hey've
>>>>just spent time fixing and testing.
>>>
>>>
>>>I just had some experience with this sort of thing (massive changes to
>>>an evolving CVS repository) at work.  The best way to do this, I think=
,
>>>is to do the following:
>>>
>>>   1) create a branch from mainline (maybe call it
>>>      "branch_joey_cleanup")
>>>   2) before work on the new branch, tag all the files (maybe call
>>>      it "tag_joey_cleanup_start")
>>>   3) make all your changes on the branch
>>>   4) when you're done with your changes, tag all the files on the
>>>      branch (maybe call this "tag_joey_cleanup_end")
>>>   5) on mainline, tag all the files (maybe, "pre_merge_joey_cleanup")
>>>   6) on mainline, do the following:
>>>       cvs update -j tag_joey_cleanup_start -j tag_joey_cleanup_end
>>>
>>>This last one is beautiful -- it merges into mainline (since that's yo=
ur
>>>current branch) all the changes _between_ the two tags.  You may have
>>>some conflicts to resolve, but it works surprisingly well.  And, if
>>>things go badly, we can always back-up to the 'pre_merge_joey_cleanup"=
 tag.
>>>
>>>--
>>>Wade
>>>wa...@ad...
>>>
>>>
>>>-------------------------------------------------------
>>>SF email is sponsored by - The IT Product Guide
>>>Read honest & candid reviews on hundreds of IT Products from real user=
s.
>>>Discover which products truly live up to the hype. Start reading now.
>>>http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>>>_______________________________________________
>>>onboardc-project mailing list
>>>onb...@li...
>>>https://lists.sourceforge.net/lists/listinfo/onboardc-project
>>>
>>>
>>
>>--=20
>>------------
>>"Debugging is twice as hard as writing the code in the first place.
>>Therefore, if you write the code as cleverly as possible, you are,
>>by definition, not smart enough to debug it." -- Brian W. Kernighan
>>------------
>>Joey Bernard
>>System Architect
>>
>>Projects Division, CARIS
>>115 Waggoners Lane, Fredericton NB, E3B 2L4 CANADA
>>Phone:  (506) 458-8533 (Reception)  (506) 462-4206
>>Fax:    (506) 459-3849
>>
>>CARIS has expanded to new office facilities. Our new mailing address is=
:
>>
>>115 Waggoners Lane, Fredericton, New Brunswick, E3B 2L4, Canada.
>>
>>Visit us on the web at http://www.caris.com
>>
>>NO BINDING CONTRACT WILL RESULT FROM THIS E-MAIL UNTIL SUCH TIME AS A
>>WRITTEN
>>DOCUMENT IS SIGNED ON BEHALF OF THE COMPANY.
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users=
.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>>_______________________________________________
>>onboardc-project mailing list
>>onb...@li...
>>https://lists.sourceforge.net/lists/listinfo/onboardc-project
>>
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users=
.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk
> _______________________________________________
> onboardc-project mailing list
> onb...@li...
> https://lists.sourceforge.net/lists/listinfo/onboardc-project
>=20
>=20

Re: [Onboardc-project] RE: Massive CVS updates (from the Forum)

[Ken M. <ma...@us...>]

On Mon, 21 Feb 2005, Joey Bernard wrote:
> The one thing I really don't want to do is to mess up the work 
> that some of the "real" developers are doing with bug fixes and 
> enhancements.

Please don't belittle the importance of clean and well documented 
code. I'm very glad you are doing what you are doing. One of the 
reasons I haven't coded much is the barrier of entry to 
understanding the code. Your work should help lower that.

   -k.

Re: [Onboardc-project] RE: Massive CVS updates (from the Forum)

[John W. <or...@ru...>]

> This is a great suggestion.  I was planning on making a branch, but I was=
 still trying to=20
> figure out the best way to merge that branch back in to the main one with=
 as little=20
> mess as possible.  The one thing I really don't want to do is to mess up =
the work that > some of the "real" developers are doing  with bug fixes and=
 enhancements.=20=20

> I think I'll still do it one subdirectory at a time, and probably start w=
ith SrcEdit first,=20
> since the development work on it should slow down with the release coming=
 in March.

This sounds just great! We'll have to establish contact while you're workin=
g on the SrcEdit sources, though.

/John
or...@ru...

> Steve Little wrote:
> > [from Wade, who was having some trouble posting this message:]
> >=20
> >=20
> >>Hi all.  I thought I would post a question before actually doing anythi=
ngto
> >>the CVS repository.  [...] I just want to be sure that when I start com=
itting
> >>the code cleanup, I don't cause others to have to re-edit the files the=
y've
> >>just spent time fixing and testing.
> >=20
> >=20
> > I just had some experience with this sort of thing (massive changes to
> > an evolving CVS repository) at work.  The best way to do this, I think,
> > is to do the following:
> >=20
> >    1) create a branch from mainline (maybe call it
> >       "branch_joey_cleanup")
> >    2) before work on the new branch, tag all the files (maybe call
> >       it "tag_joey_cleanup_start")
> >    3) make all your changes on the branch
> >    4) when you're done with your changes, tag all the files on the
> >       branch (maybe call this "tag_joey_cleanup_end")
> >    5) on mainline, tag all the files (maybe, "pre_merge_joey_cleanup")
> >    6) on mainline, do the following:
> >        cvs update -j tag_joey_cleanup_start -j tag_joey_cleanup_end
> >=20
> > This last one is beautiful -- it merges into mainline (since that's your
> > current branch) all the changes _between_ the two tags.  You may have
> > some conflicts to resolve, but it works surprisingly well.  And, if
> > things go badly, we can always back-up to the 'pre_merge_joey_cleanup" =
tag.
> >=20
> > --
> > Wade
> > wa...@ad...
> >=20
> >=20
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> > _______________________________________________
> > onboardc-project mailing list
> > onb...@li...
> > https://lists.sourceforge.net/lists/listinfo/onboardc-project
> >=20
> >=20
>=20
> --=20
> ------------
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." -- Brian W. Kernighan
> ------------
> Joey Bernard
> System Architect
>=20
> Projects Division, CARIS
> 115 Waggoners Lane, Fredericton NB, E3B 2L4 CANADA
> Phone:  (506) 458-8533 (Reception)  (506) 462-4206
> Fax:    (506) 459-3849
>=20
> CARIS has expanded to new office facilities. Our new mailing address is:
>=20
> 115 Waggoners Lane, Fredericton, New Brunswick, E3B 2L4, Canada.
>=20
> Visit us on the web at http://www.caris.com
>=20
> NO BINDING CONTRACT WILL RESULT FROM THIS E-MAIL UNTIL SUCH TIME AS A
> WRITTEN
> DOCUMENT IS SIGNED ON BEHALF OF THE COMPANY.
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> onboardc-project mailing list
> onb...@li...
> https://lists.sourceforge.net/lists/listinfo/onboardc-project
>=20

Re: [Onboardc-project] RE: Massive CVS updates (from the Forum)

[Joey B. <joe...@ca...>]

This is a great suggestion.  I was planning on making a branch, but I was still trying to figure out 
the best way to merge that branch back in to the main one with as little mess as possible.  The one 
thing I really don't want to do is to mess up the work that some of the "real" developers are doing 
with bug fixes and enhancements.  I think I'll still do it one subdirectory at a time, and probably 
start with SrcEdit first, since the development work on it should slow down with the release coming 
in March.

Steve Little wrote:
> [from Wade, who was having some trouble posting this message:]
> 
> 
>>Hi all.  I thought I would post a question before actually doing anythingto
>>the CVS repository.  [...] I just want to be sure that when I start comitting
>>the code cleanup, I don't cause others to have to re-edit the files they've
>>just spent time fixing and testing.
> 
> 
> I just had some experience with this sort of thing (massive changes to
> an evolving CVS repository) at work.  The best way to do this, I think,
> is to do the following:
> 
>    1) create a branch from mainline (maybe call it
>       "branch_joey_cleanup")
>    2) before work on the new branch, tag all the files (maybe call
>       it "tag_joey_cleanup_start")
>    3) make all your changes on the branch
>    4) when you're done with your changes, tag all the files on the
>       branch (maybe call this "tag_joey_cleanup_end")
>    5) on mainline, tag all the files (maybe, "pre_merge_joey_cleanup")
>    6) on mainline, do the following:
>        cvs update -j tag_joey_cleanup_start -j tag_joey_cleanup_end
> 
> This last one is beautiful -- it merges into mainline (since that's your
> current branch) all the changes _between_ the two tags.  You may have
> some conflicts to resolve, but it works surprisingly well.  And, if
> things go badly, we can always back-up to the 'pre_merge_joey_cleanup" tag.
> 
> --
> Wade
> wa...@ad...
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> onboardc-project mailing list
> onb...@li...
> https://lists.sourceforge.net/lists/listinfo/onboardc-project
> 
> 

-- 
------------
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian W. Kernighan
------------
Joey Bernard
System Architect

Projects Division, CARIS
115 Waggoners Lane, Fredericton NB, E3B 2L4 CANADA
Phone:  (506) 458-8533 (Reception)  (506) 462-4206
Fax:    (506) 459-3849

CARIS has expanded to new office facilities. Our new mailing address is:

115 Waggoners Lane, Fredericton, New Brunswick, E3B 2L4, Canada.

Visit us on the web at http://www.caris.com

NO BINDING CONTRACT WILL RESULT FROM THIS E-MAIL UNTIL SUCH TIME AS A
WRITTEN
DOCUMENT IS SIGNED ON BEHALF OF THE COMPANY.

[Onboardc-project] RE: Massive CVS updates (from the Forum)

[Steve L. <ste...@gm...>]

[from Wade, who was having some trouble posting this message:]

>Hi all.  I thought I would post a question before actually doing anythingto
>the CVS repository.  [...] I just want to be sure that when I start comitting
>the code cleanup, I don't cause others to have to re-edit the files they've
>just spent time fixing and testing.

I just had some experience with this sort of thing (massive changes to
an evolving CVS repository) at work.  The best way to do this, I think,
is to do the following:

   1) create a branch from mainline (maybe call it
      "branch_joey_cleanup")
   2) before work on the new branch, tag all the files (maybe call
      it "tag_joey_cleanup_start")
   3) make all your changes on the branch
   4) when you're done with your changes, tag all the files on the
      branch (maybe call this "tag_joey_cleanup_end")
   5) on mainline, tag all the files (maybe, "pre_merge_joey_cleanup")
   6) on mainline, do the following:
       cvs update -j tag_joey_cleanup_start -j tag_joey_cleanup_end

This last one is beautiful -- it merges into mainline (since that's your
current branch) all the changes _between_ the two tags.  You may have
some conflicts to resolve, but it works surprisingly well.  And, if
things go badly, we can always back-up to the 'pre_merge_joey_cleanup" tag.

--
Wade
wa...@ad...