> If you're looking for something to do, we *always* have good
> little jobs for people. :)
Great!
> 6) A test suite! My kingdom for a test suite!
I had a first stab at it; attached module + sample script,
for discussion only, because it is a kludge; I'll tidy it up
this evening.
Questions:
> To Schwern:
> * Test::Parrot ( or whatever ), needs to be special cased
> in Test::Simple::ok ( as Test::More is ), to report test
> line correctly.
A Test::Simple function to know the actual test number would
be nice, too.
Regards
Mattia
Run with
perl -Mlib=lib t/harness
Tests live in t/*/*.t .
In case of failure the assembler, bytecode and output
are available as t/dir/testnnn.pasm/pbc/out
tested under Linux and Win32
Regards
Mattia
--patch--
diff -r -b -u -2 -N parrot.cvs/lib/Test/Parrot.pm
parrot/lib/Test/Parrot.pm
--- par
> On Thu, Sep 13, 2001 at 11:07:00AM -0600, Nathan Torkington wrote:
> > Isn't the correct solution to this problem to say
> >#include
> >
> > That is, include the subdirectory prefix in all #includes. You -I the
> > directory containing parrot/, and that avoids randomly located
> > config.
This patch adds:
an hints directory ( files are named hints/lc($^O).pl )
therir contents are eval'd in Config.pl
it adds to Config.pl some flags
--debugging Enable debugging
adds -g or equivalento to compiler flags
--defaults Accept all default values
like -d option to
> PLEASE can someone rewrite the tests to actually *test* things
> and print "ok 1\n" and so on?
Here it is ( for the second time )
> Quick, or I'll call Schwern in.
Ah, I thought you missed my patches, then I was correct
both attached
testsuite.diff:
-
Run with
perl
> ## +#if defined(WIN32)
> ## +program_code = malloc( file_stat.st_size );
> ## +#else
>
> #Should we be using malloc, or are we supposed to use our own allocator?
> #(I haven't been munging in the C, so I don't really know--it just looks
> #a little suspicious.)
>
> In memory.{h,c} there is
> I have a question on your test suite.
> Would backticks not be more portable then trying to figure out how to
> redirect STDOUT on each OS? To me, it would just be simpler to use the
No, I don't need to "figure out", I just execute a
perl -e ".redirections...;system '$command'";
where re
Changes from the last one:
* some tidying in the assembly
( now uses set I4, 4 instead of set_i_ic I4, 4 )
* moved lib/Test/Parrot.pm to Parrot/Test.pm
* now run with perl t/harness
Regards
Mattia
diff -r -b -u -2 -N parrot.cvs/Parrot/Test.pm parrot/Parrot/Test.pm
--- parrot.cvs/Parrot/Tes
This patch adds:
* Win32 compilation ( of course! )
* Configure.pl
--debugging Enable debugging
--defaults Accept all default values
--define name=value Defines value name as value
--help This text
--versionShow assembler version
Suppor
there is something wrong with, uh, something...
Currently substr is named substr_s_s_i.
if I write substr_s_s_i S9, S1, I0, I1, all is good.
if I write substr S9, S1, I0, I1, I get an assembler error.
Questions:
* All opcodes include the destination register type in the name
why substr is diffe
On Tue, 18 Sep 2001, H.Merijn Brand wrote:
>On Mon 17 Sep 2001 23:08, Ask Bjoern Hansen <[EMAIL PROTECTED]> wrote:
>>
>> oops, I forgot to tell anyone. I made CVS export and tar up a
>> snapshot every 6 hours. It is available at
>> http://cvs.perl.org/snapshots/parrot/
>
>Any chance on rsync? I
On Mon, 17 Sep 2001, Gregor Purdy wrote:
Rename it to 'read':
perl 5.5 dos not dvin HAV_SYSMMAN, so the altrnativ ode
it piks th altrnativ code.
Renaming it to read() workd for MSVC5 ( whih defines an alias
from _read to read ), and for older perls on *NIX
don't know for MinGW, though
( In fact
This patch contains different things.
If you prefer three smaller patches,
just speak, I'll resend.
* Configure.pl
* 5.004_04 does not have $Config{_o}, $Config{_exe},
use obj_ext, and exe_ext
* Use ExtUtils::Manifest for manifest parsing
( now you can put blank lines/comments/
> Easy Makefile.in patch. I was worried that Win32 might need the linker
> (the change to $(LD) was submitted as part of a Win32 compatibility
> patch) but that doesn't seem to be the case. I don't have a MinGW
Fine here
Regards
Mattia
set I2, -2147483648
print I2
print "\\n"
set I3, 4294967295
print I3
print "\\n"
end
CODE
305419896
-1698898191
2147483647
-2147483648
-1
OUTPUT
I think that especting 4294967295 == -1 because they have the same
bit pattern
> On Tue, 18 Sep 2001, H.Merijn Brand wrote:
>
> > On Mon 17 Sep 2001 23:08, Ask Bjoern Hansen <[EMAIL PROTECTED]> wrote:
> > >
> > > oops, I forgot to tell anyone. I made CVS export and tar up a
> > > snapshot every 6 hours. It is available at
> > > http://cvs.perl.org/snapshots/parrot/
> >
>
here it is.
I'll release Parrot::Smoke 0.01 tomorrow,
promise.
*PLEASE* - change _read to read in test_main.c
- correct integer.t, test 1
not to test 0x == -1
( that's why we have got all F... )
Regards
Mattia
Automated smoke report for patch ?
These are the minimal fixes for smoking to take effect.
After these are in, I'll release Parrot::Smoke
* Makefile.in
* it is $(INC)/config.h, not config.h
* .o => $(O)
* test_main.c
* _read was ok when it was inside
ifdef WIN32
now it must be read ( or it fails in
no
Automated smoke report for patch Sep 20 00:00:02 2001
v0.01 on MSWin32 using cl version
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: - = unknown
c = Configure, m = make, t = make test-
> + cd t; make realclean
( from MM_Unix, sub clean
if ($Is_Win32 && Win32::IsWin95()) {
push @m, <{MAKEFILE}
\$(MAKE) clean
cd ..
EOT
}
else {
push @m, <{MAKEFILE} && \$(MAKE) clean
EOT
}
If you could change it to
cd t
PROTECTED]
Subject:CPAN Upload: M/MB/MBARBON/Parrot-Smoke-0.01.tar.gz
From: PAUSE <[EMAIL PROTECTED]>
To: "Mattia Barbon" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
[ Double-click this line for list subscription options
On Thu, 20 Sep 2001, Brent Dax wrote:
>Mattia Barbon:
># Automated smoke report for patch Sep 20 00:00:02 2001
># v0.01 on MSWin32 using cl version
>...
># MSWin32 --defaults --define iv=int --define nv=float
># MSWin32 --debugging --defaults --defi
not ok 15 - gt_nc_ic
# Failed test (Parrot/Test.pm at line 74)
# got: undef
# expected: 'ok 1
ok 2
ok 3
'
So Test::Harenss keeps whining about test 2 answrd ( yes, the PC
with the brokn keyboard again ) after test 9, and such.
Could output be changed to anyting else?
Thanks
Mat
It is gcc 2.95.2, not 2.8.1
*SMACK* to anyone kept the perl scripts
compatible with perl 5.004_04
Regards
Mattia
P.S.: Suggstions about how to make report lins shorter
*VERY* welcome
-- Forwarded message --
Automated smoke report for patch Sep 21 07:00:01 2001 UTC
> 'C:Perinperl.exe' is not recognized as an internal or external command,
> operable program or batch file.
Apply this for the C:Perinperl.exe problem
Sorry for the inconvenience.
Mattia
Index: Parrot/Test.pm
===
RCS file: /ho
This looks really nice...
Regards
Mattia
--- Forwarded message follows ---
Automated smoke report for patch Sep 22 07:00:00 2001 UTC
v0.01 on linux using cc version 2.95.2 2313 (Debian GNU/Linux)
O = OK
F = Failure(s), extended report at the bottom
? = still running
t/op/number.t is basically testing that
the rounding behaviour is the same across all
platforms. This is ***wrong***.
Regards
Mattia
--- Forwarded message follows ---
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Subject:Parrot Smoke S
I'd be sending 3 smoke reports ( Win2k/MSVC, x86/Linux,
Alphs/Tru64/GCC ) per snapshot, and maybe I will
start on cygwin and Win2k/MinGW, too.
Before I spam everyone with this,
is someone interested in it, and if so,
should I continue sending it to perl6-internals,
or is is preferable a different
--- Forwarded message follows ---
Automated smoke report for patch Sep 22 13:00:00 2001 UTC
v0.01 on dec_osf using gcc version 2.95.2
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: -
GRRR... always use reply yo all...
--- Forwarded message follows ---
From: Mattia Barbon <[EMAIL PROTECTED]>
To: Simon Cozens <[EMAIL PROTECTED]>
Subject:Re: Tru64 Numeric bug exposed!
Copies to: [EMAIL PROTEC
the t/op/trans failures are because the test
returns no output
( runnig by hand
[parrpt]$ perl Configure.pl --defaults --define cc=gcc --define
ccflags="-O3 -Iinclude" --define iv=long --define nv=double
[parrot]$ make
[parrot]$ for i in t/op/number*.pbc ; do ./test_prog $i; done
Segmentation fau
> cvsuser 01/09/22 10:20:59
>
> Modified:.Makefile.in
> Added: Test More.pm Simple.pm Utils.pm
> Log:
> I'm sick of having to install Test::More everywhere. Temporary measure
> until we remove this silly dependency.
I promise I'll do it after 0.02 is out.
Matt
> On Sun, Sep 23, 2001 at 12:27:53AM +0200, Mattia Barbon wrote:
> > [parrpt]$ perl Configure.pl --defaults --define cc=gcc --define
> > ccflags="-O3 -Iinclude" --define iv=long --define nv=double
> > [parrot]$ make
> > [parrot]$ for i in t/op/number*.pb
:(
I just tried and the "Sun Sep 23 13:00:00 2001 UTC"
segfaults all the way in t/op/number.t and t/op/trans.t,
( IV = long, NV = double )
( other tests are 100% OK ), so there are problems
with floats. Tomorrow at the university
I can debug the problem
( debugging over a dialup is a pain... )
Re
> Cool; thanks for this. Can you add a row to your smoke configuration
> which does *not* change the default type sizes?
Sure. WRT segfaults, I think I found the cause for the problems:
The files inf cvs.perl.org/snapshots seem out of date.
$ diff -u parrot/assemble.pl ../parrot.cvs/assemble.pl |
> > GNU does offer the gettext tools library for just such a purpose. I don't
> > know how it will translate to the various platforms however, and it likely
> > is a major overkill for what we are trying to do.
> > http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose
> > It migh
On Mon, 24 Sep 2001, Simon Cozens wrote:
>When tests fail for Really Bad reasons, they tend to do something like this:
>
>Got: '
>'
>Expected: '
>ok 1
>...
>'
>
>It'd be really nice if we could intercept that and give more detail on why
>the test failed. Did the assembler compile to a PBC ok? Did
--- Forwarded message follows ---
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Subject:Parrot Smoke Sep 25 19:00:04 2001 UTC MSWin32 4.0
Date sent: Tue, 25 Sep 2001 22:00:03 +0200
Automated smoke report for patch Sep 25
On Tru64, freshly compiled perl 5.005_03,
Configure.pl decides the correct type for opcode is 'l'
but that is 32 bit! After manually changinq it to 'q'
it mostly[1] works.
Problem is that al line 159 it does:
elsif ($c{ivsize} == 8) {
$c{packtype_i} = 'q';
$c{pac
On Wed, 26 Sep 2001, Gibbs Tanton - tgibbs wrote:
>Attached is a new assemble.pl. No, it doesn't change anything, it only
>breaks the code up into easier to follow functions (which are commented). I
After looking at the old assembler code: Thanks!
>am going to test it on a few more platforms a
On Wed, 26 Sep 2001, Buggs wrote:
>===
> Win32
>make ok / test ok
>(with caveats: nmake doesn't do 'test' correctly, and 'clean' doesn't
>work because of the 'rm' command)
use namke -a [1]; for the rm problem I posted a patch some time ago,
and Andy Dougherty posted anoter one abo
o zero instead of say 12,
and if I change the assembly from 0b1100 to 12, the test passes )
I din't try the new assembler.
Mattia
>-Original Message-
>From: Mattia Barbon
>To: Gibbs Tanton - tgibbs
>Cc: '[EMAIL PROTECTED] '
>Sent: 9/26/2001 2:44 AM
>Subject: Re:
On Wed, 26 Sep 2001, Simon Cozens wrote:
>On Wed, Sep 26, 2001 at 08:42:52AM -0500, Gibbs Tanton - tgibbs wrote:
>> I'm getting a core dump on Tru64 for stacks.t. Does anyone else get this?
>
>Just the one? I'm getting six of the damned things.
The 01:00 UTC snapshot segfaulted on all tests beca
Makes Win32 use ExtUtils::Command::rm_f as a rm -f replacemnt.
Regards
Mattia
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.19
diff -u -2 -r1.19 Configure.pl
--- Configure.pl20
Some cleanup, plus:
* detects assembler errors
* better output when tests are run manually
and tests fail
Suggestions for the new output format are welcome
C:\Developement\perl6\parrot>perl t/op/basic.t
1..5
not ok 1 - noop, end
# Failed test (t/op/basic.t at line 6)
### Got:
#="."
> with CygWin everything works ok...however I get a ton of warnings for
> packfile.c that look like they need to be addressed...I'll look at them
> soon. Also, when I type make test it tells me that test doesn't need to do
> anything; this was happening before these changes, but I was wondering i
-- Forwarded message --
Date: Tue, 2 Oct 2001 09:34:17 +0200
From: Barbon Mattia <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Parrot Smoke Oct 2 01:00:02 2001 UTC dec_osf 4.0
Automated smoke report for patch Oct 2 01:00:02 2001 UTC
v0.01 on dec_osf using
On Wed, 3 Oct 2001, Gibbs Tanton - tgibbs wrote:
>
>Here is the patch to get make test to work on cygwin. There may be a better
>way to do it. It is actually courtesy of someone else, but I'll have to go
>look to see who (unless you speak up :)
>
>It basically takes
>test:
> ...do tests
>and r
Automated smoke report for patch Oct 4 07:00:01 2001 UTC
v0.01 on dec_osf using gcc version 2.8.1
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: - = unknown
c = Configure, m = make, t =
I just uploaded a new version of Parrot::Smoke to CPAN.
Changes:
0.02 Fri Oct 05 06:57:20 2001
- support for sending mail through Net::SMTP
- autonfiguration through Makefile.PL should work
on Win32
- eliminated --define/--defaults from output
Regards
Mattia
> On Wed, Oct 17, 2001 at 12:45:49PM +0100, Simon Cozens wrote:
> > On Tue, Oct 16, 2001 at 03:43:57PM -0400, Gregor N. Purdy wrote:
> > > I just fixed the dependancy. Hopefully, this problem goes away now.
> >
> > Nope.
>
> Fixed it up, and also fixed some problems with the "clean" target.
> An
On Wed, 24 Oct 2001, Brent Dax wrote:
>Unfortunately, I can't figure out how to utilize it. Including
>windows.h causes a conflict with Parrot's definition of BOOL, including
>winbase.h gives me a ton of syntax errors, and putting the declaration
It is not supported to #include a win* file unles
io/io_win32.c:
according to my MSVC docs, you should use _tcslen only after
#including tchar.h
Index: io/io_win32.c
===
RCS file: /home/perlcvs/parrot/io/io_win32.c,v
retrieving revision 1.2
diff -u -2 -r1.2 io_win32.c
--- io/i
Makefile.in:
(Re)add ld_debug flags to LDFLAGS, so that Configure.pl --debugging
works with MSVC
classes/Makefile.in
make easier to add pmb2c.pl flags to all pmc2c calls
Index: Makefile.in
===
RCS file: /home/perlcvs/parro
key.c:
intialize KEY.keys
classes/perlarray.c:
* get_string: is casting SELF->cache.struct_val to a STRING*,
while all other methods are using it as a KEY*; don't know
what a perlarray stringifies to, so replacing with NULL
* get_bool: the default behaviour does not look right to me
af
I'm sorry if this is a known bug.
my.pasm ( useless, just a contrived example ):
set I1, 12
FOO:
if I1, FOO
BAR:
if I1, BAR
if I1, FOO
end
assembly:
0x816bda8: push %ebp
0x816bda9: mov%esp,%ebp
0x816bdab: int3
0x816bdac: movl $0x
This is for MinGW ( read below why not MSVC )
Changes:
* Configure.pl
correctly detect $cpuarch/$osname
* jit2h.pl
Accept a new osname parameter
search jit/cpuarch/$file-$osname.jit, and if found
add ops found there/override ops in $file.jit
* Makefile.in
add jitosname to the paramete
* hints/mswin32.pl
- move $c{platform} = win32 outside $is_msvc
* Configure.pl
- fixed jitarch/os detection for Win32
( was using cpu = MSWin32, os = x86 )
Regards
Mattia
Index: Configure.pl
===
RCS file: /home/perlcvs/pa
> "misc.c", line 541: Error:
> [ISO 6.1.4]: End of line in string literal.
>
> Here's a patch. That last one is particularly odd, as it is in a #if 0.
> I'm leaving it for now, as I think this is a case of the compiler being on
> crack.
Probably not: IIRC the standard requires the parts
The following patch adds a Parrot_nosegfault() function
to win32.c; after it is called, a segmentation fault will print
"This process received a segmentation violation exception"
instead of popping up a dialog. I think it might be useful
for tinderbox clients.
Regards
Mattia
Index: platforms/w
> > The following patch adds a Parrot_nosegfault() function
> > to win32.c; after it is called, a segmentation fault will print
> > "This process received a segmentation violation exception"
> > instead of popping up a dialog. I think it might be useful
> > for tinderbox clients.
>
> Please notic
> FYI: On interp init I already grab the standard handles (io_win32.c) so you
> could reuse the value for stderr. It might make sense to make the low level
> handle values extern so other modules can use them. Let me know and
> I'll put a patch in for it.
I don't know if it is a good idea to expos
> Michael G Schwern <[EMAIL PROTECTED]> writes:
> >On Fri, Feb 08, 2002 at 07:19:26PM +0100, Mattia Barbon wrote:
> >Content-Description: Mail message body
> >> The following patch adds a Parrot_nosegfault() function
> >> to win32.c; after it is called, a s
On Thu, 1 Aug 2002 16:50:25 +0200 Aldo Calpini <[EMAIL PROTECTED]> wrote:
> Mr. Nobody wrote:
> > The windows 9x command.com shell dosen't recognize
> > 2>&1 so it ends up passing "2" as an argument to the
> > compiler, which fails because there's no such file.
>
> this is no news. you can't eve
On Sat, 10 Aug 2002 16:56:20 -0700 (PDT) Sean O'Rourke <[EMAIL PROTECTED]> wrote:
> A few more tweaks:
>
> - inline and remove _to_keyed and _to_keyed_integer.
> - inline pack_op
> - reorder the big elsif to test for /^\[/ once at the top, then only
> match
> against keyed/non-keyed.
>
> At t
On Fri, 23 Aug 2002 16:56:54 +0200 Aldo Calpini <[EMAIL PROTECTED]> wrote:
> I stumbled upon this because I'm trying to implement an
> Iterator PMC (almost done), and the most obvious way I've
> found to bind the iterator to what it should iterate is this
> one:
>
> new P0, .PerlHash
>
On Tue, 5 Aug 2003 17:59:36 +0200 Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 11:10 +0200 7/31/03, Leopold Toetsch wrote:
> >> > *) Determine the init and setup routine names
> >>
> >>- Parrot__class_setup
> >>- Parrot__class_init
> >>
> >>The class
Puts #ifdefs as per the rest of i386/jit_emit.h.
Regards
Mattia
Index: jit/i386/jit_emit.h
===
RCS file: /cvs/public/parrot/jit/i386/jit_emit.h,v
retrieving revision 1.79
diff -u -2 -r1.79 jit_emit.h
--- jit/i386/jit_emit.h
Hello,
the correct fix is probably having different code paths for Win32 (because
on Windows NT/2000/XP/.Net and funnier names of the future environment
is/will be Unicode, not char*). For now this makes env.t pass on Win32.
Regards
Mattia
parrot.cvs.diff
Description: Binary data
Il Tue, 28 Oct 2003 18:51:56 +0100 Leopold Toetsch <[EMAIL PROTECTED]> ha scritto:
> Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> > Hi,
>
> > loadlib P1, "user32.dll"
>
> There are 2 errors in that, one is mine :)
> - I didn't use the configure define of PARROT_DLL_EXTENSION
> - Your's is:
Hello,
I have some questions about which part of the actual headers are
internal, which ones are for embedders and which ones are for
extenders.
AFAIR nothing but Parrot sources should #include parrot/parrot.h.
The public interface is available through parrot/embed.h and
parrot/extend.h. Corre
Il Tue, 6 Jan 2004 16:43:42 +0100 Leopold Toetsch <[EMAIL PROTECTED]> ha scritto:
> Mattia Barbon <[EMAIL PROTECTED]> wrote:
> > Hello,
> > this patch
>
> > * renames Parrot_INTERP and Parrot_STRING to Parrot_Interp and
> Parrot_String,
> > which
Hello,
I feel I'm becoming annoying, but: the embedding and extending
interfaces are still using different names for Parrot_Interp/Parrot_INTERP.
Which one is correct?
Thanks!
Mattia
Il Sat, 24 Jan 2004 19:42:20 -0500 Gordon Henriksen <[EMAIL PROTECTED]> ha scritto:
> On Saturday, January 24, 2004, at 11:28 , Mattia Barbon wrote:
>
> > I feel I'm becoming annoying, but: the embedding and extending
> > interfaces are still using different
[got a failure, sorry if this is a duplicate]
On 15 Aug 2004 10:11:11 - Leopold Toetsch via RT <[EMAIL PROTECTED]> wrote:
> Mattia Barbon <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> > I am not sure about this patch. It splits part of Parrot_load_lib
>
Hello,
crrently argument count is passed in I3. A comment in untils.c
near foldup says that:
TODO - IMCC and PDD 3 aren't yet in conformance. This uses the current
IMCC setup, but should be changed as soon as IMCC modified to the
correct calling conventions.
while pdd03 says:
.
Hello,
I think extenders should have access to at least some of the
flags in PObj_enum. Should we have a different function for
each flag (say: Parrot_PObj_set_custom_mark(INTERP, PMC, value),
Parrot_PObj_set_is_class(INTERP, PMC, value) or a single
Parrot_PObj_set_flag(INTERP, PMC, flag, value)
On Sat, 21 Aug 2004 19:36:43 -0400 Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:44 PM +0200 8/21/04, Mattia Barbon wrote:
> > Hello,
> >I think extenders should have access to at least some of the
> >flags in PObj_enum. Should we have a different fun
On Sun, 22 Aug 2004 11:00:10 +0200 Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Mattia Barbon <[EMAIL PROTECTED]> wrote:
> > Hello,
> > as promised with this patch:
>
> > pmc2c2 ... --library foo --c pmc1.pmc pmc2.pmc pmc3.pmc ...
>
> Thanks, appl
Hello,
should they be? I think they are covered by the statemente in
pdd11 (... about the same level of access to Parrot
that bytecode programs ...).
Regards
Mattia
On Sun, 29 Aug 2004 11:09:46 +0200 Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Mattia Barbon <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> > this patch implements Parrot_call_method (with test).
>
> This code seems to duplicate functions from F and
> ret
On Sat, 22 Oct 2005 09:33:50 +0200 Christian Renz <[EMAIL PROTECTED]> wrote:
Hello,
> How do I find the right symbol name for a function? For example, the
> void wxBell(void) function can be found in the library as __Z6wxBellv
> (found using otool -vT /usr/lib/libwx.dylib), but I guess on Wind
Hi!
> I like the idea of leveraging the wxPerl XS files. Any comments on why
> you introduced xsubppp (on top of xsubpp) for some XS files?
XS++ is much less verbose than plain XS when writing
C++ code [1], and it allows me to handle some C++ features
(like passing/returning references) without
84 matches
Mail list logo
