On Mon, Mar 31, 2008 at 4:58 PM, Sherm Pendley <sherm.pendley@...>
wrote:
> SVN is passing all of the self-tests in the Debug build configuration now.
> I've added a new function for choosing the appropriate objc_msgSend variant
> for the current arch & message, many new tests in NSNumber.t, for testing
> bool, char, short, and long as both argument & return types. Fixed bug that
> was causing BundleLoader.t to fail.
>
> ShuX still falls over dead soon after launching on PPC Leopard, refuses to
> launch at all on PPC Panther, and runs successfully on Intel Tiger.
>
> Given the passage of all the self-tests, we're left with a bug we're not
> testing for, or a bug in ShuX. If it's a bug in the framework, I suspect
> that it might be a PPC-specific bug showing different symptoms on Panther &
> Leopard.
>
> Can anyone comment on whether the latest SVN builds & passes self-tests in
> Debug config, for Intel Leopard? PPC, either Tiger or Leopard? (The project
> file is in 2.4 format, but is configured for the 10.5 SDK and support for
> Perl 5.8.8 - you'll need to tweak the project settings to build on Tiger,
> and the resulting framework will not run on Leopard.)
Oh, and if anyone wants to build a Release-App-Embedded framework to test an
embedded framework in their .app, feedback about that would be most welcome.
In particular, if we get a whole flood of "works foo Foo.app," that lends
credence to the idea that the bug I'm seeing here is really in ShuX.
Conversely, if all our apps are FUBAR on PPC, the bug is obviously in the
framework.
sherm--

SVN is passing all of the self-tests in the Debug build configuration now.
I've added a new function for choosing the appropriate objc_msgSend variant
for the current arch & message, many new tests in NSNumber.t, for testing
bool, char, short, and long as both argument & return types. Fixed bug that
was causing BundleLoader.t to fail.
ShuX still falls over dead soon after launching on PPC Leopard, refuses to
launch at all on PPC Panther, and runs successfully on Intel Tiger.
Given the passage of all the self-tests, we're left with a bug we're not
testing for, or a bug in ShuX. If it's a bug in the framework, I suspect
that it might be a PPC-specific bug showing different symptoms on Panther &
Leopard.
Can anyone comment on whether the latest SVN builds & passes self-tests in
Debug config, for Intel Leopard? PPC, either Tiger or Leopard? (The project
file is in 2.4 format, but is configured for the 10.5 SDK and support for
Perl 5.8.8 - you'll need to tweak the project settings to build on Tiger,
and the resulting framework will not run on Leopard.)
sherm--

sherm.pendley@... (Sherm Pendley) wrote:
>But, even *more* people are using Leopard than Panther at this point, so
>dropping Panther (perhaps temporarily) may be the lesser of two evils.
Is 1.0.3 broken on Panther? Otherwise, dropping Panther in the
version adding support for Leopard seems eminently reasonable.
Ideally it would support everything under the sun, of course,
but OS version support is a feature like any other; if it
doesn't fit with other goals (such as actually shipping) it
needs to be dropped.
--
“See... *That* is the problem... Scotch is for sipping,
relaxing, and deep
thoughts... Jack is what you drink when you need to work
through the pain.”
--
John C. Welch

I agree.
Though I still use Panther on my laptop, I wouldn't object to
dropping support for it in DVDSpanner.
On 21-Mar-08, at 6:02 PM, Dan Grillo wrote:
> my 2c: It's much better to drop Panther support than to block Leopard.

my 2c: It's much better to drop Panther support than to block Leopard.
--Dan
----- Begin forwarded message:
From: "Sherm Pendley" <sherm.pendley@...>
Sender: camelbones-devel-bounces@...
Subject: Re: [Camelbones-devel] Please help :-(
To: "Matt Sergeant" <matt@...>
Cc: CamelBones Development <camelbones-devel@...>
Date: Fri, Mar 21 12:05:15
On Sun, Mar 16, 2008 at 2:43 PM, Matt Sergeant <matt@...> wrote:
I'm on the verge now. I'm ready to switch wholesale to Ruby Cocoa
instead of CamelBones. I don't WANT to, and that's a lot for me to
learn, but if I have to then I'll just have to.
I spent this morning playing with Rachel's 1.1 beta release, but it's
just missing so much (perl modules in the Framework such as PAR and
the others currently included, and DBIKit for all the supported
platforms) that I can't run with it, and I don't have all the
platforms necessary to be able to build all those things.
What are my options now? Should I just give up and move on, or is
there really anything to hope for on the horizon?
At this point, I've tried all of the obvious solutions to the dyld error we've discussed here on this list.
I'm left with waiting for my muse to inspire me with a new idea, or for someone with better dyld-fu than I to
step forward with an answer. There's no real way to accurately predict when one of those two things will
happen, and I'm reluctant to even hazard a guess.
With the primary show-stopping bug only affecting Panther, I'm beginning to wonder whether continued Panther
support is really worth the effort and/or further delay. I certainly don't use it, and I don't personally know
anyone who does. I don't *want* to drop Panther support - Omni (<http://update.omnigroup.com/&gt;) is showing
"other" at 0.4%, but with millions of Mac users out there, even that small percentage adds up to a *lot* of
users. But, even *more* people are using Leopard than Panther at this point, so dropping Panther (perhaps
temporarily) may be the lesser of two evils.
sherm--
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
Camelbones-devel mailing list
Camelbones-devel@...
https://lists.sourceforge.net/lists/listinfo/camelbones-devel
----- End forwarded message
--
Dan Grillo dan@... 650-299-1470

On Sun, Mar 16, 2008 at 2:43 PM, Matt Sergeant <matt@...> wrote:
> I'm on the verge now. I'm ready to switch wholesale to Ruby Cocoa
> instead of CamelBones. I don't WANT to, and that's a lot for me to
> learn, but if I have to then I'll just have to.
>
> I spent this morning playing with Rachel's 1.1 beta release, but it's
> just missing so much (perl modules in the Framework such as PAR and
> the others currently included, and DBIKit for all the supported
> platforms) that I can't run with it, and I don't have all the
> platforms necessary to be able to build all those things.
>
> What are my options now? Should I just give up and move on, or is
> there really anything to hope for on the horizon?
At this point, I've tried all of the obvious solutions to the dyld error
we've discussed here on this list. I'm left with waiting for my muse to
inspire me with a new idea, or for someone with better dyld-fu than I to
step forward with an answer. There's no real way to accurately predict when
one of those two things will happen, and I'm reluctant to even hazard a
guess.
With the primary show-stopping bug only affecting Panther, I'm beginning to
wonder whether continued Panther support is really worth the effort and/or
further delay. I certainly don't use it, and I don't personally know anyone
who does. I don't *want* to drop Panther support - Omni (<
http://update.omnigroup.com/&gt;) is showing "other" at 0.4%, but with millions
of Mac users out there, even that small percentage adds up to a *lot* of
users. But, even *more* people are using Leopard than Panther at this point,
so dropping Panther (perhaps temporarily) may be the lesser of two evils.
sherm--

I'm on the verge now. I'm ready to switch wholesale to Ruby Cocoa
instead of CamelBones. I don't WANT to, and that's a lot for me to
learn, but if I have to then I'll just have to.
I spent this morning playing with Rachel's 1.1 beta release, but it's
just missing so much (perl modules in the Framework such as PAR and
the others currently included, and DBIKit for all the supported
platforms) that I can't run with it, and I don't have all the
platforms necessary to be able to build all those things.
What are my options now? Should I just give up and move on, or is
there really anything to hope for on the horizon?
Matt.

On 9-Mar-08, at 7:44 AM, Terje Bless wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> sherm.pendley@... (Sherm Pendley) wrote:
>
>> We need templates for the next release anyway, and sometimes it
>> helps to
>> put difficult problems on the back burner
>
> We need a next release, period.
I concur. I'm still waiting on something I can easily download and
get a new DVDSpanner out. I've had about 50 emails about it now, and
it's getting rather depressing telling people to wait.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
sherm.pendley@... (Sherm Pendley) wrote:
>I'm not CEO material, myself, and I know jack about marketing a product. I
>can estimate how much it may cost to build an app, in terms of programmer
>salary, but I don't have a clue what a reasonable marketing budget might
>be for it. But if someone who *is* blessed with those skills needs a
>developer for such a venture wants to talk partnership, I'm all ears. :-)
Well, one of the nice things about venture capital is that they
will usually hook you up with a business savvy person if you
don't already have that. The downside is, of course, that they
want to own your soul. :-)
You can always email <ifund@...> to ask about how much
business savvy you need to bring to the table, and how much they
might be able to help you with there (cf. <http://www.kpcb.com/initiatives/ifund/faq.html&gt;).
I note that in their application form
<http://www.kpcb.com/initiatives/ifund/apply.php&gt; they call out
«your technology stack and any proprietary intellectual
property you have developed or intend to develop», so they may
not be particularly receptive to Open Source projects; but even
if the source is open, if you can tie it to a closed backend
service of some kind, they may still be willing to talk. In the
cases I outlined for the healthcare sector, the specially
adapted databases — built from public, semi-public, or
licensed sources — would be the backend. And, of course,
there's no reason you couldn't develop closed source —
licensing wise — applications using CamelBones.
I think there's a great opportunity here!
- --
>I suggest you attend some sort of anger management class....
That's where you learn to upset the PHBs?
-- Peter
da Silva
-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.10.1
wj8DBQFH0+oIo/I+siR19ewRAjiMAKDiCO0CKDDEgR2plIBhR3tnwtmQyQCdGr09
B6eLcf6FhZuCAvrU/ygaX5YXT
-----END PGP SIGNATURE-----

On Sun, Mar 9, 2008 at 7:34 AM, Terje Bless <link@...> wrote:
Hmm. Do you actually need to run the /usr/bin/perl built for the
> iPhone, or do you need to link them against the libperl that's
> built for the iPhone?
The latter will suffice, if we can live without "make test". We could
conceivably create new targets in Xcode to build the module, instead of
using ExtUtils::MakeMaker as it's done now. It shouldn't be hard, with
EU::MM already showing us exactly what compiler flags we need to use. We
could use Xcode's built-in unit testing too, instead of calling "make test",
should that prove necessary and possible.
BTW, Sherm, you didn't consider writing up a CamelBones related
> proposal for Kleiner Perkins did you? :-)
Are you kidding me? I've been racking my brain for ideas. :-)
I have a few ideas, actually. For instance, an app that used DBD::Proxy
(pure perl, so no compilation worries) could allow for wireless access to an
Oracle, DB2, or any other database. That would certainly help make the
iPhone into a useful tool for businesses.
<http://www.kpcb.com/initiatives/ifund/&gt;
>
> With a cool $100M in venture capital to spread around, it should
> be within their risk-taking levels to start a small Perl on
> iPhone company.
I'm not CEO material, myself, and I know jack about marketing a product. I
can estimate how much it may cost to build an app, in terms of programmer
salary, but I don't have a clue what a reasonable marketing budget might be
for it. But if someone who *is* blessed with those skills needs a developer
for such a venture wants to talk partnership, I'm all ears. :-)
sherm--

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
sherm.pendley@... (Sherm Pendley) wrote:
>Imagine a warehouse worker using a portable app that connects with DBI to
>the inventory database.
Oh I can imagine quite a bit more than that!
Working in Hospital IT, one thing I've learned is that Doctors
absolutely *adore* portable gizmos. They also have an insane
number of specialized applications they need to use. The drug
interactions database, the patient demographic data (their name
and such), diagnostic codes, etc. etc. All of these apps are
things that Perl would excel at delivering, and the iPhone would
be an excellent delivery vehicle for.
There's also the fact that your typical doctor has an average of
5 doo-dahs he carries around. A pager, one or two cell phones, a
DECT or similar phone, a PDA, etc.; they're much much worse then
geeks in this regard. And the iPhone can replace an awful lot of
those gizmos (by having both GSM and WLAN, and the ability to
run a sane VoIP app).
If you add in the critical apps he wants, the iPhone is the
answer to their prayers; Doctors will be buying these in droves.
Did you think it was a coincidence that Jobs' announcement
highlighted a drug interactions app?
Now a lot of the medical apps are stuff like MRI, or CT etc.
that require specialized workstations and huge screens. Or
Electronic Health Record or Patient Administrative Systems that
have so complex interfaces that they need a full desktop
computer. But the stuff they need the most are the various
databases where they look up drug interactions etc., which are
perfect for Perl and the iPhone. These are usually a database
somewhere. They're periodically updated from some central
auuthority. They'll require some text munging, and some
adaptability to survive each individual doctor's demands, and
support a wide array of data sources (DBI, SOAP, screenscraping, etc.).
Were I in the states I'd seriously consider writing up a
proposal for iFund for a startup to build this kind of stuff.
- --
“I don't mind being thought of as a badguy,
but it /really/ annoys me to be thought of
as an *incompetent* badguy!” -- John Moreno
-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.10.1
wj8DBQFH09E3o/I+siR19ewRAptBAJ0ekllgMdMafDOaZb+M7Bv4ORadrACg8Bsl
rKx0cb5IyTto1bhtu98g0+c=shND
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
sherm.pendley@... (Sherm Pendley) wrote:
>We need templates for the next release anyway, and sometimes it helps to
>put difficult problems on the back burner
We need a next release, period.
If we need to push something out that's horribly broken on
Panther, and probably has other issues, then fine; we'll call it
a “Developer Preview”. It's a good way to get fresh eyeballs
on the problem, and on finding other problems lurking in there.
But we need to ship something. Anything. :-)
- --
I have lobbied for the update and improvement of SGML. I've done
it for years.
I consider it the jewel for which XML is a setting. It does
deserve a bit of
polishing now and then.
- -- Len Bullard
-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.10.1
wj8DBQFH082Go/I+siR19ewRApl0AKDwe+2wEYOeruC4ReCY4RWD9zlv6wCg+82M
U51kwgzTGPxmanT0MVdUrPM=1wIs
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
sherm.pendley@... (Sherm Pendley) wrote:
>I just had a very unpleasant thought - Does the iPhone have Perl on it at
>all? If not, we'd need to cross-compile it, and bundle it with the
>framework.
I think it's safe to assume Perl is not available on the iPhone.
It's a space-constrained device, so nuking Perl and such would
probably be the first thing I did if I needed to shrink Mac OS X
to run on it.
>And, whether it's built-in or homegrown, we'd need to be able to run the
>iPhone's Perl in emulation under Xcode, to build any CPAN modules for it -
>including the module component of CamelBones.
Hmm. Do you actually need to run the /usr/bin/perl built for the
iPhone, or do you need to link them against the libperl that's
built for the iPhone?
The thing is, with one thing and another, I doubt you'd be able
to build a module _on_ the iPhone (including its emulator). But
apart from that this seems like the same cross-compilation
problem as for Perl itself?
>I've googled a bit, and found that cross-compiling a perl is quite
>possible, although it's not documented, that I could find. Google turned
>up lots of q&a about it, but no docs.
I'm fairly sure Jarkko did it for Symbian, and p5p should be
willing to help with this.
BTW, Sherm, you didn't consider writing up a CamelBones related
proposal for Kleiner Perkins did you? :-)
<http://www.kpcb.com/initiatives/ifund/&gt;
With a cool $100M in venture capital to spread around, it should
be within their risk-taking levels to start a small Perl on
iPhone company.
- --
“Violence accomplishes nothing.” What a contemptible
lie! Raw, naked
violence has settled more issues throughout history than
any other
method ever employed. Perhaps the city fathers of Carthage
could debate
the issue, with Hitler and Alexander as judges?
-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.10.1
wj4DBQFH08tTo/I+siR19ewRAhoTAKC9oOqVC6BWRQmKRxZ9bCLTpm37TgCYqO+Q
h3t0Bqf/559TK7tvMio14w=
=ksdr
-----END PGP SIGNATURE-----

When we get this dyld bug on Panther figured out, I intend to write a
"Project Template Maker" app. A template has a plist of files, indicating
which are to be copied as-is, and which should have a certain string token
replaced with the project name. Files can also be renamed in the same way.
So, to make a template from a project, all one needs to do is reverse the
process - set up a project with the settings, files, targets, etc. you want,
then replace the project name with the replacement token and create the
.plist.
I created the old templates by just duping a project dir, and doing the
replacement by hand with BBEdit. That was with Project Builder 1.0 projects,
and I've been updating the same old projects, and doing a "convert to
native" at one point, ever since. I'd instantiate the project, make whatever
updates were needed, then use BBEdit's "compare folders" function to patch
the changes back into the template. After all that, there's bound to be some
bit-rot in them at this point.
I might just go ahead and do that sooner rather than later. We need
templates for the next release anyway, and sometimes it helps to put
difficult problems on the back burner - it's like the subconscious is still
working on it or something, I dunno. Anyway, it won't take a whole lot to
write an app to replace some text and create a .plist.
sherm--

On Fri, Mar 7, 2008 at 5:21 PM, Sherm Pendley <sherm.pendley@...>
wrote:
> Great idea, and it fits right in to Apple's business-friendly strategy.
> Imagine a warehouse worker using a portable app that connects with DBI to
> the inventory database.
>
> But it's not going to happen any time soon, at least not from me. I don't
> have an iPhone, and I haven't yet found an OSX86 Leopard disk that agrees
> with my Hackintosh. I do have Leopard, on my G4, but the iPhone SDK requires
> Leopard on Intel.
>
> I'm downloading another iso for my Hackintosh - if I can find a Leopard
> that works with it, I'll grab the iPhone SDK and give it a go. The
> objective-c runtime functions that CB depends upon are low-level stuff that
> all of Cocoa depends upon as well, so I'm not concerned about that. I'd say
> that the $64k question is whether libffi supports the CPU the iPhone uses -
> a 650Mhz ARM, I believe.
I just had a very unpleasant thought - Does the iPhone have Perl on it at
all? If not, we'd need to cross-compile it, and bundle it with the
framework.
And, whether it's built-in or homegrown, we'd need to be able to run the
iPhone's Perl in emulation under Xcode, to build any CPAN modules for it -
including the module component of CamelBones.
I've googled a bit, and found that cross-compiling a perl is quite possible,
although it's not documented, that I could find. Google turned up lots of
q&a about it, but no docs.
sherm--

Great idea, and it fits right in to Apple's business-friendly strategy.
Imagine a warehouse worker using a portable app that connects with DBI to
the inventory database.
But it's not going to happen any time soon, at least not from me. I don't
have an iPhone, and I haven't yet found an OSX86 Leopard disk that agrees
with my Hackintosh. I do have Leopard, on my G4, but the iPhone SDK requires
Leopard on Intel.
I'm downloading another iso for my Hackintosh - if I can find a Leopard that
works with it, I'll grab the iPhone SDK and give it a go. The objective-c
runtime functions that CB depends upon are low-level stuff that all of Cocoa
depends upon as well, so I'm not concerned about that. I'd say that the $64k
question is whether libffi supports the CPU the iPhone uses - a 650Mhz ARM,
I believe.
sherm--
On Fri, Mar 7, 2008 at 3:51 AM, Terje Bless <link@...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> So any of you lot have iPhones? Any chance I'll be able to write
> iPhone apps in CamelBones Perl in the near future? :-)
>
> - --
> >Did you notice the three words "hurricane relief work" in there?
> I think we've just discovered a new corollary to Godwin's Law.
>
> - Rich Siegel <siegel@...>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP SDK 3.10.1
>
> wj8DBQFH0QIOo/I+siR19ewRAq00AJ9CHlxnGBZVkD/CFFzhur2r0NhrEQCgosIy
> lWd/KR2rmYmbkU1PLbu1cl0=ohuj
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Camelbones-devel mailing list
> Camelbones-devel@...
> https://lists.sourceforge.net/lists/listinfo/camelbones-devel
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So any of you lot have iPhones? Any chance I'll be able to write
iPhone apps in CamelBones Perl in the near future? :-)
- --
>Did you notice the three words "hurricane relief work" in there?
I think we've just discovered a new corollary to Godwin's Law.
- Rich Siegel <siegel@...>
-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.10.1
wj8DBQFH0QIOo/I+siR19ewRAq00AJ9CHlxnGBZVkD/CFFzhur2r0NhrEQCgosIy
lWd/KR2rmYmbkU1PLbu1cl0=ohuj
-----END PGP SIGNATURE-----

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details