Re: B::Bytecode and Windows
Reini Urban
> Hello, you plan to support B::Bytecode for windows platform?
Yes, I do plan and test on windows.
But certain older perl versions will not work at all.
My simple patches were refused so far.
strawberry 5.12:
perl -Mblib t\bytecode.t
...
Label not found for "next NUMBER" at bytecode21.pl line 1.
not ok 21 #TODO wanted: 024, $? = 65280, got: 0
ok 22
ok 23
ok 24
ok 25
ok 26
ok 27#TODO
ok 28
ok 29
ok 30
ok 31
[perl #80622] Upgrading entertry from BASEOP to LOGOP...
[perl #80622] Upgrading entertry from BASEOP to LOGOP...
Assertion failed: ((char*)PL_scopestack_name[PL_scopestack_ix-1] ==
(char*)"eval_scope") || strEQ(PL_scopestack_name[PL_
scopestack_ix-1], "eval_scope"), file ..\pp_ctl.c, line 4000
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
not ok 32 #TODO wanted: 12, $? = 768, got:
ok 33
ok 34
ok 35
ok 36
ok 37
ok 38
ok 39
ok 40
Unbalanced string table refcount: (2) for "bytecode41.plc" during
global destruction.
ok 41
Assertion failed: he->shared_he_he.hent_hek == hek, file ..\hv.c, line 2378
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
not ok 42 #TODO wanted: ok, $? = 768, got:
Assertion failed: he->shared_he_he.hent_hek == hek, file ..\hv.c, line 2378
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Konovalov, Vadim (Vadim)** CTR **
>
> Yes, I do plan and test on windows.
> But certain older perl versions will not work at all.
> My simple patches were refused so far.
I guess it is time to _politely_ suggest applying "store_cop_label" patch
again.
>
> strawberry 5.12:
> perl -Mblib t\bytecode.t
>
> ...
> Label not found for "next NUMBER" at bytecode21.pl line 1.
> not ok 21 #TODO wanted: 024, $? = 65280, got: 0
yes, this is due to this "store_cop_label".
And I want to suggest two things here:
1. simplify version forest a lot.
Let us state that we support 5.14.+ and remove "ifdefs" for older perl.
(at least for win32, where it is broken)
2. simplifying Byteloader is even more imortant task.
Now it is 20+lines of perl, and this is not good, IMO
The point is - if you byte-compile small pm file, but then byteload logic
is large - the effort is wasted.
but let us to become robust first :)
Reini, in your PC, can you byte-compile Math::BigInt.pm and then run it w/o
crash?
Regards,
Vadim.
Reini Urban
<vadim.k...@alcatel-lucent.com>:
>> From: perl-c...@googlegroups.com On Behalf Of Reini Urban
>>
>> Yes, I do plan and test on windows.
>> But certain older perl versions will not work at all.
>> My simple patches were refused so far.
>
> I guess it is time to _politely_ suggest applying "store_cop_label" patch
> again.
>
>>
>> strawberry 5.12:
>> perl -Mblib t\bytecode.t
>>
>> ...
>> Label not found for "next NUMBER" at bytecode21.pl line 1.
>> not ok 21 #TODO wanted: 024, $? = 65280, got: 0
>
> yes, this is due to this "store_cop_label".
>
> And I want to suggest two things here:
>
> 1. simplify version forest a lot.
> Let us state that we support 5.14.+ and remove "ifdefs" for older perl.
> (at least for win32, where it is broken)
For sure not. I'll rather try to backport the Bytecode compiler fixes
to 5.6 also. 5.6 is still worthwile to support.
> 2. simplifying Byteloader is even more imortant task.
> Now it is 20+lines of perl, and this is not good, IMO
> The point is - if you byte-compile small pm file, but then byteload logic
> is large - the effort is wasted.
This is impossible. But I'll try to mmap the script.
> but let us to become robust first :)
>
> Reini, in your PC, can you byte-compile Math::BigInt.pm and then run it w/o
> crash?
Yes,
$ pb -MO=Bytecode,-H,-obig.plc -e'use Math::BigInt; print
Math::BigInt->new(1e40) + 40'
-e syntax OK
$ pb big.plc
10000000000000000000000000000000000000040
Konovalov, Vadim (Vadim)** CTR **
I will comment on this, after I will collect my feeling on the current B::C maintainer...
>
> > 2. simplifying Byteloader is even more imortant task.
> > Now it is 20+lines of perl, and this is not good, IMO
> > The point is - if you byte-compile small pm file, but then
> byteload logic
> > is large - the effort is wasted.
>
> This is impossible. But I'll try to mmap the script.
any explanations on why this is impossible?
I seemingly gave reasoning on my POV, and your "impossible" does not sound very convincing, I afraid :)
>
> > but let us to become robust first :)
> >
> > Reini, in your PC, can you byte-compile Math::BigInt.pm and
> then run it w/o
> > crash?
>
> Yes,
>
> $ pb -MO=Bytecode,-H,-obig.plc -e'use Math::BigInt; print
> Math::BigInt->new(1e40) + 40'
> -e syntax OK
>
> $ pb big.plc
> 10000000000000000000000000000000000000040
Fine.
I am almost happy.
can you transfer to me the file BigInt.pmc after executing
perl -MO=Bytecode,-H,-oBigInt.pmc BigInt.pm
?
TIA,
Vadim.
Konovalov, Vadim (Vadim)** CTR **
> > [mailto:perl-c...@googlegroups.com] On Behalf Of Reini Urban
> > Sent: Tuesday, May 24, 2011 9:29 PM
> > To: perl-c...@googlegroups.com
> > Cc: ZloySystem
> > Subject: Re: [perl-compiler] Re: B::Bytecode and Windows
> >
> > <vadim.k...@alcatel-lucent.com>:
> > >> From: perl-c...@googlegroups.com On Behalf Of Reini Urban
> > >>
> > >> Yes, I do plan and test on windows.
> > >> But certain older perl versions will not work at all.
> > >> My simple patches were refused so far.
> > >
> > > I guess it is time to _politely_ suggest applying
> > "store_cop_label" patch
> > > again.
> > >
> > >>
> > >> strawberry 5.12:
> > >> perl -Mblib t\bytecode.t
> > >>
> > >> ...
> > >> Label not found for "next NUMBER" at bytecode21.pl line 1.
> > >> not ok 21 #TODO wanted: 024, $? = 65280, got: 0
> > >
> > > yes, this is due to this "store_cop_label".
> > >
> > > And I want to suggest two things here:
> > >
> > > 1. simplify version forest a lot.
> > > Let us state that we support 5.14.+ and remove "ifdefs" for
> > older perl.
> > > (at least for win32, where it is broken)
> >
> > For sure not. I'll rather try to backport the Bytecode
> compiler fixes
> > to 5.6 also. 5.6 is still worthwile to support.
will you share your time plan on this please?
>
> I will comment on this, after I will collect my feeling on
> the current B::C maintainer...
>
>
> >
> > > 2. simplifying Byteloader is even more imortant task.
> > > Now it is 20+lines of perl, and this is not good, IMO
> > > The point is - if you byte-compile small pm file, but then
> > byteload logic
> > > is large - the effort is wasted.
> >
> > This is impossible. But I'll try to mmap the script.
>
> any explanations on why this is impossible?
obviously this is indeed possible, due to lack of explanations on the matter.
Now, can we discuss on reducing this #ifdef forest then, please?
I think having these lines in "bytecode.h" are stupid:
# if (PERL_VERSION < 13) || ((PERL_VERSION == 13) && (PERL_SUBVERSION < 5))
# if defined(_WIN32) || (defined(__CYGWIN__) && (__GNUC__ > 3)) || defined(AIX)
# define BSET_cop_label(cop, arg) /* XXX not exported */
# else
# define BSET_cop_label(cop, arg) (cop)->cop_hints_hash = \
Perl_store_cop_label(aTHX_ (cop)->cop_hints_hash, arg)
# endif
# else
...
I vote for removal of these.
Opinions anyone?
> I seemingly gave reasoning on my POV, and your "impossible"
> does not sound very convincing, I afraid :)
I want to emphasize this line once more, if possible,
I think it deserves either agreement on this, or otherwise declaring
it stupid, which is also possible after some agreement on this.
Next,
I would be grateful for anyone sending me working BigInt.pmc
that was mentioned several times already.
Vadim.
Konovalov, Vadim (Vadim)** CTR **
please share with me.
Either linux or win32 OS would be good.
created by command
perl -MO=Bytecode,-H,-oBigInt.pmc BigInt.pm
Vadim.
Konovalov, Vadim (Vadim)** CTR **
can you unsubscribe me please?
> --
> Unsubscribe via mail to perl-compile...@googlegroups.com
> Options: http://groups.google.com/group/perl-compiler?hl=en
>