lvalue cast warnings
Andy Dougherty
warnings. If memory serves, there are other compilers that don't
like lvalue casts as well.
"closure.pmc", line 21: warning: a cast does not yield an lvalue
"closure.pmc", line 48: warning: a cast does not yield an lvalue
"continuation.pmc", line 20: warning: a cast does not yield an lvalue
"coroutine.pmc", line 20: warning: a cast does not yield an lvalue
"retcontinuation.pmc", line 22: warning: a cast does not yield an lvalue
"retcontinuation.pmc", line 29: warning: a cast does not yield an lvalue
"sub.pmc", line 20: warning: a cast does not yield an lvalue
"sub.pmc", line 62: warning: a cast does not yield an lvalue
--
Andy Dougherty doug...@lafayette.edu
Simon Glover
On Fri, 29 Aug 2003, Andy Dougherty wrote:
> On a fresh checkout today, my Solaris C compiler issued the following
> warnings. If memory serves, there are other compilers that don't
> like lvalue casts as well.
lcc & tcc to name two; only with these, it's an error, not just a
warning.
Simon
Leopold Toetsch
> "closure.pmc", line 21: warning: a cast does not yield an lvalue
tcc fails totally. Its of cource me to blame :-)
What is the "official" way here:
- don't do that, its really forbidden (why)
- create another macro acround that?
The lvalue usage isn't to often, but it would be handy to have the same
thing as in RHS to just hide the interface (until things have settled -
I'm not a friend of these macros. They are necessary as long as such
structures like PMC are still in flux).
leo
Nicholas Clark
> Andy Dougherty <doug...@lafayette.edu> wrote:
>
> > "closure.pmc", line 21: warning: a cast does not yield an lvalue
>
> tcc fails totally. Its of cource me to blame :-)
>
> What is the "official" way here:
> - don't do that, its really forbidden (why)
(IIRC) ANSI C forbits lvalue casts. (obviously) gcc is quite happy with these
IIRC HP-UX's C compiler and AIX's C compiler barf on these, with the result
that Merijn usually smokes these things out pretty quickly for perl5
> - create another macro acround that?
I think that the appended patch will work around the problem, by doing
the case on the pointer (which is an RVALUE) and then deferencing.
But currently I only have access to systems with gcc, so I can't test
on something pickier. (mmm. might be able to get x86 lcc installed
at some point)
Nicholas Clark
--- include/parrot/sub.h.orig 2003-08-29 21:09:19.000000000 +0100
+++ include/parrot/sub.h 2003-08-29 21:14:26.000000000 +0100
@@ -33,7 +33,7 @@ typedef struct Parrot_Sub {
char *packed; /* to simplify packing Constant Subs */
} * parrot_sub_t;
-#define PMC_sub(pmc) ((parrot_sub_t)((pmc)->cache.pmc_val))
+#define PMC_sub(pmc) (*((parrot_sub_t *)&((pmc)->cache.pmc_val)))
/* the first entries must match Parrot_Sub, so we can cast
* these two to the other type
Leopold Toetsch
> -#define PMC_sub(pmc) ((parrot_sub_t)((pmc)->cache.pmc_val))
> +#define PMC_sub(pmc) (*((parrot_sub_t *)&((pmc)->cache.pmc_val)))
This seems to work. Thanks for the patch.
(the tcc tinderbox seems to be missing a make realclean/Configure or
such though)
leo
Benjamin Goldberg
Hmm, maybe we should define a new macro, to make this easier in the
future:
#ifdef __gcc
#define LVALUE_CAST(type, val) ((type)(val))
#else
#define LVALUE_CAST(type, val) (*((type *)&(val)))
#endif
Then, PMC_sub becomes:
#define PMC_sub(pmc) LVALUE_CAST( parrot_sub_t, (pmc)->cache.pmc_val )
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Andy Dougherty
> > Andy Dougherty <doug...@lafayette.edu> wrote:
> >
> > > "closure.pmc", line 21: warning: a cast does not yield an lvalue
> I think that the appended patch will work around the problem, by doing
> the case on the pointer (which is an RVALUE) and then deferencing.
> --- include/parrot/sub.h.orig 2003-08-29 21:09:19.000000000 +0100
> +++ include/parrot/sub.h 2003-08-29 21:14:26.000000000 +0100
> @@ -33,7 +33,7 @@ typedef struct Parrot_Sub {
> char *packed; /* to simplify packing Constant Subs */
> } * parrot_sub_t;
>
> -#define PMC_sub(pmc) ((parrot_sub_t)((pmc)->cache.pmc_val))
> +#define PMC_sub(pmc) (*((parrot_sub_t *)&((pmc)->cache.pmc_val)))
>
> /* the first entries must match Parrot_Sub, so we can cast
> * these two to the other type
>
Thanks. That worked just fine.
Andy Dougherty doug...@lafayette.edu
Clemens Eisserer
I惴 a java programmer and I惴 not really experienced with perl.
But I扉e searched a long time for a system like .NET that can愒 be
controlled by Microsoft through Patents.
Imagine 10.000 apps need the .NET api ruuning on mono, and microsoft
permits cloning the .NET api.
Maybe 5000 of these 10.000 apps are unmaintained, and even using these
apps with an older version of mono would not be legal.
The other 5.000 will need weeks to create a patent-free version of there
software, till MS finds another point which could be destroyed using
patents.
And, after the fist change Mono wont be compatinble to .NET at all, so
why dont create a patent-free .NET from the beginning.
I searched a long time for such a project, and after all I found it
where I never expected it: Perl ;-)
I really like languages which are deployed compiled to bytecode, no
problems with ABI-changes or with compiliers, once compiled link everywhere.
Thats the reason why I linke Java really much, but there are some
points, which are really showstoppers: *Java isnt free, *Swing is toooo
slow to be useful.
In my opinion runtimes only make sence when they dont need to rely on
native code.
It doesnt make sence that parrot is platform independent and I need to
"link" against native libraries through bindings, because perl愀
"classpath" lacks e.g. GUI functionality.
Mono solves this problem like Java - they just include every class which
could be useful. Maybe this design is to heavyweight....
Hmm, I talked a too long time to myself, I know ;-)
So, heres my question:
I think that parrot could be the Gnu-version of .NET and could be a
realy benefit for the whole opensource-world. No 20 runtimes need to be
installed on a system - parrot would do the job better than each could
alone (Because if many apps rely on parrot the JIT will be tuned by guys
from IBM ;-) ).
But in my opinion parrot needs a more complete "classpath" that perl5
currently has.
Parrot is another level like perl5, perl5 was fine for scripting and
even bigger apps worked great, bt it never tried to be a complete
framework for many languages.
Parrot is in my eyes a way to go away from C to higher level languages.
So, my question: Is it planned to include a complete classpath into
parrot, including gui, network, db, sound functionality or will it have
only the "really needed" things like perl5 had?
I know that everything is already available for perl5 installing
bindings, but in my eyes this doesnt solve the problem.
Many users dont want to install seperat libraries, they simply want to
use parrot based apps with nice frontends, etc.
I hope I didnt make you angry, and please dont missunderstand me, I
think what you do is great!
Please let me know what you think about the idea to include a "complete"
classpath into parrot.....
lg Clemens
James Michael Dupont
--- Clemens Eisserer <linux...@web.de> wrote:
> But I´ve searched a long time for a system like .NET that can´t be
> controlled by Microsoft through Patents.
I am also concerned about the control of patents, and the DotGnu(TM)
team implementing patented interfaces that are of questionable value.
Please note that ECMA sumbitted code is *not* covered by patents.
In fact in my mail to the dotgnu list that got me banned,
http://dotgnu.org/pipermail/pnet-developers/2003-August/000511.html
I questioned the value of implemented this CodeDom interface.
"""
> - finish CodeDom and write a test suite
I have done an analysis of the codedom last year. This is definitly
something that I am interested in. In fact, I think we might want
to
create dotgnu replacement for thatt, because it is not standard and
part of the patent application : 20030028685
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=/netahtml/PTO/srchnum.html&r=1&f=G&l=50&s1='20030028685'.PGNR.&OS=DN/20030028685&RS=DN/20030028685
United States Patent Application, 20030028685.
System.CodeDom.Compiler.txt
I have some ideas about how this replacment might look, in fact, my
working model is much more fine tuned, and would allow code on the
finiest expression level to be created.
"""
> So, my question: Is it planned to include a complete classpath into
> parrot, including gui, network, db, sound functionality or will it
> have
> only the "really needed" things like perl5 had?
There are numerous plans to convert java to IL.
There is a project in DotGnu(TM) for a java frontend.
There is a plan to have a parrot backend for dotgnu.
Please not that I am not speaking for anyone except myself,
Gruss züruck,
mike
--------------
All trademarks (DotGnu) are owned by thier respective owners, In no way
should you interpret my statements about them as any promise of support
of these ideas by the Owners to the intellectual property named
"DotGNU".
=====
James Michael DuPont
http://introspector.sourceforge.net/
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Luke Palmer
> Hi there!
>
> I卒m a java programmer
Uh oh :-)
> and I卒m not really experienced with perl.
>
> [...]
>
> I think that parrot could be the Gnu-version of .NET and could be a
> realy benefit for the whole opensource-world. No 20 runtimes need to be
> installed on a system - parrot would do the job better than each could
> alone (Because if many apps rely on parrot the JIT will be tuned by guys
> from IBM ;-) ).
>
> But in my opinion parrot needs a more complete "classpath" that perl5
> currently has.
There is a big problem with that: it kinda precludes the whole
"community" thing that made everyone love Perl 5. In particular, CPAN.
The plan for Perl 6, at least, is to include almost nothing in the base
distribution, so administrators are forced to install some stuff from
CPAN order for Perl to be useful at all[1].
We need to harness the community work force of CPAN, for one because we
don't have the work force ourselves to put together such a library. But
the bigger reason is to enable the community to write modules, so we
always have forward progress on the language.
> Parrot is another level like perl5, perl5 was fine for scripting and
> even bigger apps worked great, bt it never tried to be a complete
> framework for many languages.
> Parrot is in my eyes a way to go away from C to higher level languages.
>
> So, my question: Is it planned to include a complete classpath into
> parrot, including gui,
maybe
> network,
yes
> db,
no
> sound functionality
no
> or will it have only the "really needed" things like perl5 had?
> I know that everything is already available for perl5 installing
> bindings, but in my eyes this doesnt solve the problem
> Many users dont want to install seperat libraries, they simply want to
> use parrot based apps with nice frontends, etc.
Ahh, I see what you mean. You want to distribute your app and parrot
and have it Just Work. You can always include the needed modules in
your distribution and install them when you get there... but that kills
the platform independence thing. You could tell parrot to install them
when you get there off the CPAN automatically, but from a commercial
standpoint, that puts all your users in the hands of a -- possibly
mischievous -- module author (though I don't know any authors who would
do such a thing, it's still a concern).
There will be a solution to the commercial thing. One of the (smaller)
goals of Perl 6 is to be used commercially to some extent.
A bigger goal, though, is to keep the open source support we already
have. Including a big default classpath makes people feel like
everything is "easy enough," which, ironically, isn't easy enough. It
doesn't motivate people to write/install modules.
So there you go, we're including everything we need to make the Easy
Things Possible, and the community will worry about making them Easy.
Luke
>
> I hope I didnt make you angry, and please dont missunderstand me, I
> think what you do is great!
>
> Please let me know what you think about the idea to include a "complete"
> classpath into parrot.....
>
> lg Clemens
>
>
[1] This was a big problem in Perl 5: admins would install Perl, and
assume that it's ready because it already comes with, like, 40 modules.
And then nobody could use it, because there were no good modules
installed.
Clemens Eisserer
Wow, thanks for thinking about my ideas. I expected that you call me a
troll, but it seems that there are cool people here ;-)
O.K. lets simply call it class-library.
> It doesn't seem to be the Perl way to limit yourself to one option
> only ("There's more than one way to do it"). Of course we wouldn't
> want five different implementations of Unicode, and it makes sense to
> ship _one_. However, people might want to use different GUIs --
> e.g. wxWindows, TK, native Windows GUI, Aqua, ...
In my opinion wxWindows would be fine with a nice api-binding.
The C++-Api is terrible, but the toolkit itself seems to offer quite
cool features.
I would prefer wxWindows, because they did what Sun didnt continue.
One API many toolkits, small library-size.
Of course, many people have different tastes, but look at Java (thats
the world where I come from).
swing is slow and ugly, but nearly 97% of all java programs use it
because its shipped with java since 1.2...
Look at TCL, TK is used because it integrates well with TCL.
If one really doesnt like wxWindows, he can of course provide other
libraries.
But the mainstream will use the libraries provided with the runtime.
> Sound is a whole different beast -- implementations vary
> wildly across systems, and I'm not sure whether it is possible to have
> a high-performance cross-platform implementation that satisifes 90% of
> users.
SDL shows that this is possible.
Of course, its often a problem of portability.
But developers also have to think about portability. If the
class-libraries shipped with a runtime-enviroment are available across
most ports, they dont have to use 3 different bindings to different
native libs. They can simply use the api implemented in the
class-library and work with it.
For the developers of the class library this is of course hard work and
the runtime often gets big.
> - Parrot bytecode executables might be packages that contain the
> necessary libraries in bytecode format (e.g. wxWindows).
> - Installers might include libraries (in bytecode) and install
> them if needed (install = simple copy)
Bytecode-packages are typically no problem. They are small and only
depend on libraries provieded by the enviroment.
> For binary (platform-dependant) packages:
>
> Usually, people just ship these statically linked against those libs
> that can't be typically expected to be installed on the system.
> So I guess for Parrot apps distributed in binary, there's not much of
> a problem. For apps shipped as bytecode, it still needs to be
> discussed what is going to be provided:
>
> - Preferably a small package (< 5 - 10 MB) that lets people use Parrot
> apps
> quickly.
>
> - A huge package complete with
> Perl/Python/PHP/Befunge/hq9+/... support so that everybody will have
> 95% of everything they are ever gonna need
>
> - Or both?
Of course, both would be best ;-).
In my opinion it would be best, to provide a native basis.
"Lightweight"-libraries could do the rest.
However the user has to install native libraries, he has the good old
problems:
*ABI problems
*Dependencies
*............
Of course, in parts where high-performance is needed, this wont be a
good solution.
Of course it would be fine to have a package that only weights 5Mb, but
what if the user needs to install 3 different libraries so that the user
can use its program.
Imagine how much fits in a 15Mb RPM.....
A very important thing is in my eyes, that bindings can be created
without the need of native code. e.g. JNI-bindings need to be written
using C, theres no way to do everything in Java.
Maybe I can help creating such a class-library?
How hard do you think will it be to create a library which works good
for many languages. E.G. Java has interfaces, I dont know about perl or
python. But I´m sure perl has language features that java doesnt have....
Mochts as guat, Clemens *real Austrian slang*
Dan Sugalski
>Hi there!
>
>I´m a java programmer and I´m not really experienced with perl.
>
>But I´ve searched a long time for a system like .NET that can´t be
Do be aware that Microsoft may still hold patents that affect Parrot,
as might IBM, HP, and whoever owns what used to be Bell Labs these
days. Amongst others. Independent development is *no* protection
against patents. Just ask the other guys who independently invented
the telephone. (Remember them? No? Neither does anyone else :)
>I really like languages which are deployed compiled to bytecode, no
>problems with ABI-changes or with compiliers, once compiled link
>everywhere.
>Thats the reason why I linke Java really much, but there are some
>points, which are really showstoppers: *Java isnt free, *Swing is
>toooo slow to be useful.
Erm--bytecode doesn
>I think that parrot could be the Gnu-version of .NET and could be a
>realy benefit for the whole opensource-world. No 20 runtimes need
>to be installed on a system - parrot would do the job better than
>each could alone (Because if many apps rely on parrot the JIT will
>be tuned by guys from IBM ;-) ).
We thought the same about Java when it came out. Alas you'll find a
half-dozen different JVMs installed on some systems. (Not, mind, that
I want to do the same, but it is possible that it'll happen)
>But in my opinion parrot needs a more complete "classpath" that
>perl5 currently has.
Hrm? I'm completely lost here. Library search functionality should be
at least as good, if not better, than perl 5, and it's been my
experience that perl 5's library search capabilities were better than
any Java I've had the misfortunte to deal with. Might just have had
some bad experiences.
>So, my question: Is it planned to include a complete classpath into
>parrot, including gui, network, db, sound functionality
No. Networking yes, probably some DB functionality (at least DBI and
xDBM style access, though unlikely no actual SQL DB drivers. Possibly
flat file SQL access, we'll see), but no sound or GUI stuff. That's
all very platform-specific, or really really ugly.
Not to say that there won't be good cross-platform libraries--I'd be
thrilled if there was a good Tk or wXwindows library for Parrot, but
we're not going to ship with them.
>Please let me know what you think about the idea to include a
>"complete" classpath into parrot.....
If you want a complete *library* shipping with Parrot, you're going
to be rather disappointed I'm afraid.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Dan Sugalski
>Clemens Eisserer writes:
>> Hi there!
>>
>
>Uh oh :-)
>
>> and Ië¾m not really experienced with perl.
>>
>> [...]
>>
>> I think that parrot could be the Gnu-version of .NET and could be a
>> realy benefit for the whole opensource-world. No 20 runtimes need to be
>> installed on a system - parrot would do the job better than each could
>> alone (Because if many apps rely on parrot the JIT will be tuned by guys
>> from IBM ;-) ).
>>
>> But in my opinion parrot needs a more complete "classpath" that perl5
>> currently has.
>
>There is a big problem with that: it kinda precludes the whole
>"community" thing that made everyone love Perl 5. In particular, CPAN.
>
>The plan for Perl 6, at least, is to include almost nothing in the base
>distribution, so administrators are forced to install some stuff from
>CPAN order for Perl to be useful at all[1].
Not entirely true. There's going to be a decoupling between the core
distribution, mainly parrot and its supporting stuff, and perl (and
python, and ruby) but there'll be an all-in-one install for them all,
so a trip to CPAN won't actually be necessary.
Christian Renz
>"classpath"
I guess the proper term would be class library. The path is only where
you look for the libraries :).
It doesn't seem to be the Perl way to limit yourself to one option
only ("There's more than one way to do it"). Of course we wouldn't
want five different implementations of Unicode, and it makes sense to
ship _one_. However, people might want to use different GUIs --
e.g. wxWindows, TK, native Windows GUI, Aqua, ... Basic network
classes, on the other hand, might be something that might be shipped
with Parrot. Sound is a whole different beast -- implementations vary
wildly across systems, and I'm not sure whether it is possible to have
a high-performance cross-platform implementation that satisifes 90% of
users.
On the other hand, I don't think we only have the choice between
shipping all libraries like Java and having a complicated install
system (for the average GUI-loving end user) like CPAN. There's a
couple of middle options:
For bytecode based packages:
- Parrot bytecode executables might be packages that contain the
necessary libraries in bytecode format (e.g. wxWindows).
- Installers might include libraries (in bytecode) and install
them if needed (install = simple copy)
For binary (platform-dependant) packages:
Usually, people just ship these statically linked against those libs
that can't be typically expected to be installed on the system.
So I guess for Parrot apps distributed in binary, there's not much of
a problem. For apps shipped as bytecode, it still needs to be
discussed what is going to be provided:
- Preferably a small package (< 5 - 10 MB) that lets people use Parrot apps
quickly.
- A huge package complete with
Perl/Python/PHP/Befunge/hq9+/... support so that everybody will have
95% of everything they are ever gonna need
- Or both?
Liebe Grüße,
Christian (since you started the German greetings thingie ;-))
--
cr...@web42.com - http://www.web42.com/crenz/ - http://www.web42.com/
"Surely what a man does when he is taken off his guard is the best evidence
for what sort of man he is." -- C.S. Lewis, Mere Christianity
Dan Sugalski
>Clemens,
>
>>"classpath"
>
>I guess the proper term would be class library. The path is only where
>you look for the libraries :).
>
>It doesn't seem to be the Perl way to limit yourself to one option
>only ("There's more than one way to do it").
I'd worry less about the Perl way to do it, since we're more
concerned with the Parrot way to do it, and that's when we have one
way that's good enough we ship it, so people don't have to re-invent
the bikeshed, or choose from a half-dozen identically shaped but
different colored sheds. Which means that we ship a core that's as
small as feasable, and an add-on pack (which we'll likely also ship
with the core for an all-in-one install) with the best things we can
find that are cross-platform enough to be useful.
That means we'll shoot for a good set of networking modules for the
various RFC protocols, a generic SQL database front-end, an (ick :)
XML parser, a variety of cross-platform tools (filename conversions
and whatnot), a set of xDBM interface modules, and some other stuff.
Don't forget there is an issue of us wanting to be a good core for
more than just perl. The Python parrot package would have Python's
standard module set, the Ruby package would have ruby's modules, and
the Perl package would have the perl modules. There's a fair amount
of overlap and I expect people both want their modules and *don't*
want two or three alternate versions of the same modules installed. I
could be wrong, of course.
GUI stuff's a massive pain, as you either get cross-platform which is
ugly and awkward everywhere, or platform-specfic and useless anywhere
but on the platform in question. And I'm pretty sure that, no matter
*how* Insanely Great the OS X Cocoa interface modules are, they're
not going to do MSWin folks much good. :)
As for sound... Yeesh. There's a swamp I don't have enough castles for.
However, since we have a good native interface it should mean that
many modules that now require a compiler for can be done entirely in
parrot bytecode, which should mean that it's far easier for people to
install and reduce a lot of the pain. Also we've a fair amount of
experience in the perl world with network module installation
systems--we know some things that do work, and some things that
don't, and I expect we should be able to leverage that to make a
system better than what we have now. (Which, honestly, is pretty
darned good, especially given the limited information it has
available to work with)
Damien Hogan
> At 8:53 PM +0200 9/1/03, Christian Renz wrote:
> >Clemens,
> >
> >>"classpath"
> >
> >I guess the proper term would be class library. The path is only where
> >you look for the libraries :).
> >
> >It doesn't seem to be the Perl way to limit yourself to one option
> >only ("There's more than one way to do it").
>
> I'd worry less about the Perl way to do it, since we're more
> concerned with the Parrot way to do it, and that's when we have one
> way that's good enough we ship it, so people don't have to re-invent
> the bikeshed, or choose from a half-dozen identically shaped but
> different colored sheds. Which means that we ship a core that's as
> small as feasable, and an add-on pack (which we'll likely also ship
> with the core for an all-in-one install) with the best things we can
> find that are cross-platform enough to be useful.
>
> That means we'll shoot for a good set of networking modules for the
> various RFC protocols, a generic SQL database front-end, an (ick :)
> XML parser, a variety of cross-platform tools (filename conversions
> and whatnot), a set of xDBM interface modules, and some other stuff.
Do you imagine that the stock XML parser or xDBM will be written in a parrot language
or will it be a c lib used through NCI?
>
> Don't forget there is an issue of us wanting to be a good core for
> more than just perl. The Python parrot package would have Python's
> standard module set, the Ruby package would have ruby's modules, and
> the Perl package would have the perl modules. There's a fair amount
> of overlap and I expect people both want their modules and *don't*
> want two or three alternate versions of the same modules installed. I
> could be wrong, of course.
Is one of the advantages of a multi-language interp not to combine the
libraries of each language, to capitalize on the strength found in one
language for the benefit of the other? And would a unification of those libraries
be outside the scope of parrot or would it fit right in?
>
> GUI stuff's a massive pain, as you either get cross-platform which is
> ugly and awkward everywhere, or platform-specfic and useless anywhere
> but on the platform in question. And I'm pretty sure that, no matter
> *how* Insanely Great the OS X Cocoa interface modules are, they're
> not going to do MSWin folks much good. :)
>
> As for sound... Yeesh. There's a swamp I don't have enough castles for.
>
> However, since we have a good native interface it should mean that
> many modules that now require a compiler for can be done entirely in
> parrot bytecode, which should mean that it's far easier for people to
> install and reduce a lot of the pain. Also we've a fair amount of
> experience in the perl world with network module installation
> systems--we know some things that do work, and some things that
> don't, and I expect we should be able to leverage that to make a
> system better than what we have now. (Which, honestly, is pretty
> darned good, especially given the limited information it has
> available to work with)
I want to ask for clarification here. You mean that the design of NCI
will allow c libs to be wrapped using just parrot code instead of additional
c code as in XS?
I agree that the perl system is pretty darned good. But I don't know if our
admins (who make there lives very difficult with lack of user policy vision)
would agree. I believe they would says it's the best of the other languages they
work with except for c/c++. I also would agree that the libtool/autoconf system
is more reliable then some of the XS code available from CPAN. And although this
does not bother me because I enjoy working with perl. They really don't care what
the boxes do as long as the boxes are doing it.
Also building a mysql/apache/mod_perl/libxml/ environment is very challenging WRT customers
and clients. In very few instances would I expect a low level admin to accomplish such a task
in a reasonable amount of time.
Knowing very little about this stuff I have always wondered why I need to rely so heavily on
certain features of the installed system. I would like to compile byte code that includes the
byte code for modules I am using. I realize that creates a certain undesired coupling. But in
some instances especially WRT to client/customer apps it would prevent upgrading modules
outside of your control.
> --
> Dan
>
> --------------------------------------"it's like this"-------------------
> Dan Sugalski even samurai
> d...@sidhe.org have teddy bears and even
> teddy bears get drunk
--
Be nice I'm new
Damien Hogan