search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.96k stars 555 forks source link

turning interp struct bools into bitfields? #12572

Closed p5pRT closed 9 years ago

p5pRT commented 11 years ago

Migrated from rt.perl.org#115766 (status was 'rejected')

Searchable as RT115766$

p5pRT commented 11 years ago

From @bulk88

Created by @bulk88

Looking in interpvar.h\, there is some waste of using bools which are chars on Win32 C and C++ mode (but VC's C++ bool isn't used by Perl) instead of individual flags with a bitfield\, starting with minus_c there are 8 sequential bools in a row\, this can be collapses to 1 char (but be careful of padding to 4 or 8 bytes). I counted 28 bools in interpvar.h. The reason I filed this is because I noticed PL_srand_called is set only once a process (copied in psuedofork) or once an ithread (thread.xs) and 7 bits are unused. I suggest using chars as bitfields rather than U32s for more compact instructions/compact flag constants. I'm filing this bug so the idea isn't lost forever. I don't plan to do anything about it.

Perl Info ``` Flags: category=core severity=wishlist Site configuration information for perl 5.17.6: Configured by Owner at Thu Nov 15 18:16:26 2012. Summary of my perl5 (revision 5 version 17 subversion 6 patch blead 2012-11-15.22:53:41 00ec60ba0b8283af9a17ca1eddf992ca371f0411 v5.17.5-497-g00ec60b) configuration: Snapshot of: 00ec60ba0b8283af9a17ca1eddf992ca371f0411 Platform: osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -GL -G7 -arch:SSE2 -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D_USE_32BIT_TIME_T', optimize='-MD -Zi -DNDEBUG -O1 -GL -G7 -arch:SSE2', cppflags='-DWIN32' ccversion='13.10.6030', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -ltcg -libpath:"c:\perl517\lib\CORE" -machine:x86' libpth="C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\lib" libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl517.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -ltcg -libpath:"c:\perl517\lib\CORE" -machine:x86' Locally applied patches: @INC for perl 5.17.6: C:/perl517/site/lib C:/perl517/lib . Environment for perl 5.17.6: HOME (unset) LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=C:\perl517\bin;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\bin\prerelease;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem; PERL_BADLANG (unset) SHELL (unset) ```
p5pRT commented 11 years ago

From @cpansprout

On Fri Nov 16 19​:06​:10 2012\, bulk88 wrote​:

This is a bug report for perl from bulk88@​hotmail.com\, generated with the help of perlbug 1.39 running under perl 5.17.6.

----------------------------------------------------------------- [Please describe your issue here]

Looking in interpvar.h\, there is some waste of using bools which are chars on Win32 C and C++ mode (but VC's C++ bool isn't used by Perl) instead of individual flags with a bitfield\, starting with minus_c there are 8 sequential bools in a row\, this can be collapses to 1 char (but be careful of padding to 4 or 8 bytes). I counted 28 bools in interpvar.h. The reason I filed this is because I noticed PL_srand_called is set only once a process (copied in psuedofork) or once an ithread (thread.xs) and 7 bits are unused. I suggest using chars as bitfields rather than U32s for more compact instructions/compact flag constants. I'm filing this bug so the idea isn't lost forever. I don't plan to do anything about it.

I did something similar when adding new booleans to the parser struct\, but then Nicholas Clark changed it to multiple fields to reduce the amount of machine code needed to read them.

I’m not an expert in this area (or in anything requiring more than a cursory knowledge of C)\, so I cannot say whether this is a good idea or not.

--

Father Chrysostomos

p5pRT commented 11 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 11 years ago

From @khwilliamson

On 11/17/2012 12​:04 PM\, Father Chrysostomos via RT wrote​:

On Fri Nov 16 19​:06​:10 2012\, bulk88 wrote​:

This is a bug report for perl from bulk88@​hotmail.com\, generated with the help of perlbug 1.39 running under perl 5.17.6.

----------------------------------------------------------------- [Please describe your issue here]

Looking in interpvar.h\, there is some waste of using bools which are chars on Win32 C and C++ mode (but VC's C++ bool isn't used by Perl) instead of individual flags with a bitfield\, starting with minus_c there are 8 sequential bools in a row\, this can be collapses to 1 char (but be careful of padding to 4 or 8 bytes). I counted 28 bools in interpvar.h. The reason I filed this is because I noticed PL_srand_called is set only once a process (copied in psuedofork) or once an ithread (thread.xs) and 7 bits are unused. I suggest using chars as bitfields rather than U32s for more compact instructions/compact flag constants. I'm filing this bug so the idea isn't lost forever. I don't plan to do anything about it.

I did something similar when adding new booleans to the parser struct\, but then Nicholas Clark changed it to multiple fields to reduce the amount of machine code needed to read them.

I’m not an expert in this area (or in anything requiring more than a cursory knowledge of C)\, so I cannot say whether this is a good idea or not.

I tried something similar once\, but noticed that in fact it increased the total size instead of reducing it. And the extra code needed to process these is slower.

What I don't know is if declaring things U8 helps or hinders things. I imagine that using 'int' is the best for the platform\, but does an 8 bit declaration in general cause extra code to be generated.

p5pRT commented 11 years ago

From @jandubois

On Sun\, Nov 18\, 2012 at 11​:25 AM\, Karl Williamson \public@​khwilliamson\.com wrote​:

What I don't know is if declaring things U8 helps or hinders things. I imagine that using 'int' is the best for the platform\, but does an 8 bit declaration in general cause extra code to be generated.

There is no general answer to this; it depends on the CPU architecture. And even then\, code may be slower to process a U8 value than an int\, but if switching to the U8 keeps some other data in the cache\, then it may still be a net win.

In general you should also be mindful of memory alignment within structs. If you can't pack multiple U8 values together\, then the "saved" space may just be turned back into padding to maintain proper alignment for the stuct itself\, and all its other fields.

Cheers\, -Jan

p5pRT commented 10 years ago

From @jkeenan

On Mon Nov 19 11​:04​:44 2012\, jdb wrote​:

On Sun\, Nov 18\, 2012 at 11​:25 AM\, Karl Williamson \public@​khwilliamson\.com wrote​:

What I don't know is if declaring things U8 helps or hinders things. I imagine that using 'int' is the best for the platform\, but does an 8 bit declaration in general cause extra code to be generated.

There is no general answer to this; it depends on the CPU architecture. And even then\, code may be slower to process a U8 value than an int\, but if switching to the U8 keeps some other data in the cache\, then it may still be a net win.

In general you should also be mindful of memory alignment within structs. If you can't pack multiple U8 values together\, then the "saved" space may just be turned back into padding to maintain proper alignment for the stuct itself\, and all its other fields.

Cheers\, -Jan

There has been no correspondence in this RT in more than a year. Re-reading it\, my sense is that the consensus is that no change in Perl is warranted. Is that the case? If so\, we should close this ticket.

Thank you very much. Jim Keenan

p5pRT commented 10 years ago

From @bulk88

On Fri Dec 13 16​:25​:40 2013\, jkeenan wrote​:

There has been no correspondence in this RT in more than a year. Re- reading it\, my sense is that the consensus is that no change in Perl is warranted. Is that the case? If so\, we should close this ticket.

Thank you very much. Jim Keenan

Lets wait a couple days for more opinions (your bump might being some)\, if no responses then close. I don't plant to add any patches/code under this ticket.

-- bulk88 ~ bulk88 at hotmail.com

p5pRT commented 9 years ago

From @jkeenan

On Fri Dec 13 17​:13​:58 2013\, bulk88 wrote​:

On Fri Dec 13 16​:25​:40 2013\, jkeenan wrote​:

There has been no correspondence in this RT in more than a year. Re- reading it\, my sense is that the consensus is that no change in Perl is warranted. Is that the case? If so\, we should close this ticket.

Thank you very much. Jim Keenan

Lets wait a couple days for more opinions (your bump might being some)\, if no responses then close. I don't plant to add any patches/code under this ticket.

Well\, we waited 21 months and there were no further comments. Closing ticket.

Thank you very much.

-- James E Keenan (jkeenan@​cpan.org)

p5pRT commented 9 years ago

@jkeenan - Status changed from 'open' to 'rejected'

p5pRT commented 9 years ago

From @rurban

On Mon Oct 05 19​:05​:57 2015\, jkeenan wrote​:

On Fri Dec 13 17​:13​:58 2013\, bulk88 wrote​:

On Fri Dec 13 16​:25​:40 2013\, jkeenan wrote​:

There has been no correspondence in this RT in more than a year. Re- reading it\, my sense is that the consensus is that no change in Perl is warranted. Is that the case? If so\, we should close this ticket.

Opinions?

Nicholas was wrong as most of the time with his similar changes for the worse. The whole runtime was de-optimized in this way. Even Larry joked about this in his last talk\, but nobody listened.

I did something similar when adding new booleans to the parser struct\, but then Nicholas Clark changed it to multiple fields to reduce the amount of machine code needed to read them.

I’m not an expert in this area (or in anything requiring more than a cursory knowledge of C)\, so I cannot say whether this is a good idea or not.

Sure it's good.

On modern intel CPU's less or compressed data is far more important than less instructions. Compressing globals state into bitfields is much better than having direct word-aligned access to it. You need look at cachegrind for cache misses\, which are 200x more expensive than simple mask instructions. perf stat on linux helps also.

-- Reini Urban

p5pRT commented 9 years ago

From @iabyn

On Thu\, Oct 08\, 2015 at 02​:58​:00AM -0700\, Reini Urban via RT wrote​:

On Mon Oct 05 19​:05​:57 2015\, jkeenan wrote​:

On Fri Dec 13 17​:13​:58 2013\, bulk88 wrote​:

On Fri Dec 13 16​:25​:40 2013\, jkeenan wrote​:

There has been no correspondence in this RT in more than a year. Re- reading it\, my sense is that the consensus is that no change in Perl is warranted. Is that the case? If so\, we should close this ticket.

Opinions?

Nicholas was wrong as most of the time with his similar changes for the worse.

Here's a suggestion. When engaging in a technical discussion\, don't immediately resort to a personal attack on someone. You'll find that it's a lot easier to get on with people that way. You'd be amazed.

Anyway\, in the specific context of this ticket\, the change Nicholas made which FC referred to was this​:

  commit 286a76ab020bbce3bb02a3c2490a7a01ad781c47   Author​: Nicholas Clark \nick@​ccl4\.org   CommitDate​: Mon Feb 27 11​:31​:48 2012 +0100

  In struct yy_parser\, change lex_flags to a U8\, from part of a bitfield.  
  lex_flags holds 4 flag bits\, with multiple flag bits manipulated together   at times\, so they can't be split out into individual bitfields. This change   permits the C compiler to generate simpler code\, reducing toke.o by about   400 bytes on this platform\, but doesn't change the size of the structure.  
  lex_flags was added in commit 802a15e9c01d1a0b in August 2011\, so is not in   any stable release.

Note that Nicholas didn't increase the size of the data structure.

I’m not an expert in this area (or in anything requiring more than a cursory knowledge of C)\, so I cannot say whether this is a good idea or not.

Sure it's good.

Sure it all depends.

On modern intel CPU's less or compressed data is far more important than less instructions. Compressing globals state into bitfields is much better than having direct word-aligned access to it. You need look at cachegrind for cache misses\, which are 200x more expensive than simple mask instructions. perf stat on linux helps also.

But larger code size can result in instruction cache misses too. I suspect in this case merging some booleans may improve things. But It All Depends.

-- "Foul and greedy Dwarf - you have eaten the last candle."   -- "Hordes of the Things"\, BBC Radio.

p5pRT commented 9 years ago

From @rurban

On Oct 8\, 2015\, at 6​:31 PM\, Dave Mitchell \davem@​iabyn\.com wrote​:

On Thu\, Oct 08\, 2015 at 02​:58​:00AM -0700\, Reini Urban via RT wrote​:

On Mon Oct 05 19​:05​:57 2015\, jkeenan wrote​:

On Fri Dec 13 17​:13​:58 2013\, bulk88 wrote​:

On Fri Dec 13 16​:25​:40 2013\, jkeenan wrote​:

There has been no correspondence in this RT in more than a year. Re- reading it\, my sense is that the consensus is that no change in Perl is warranted. Is that the case? If so\, we should close this ticket.

Opinions?

Nicholas was wrong as most of the time with his similar changes for the worse.

Here's a suggestion. When engaging in a technical discussion\, don't immediately resort to a personal attack on someone. You'll find that it's a lot easier to get on with people that way. You'd be amazed.

I beg to differ.

Some of us are trying to getting perl5 in a better shape. If the problem are certain people and not certain mistakes\, it proved to be more effective to name the root cause\, and not the individual mistakes.

And it worked good so far. You should be amazed.

p5pRT commented 9 years ago

From @rjbs

* Reini Urban \reini@​cpanel\.net [2015-10-11T03​:04​:59]

On Oct 8\, 2015\, at 6​:31 PM\, Dave Mitchell \davem@​iabyn\.com wrote​: Here's a suggestion. When engaging in a technical discussion\, don't immediately resort to a personal attack on someone. You'll find that it's a lot easier to get on with people that way. You'd be amazed.

I beg to differ.

Some of us are trying to getting perl5 in a better shape. If the problem are certain people and not certain mistakes\, it proved to be more effective to name the root cause\, and not the individual mistakes.

And it worked good so far. You should be amazed.

Look\, in your post about Nicholas's "similar changes for the worse\," you fail to indicate what the heck you're talking about. What change? Do you mean 286a76ab02? Worse in what way? Do you mean tha the increased the data space used? Your comment makes it seem that way. Dave points out that this isn't the case. Do you mean something else?

Your comment is clear as mud\, other than the "I don't like Nicholas's work\, and will not explain what or how."

Get to the point. If you want to point out that people are the problem\, it's either because (a) those people are making the same demonstrable mistakes over and over without improvement or (b) those people are making the workplace unbearable.

You are not demonstrating that Nicholas is making the same mistake over and over again\, because you're just sort of saying "Nicholas is a problem." Maybe you think you've explained it a hundred times before\, but I don't think you have.

Either make a real technical point that isn't clearly wrong\, sincerely apologize for your remarks\, or go take your work to your own mailing list.

Seriously.

-- rjbs

p5pRT commented 9 years ago

From @doughera88

On Sun\, Oct 11\, 2015 at 09​:04​:59AM +0200\, Reini Urban wrote​:

On Oct 8\, 2015\, at 6​:31 PM\, Dave Mitchell \davem@​iabyn\.com wrote​:

On Thu\, Oct 08\, 2015 at 02​:58​:00AM -0700\, Reini Urban via RT wrote​:

On Mon Oct 05 19​:05​:57 2015\, jkeenan wrote​:

On Fri Dec 13 17​:13​:58 2013\, bulk88 wrote​:

On Fri Dec 13 16​:25​:40 2013\, jkeenan wrote​:

There has been no correspondence in this RT in more than a year. Re- reading it\, my sense is that the consensus is that no change in Perl is warranted. Is that the case? If so\, we should close this ticket.

Opinions?

Nicholas was wrong as most of the time with his similar changes for the worse.

Here's a suggestion. When engaging in a technical discussion\, don't immediately resort to a personal attack on someone. You'll find that it's a lot easier to get on with people that way. You'd be amazed.

I beg to differ.

Some of us are trying to getting perl5 in a better shape. If the problem are certain people and not certain mistakes\, it proved to be more effective to name the root cause\, and not the individual mistakes.

And it worked good so far. You should be amazed.

I'm sorry you disagree\, but we expect participants on this list to be civil and avoid demeaning remarks. Personal attacks are not welcome.

--   Andy Dougherty doughera@​lafayette.edu

p5pRT commented 9 years ago

From @rjbs

* Ricardo Signes \perl\.p5p@​rjbs\.manxome\.org [2015-10-11T12​:11​:24]

Either make a real technical point that isn't clearly wrong\, sincerely apologize for your remarks\, or go take your work to your own mailing list.

Well?

-- rjbs

p5pRT commented 9 years ago

From @nwc10

On Thu Oct 08 09​:31​:54 2015\, davem wrote​:

On Thu\, Oct 08\, 2015 at 02​:58​:00AM -0700\, Reini Urban via RT wrote​:

Opinions?

Nicholas was wrong as most of the time with his similar changes for the worse.

Here's a suggestion. When engaging in a technical discussion\, don't immediately resort to a personal attack on someone. You'll find that it's a lot easier to get on with people that way. You'd be amazed.

Anyway\, in the specific context of this ticket\, the change Nicholas made which FC referred to was this​:

commit 286a76ab020bbce3bb02a3c2490a7a01ad781c47

Note that Nicholas didn't increase the size of the data structure.

I see that I'm wrong again. For the usual value of wrong :-)

To add something that has occurred to me recently about this\, which I'm not aware has been considered/mentioned

You can't take the address of a bitfield.

Perl 5's exception mechanism relies on being able to restore "global" values in the interpreter struct. The implementation relies on saving the address of the value\, and the value to restore (now in one 32 bit value\, to reduce memory usage. At the cost of a bit more CPU. Another "wrongness" I added). Hence the restore code looks like this​:

  case SAVEt_BOOL​: /* bool reference */   *(bool*)ARG0_PTR = cBOOL(uv >> 8);

You can't do that if values in the interpreter struct are stored as bitfields.

IIRC you can't even make platform-agnostic assumptions about endian ordering of bitfields.

So storing booleans as (actual) bitfields would need more complex and much more fragile code to implement the save/restore mechanism.

Nicholas Clark

p5pRT commented 9 years ago

From @bulk88

On Wed Oct 14 04​:48​:18 2015\, nicholas wrote​:

To add something that has occurred to me recently about this\, which I'm not aware has been considered/mentioned

You can't take the address of a bitfield.

Use a C mask and & or |. Whether my proposal\, was to use C lang bitfields\, or conceptual bitfields (is SvFLAGS not a bitfield) doesn't matter. The fact is the currently implementation has 32 bools take up 32 BYTES while 32 bits take up 4 BYTES\, and some CCs/OSes say C "bool" is 4 BYTES long\, not 1 BYTE.

Perl 5's exception mechanism relies on being able to restore "global" values in the interpreter struct. The implementation relies on saving the address of the value\, and the value to restore (now in one 32 bit value\, to reduce memory usage. At the cost of a bit more CPU. Another "wrongness" I added). Hence the restore code looks like this​:

case SAVEt_BOOL​: /* bool reference */ *(bool*)ARG0_PTR = cBOOL(uv >> 8);

You can't do that if values in the interpreter struct are stored as bitfields.

void Perl_save_bool(pTHX_ bool *boolp) {   dSS_ADD;

  PERL_ARGS_ASSERT_SAVE_BOOL;

  SS_ADD_PTR(boolp);   SS_ADD_UV(SAVEt_BOOL | (*boolp \<\< 8));   SS_ADD_END(2); }

A SS type slot has atleast 26 unused high bits\, every SS slot UV sized (I have plans to change the SS slot to be ptr sized\, not UV sized in the future for mem savings on 64 IVs on 32 cpu).

#define SAVE_TIGHT_SHIFT 6 #define SAVE_MASK 0x3F

Since a bitfield must be fixed size (no UV allowed\, only U32 or U16 or U8)\, the largest bitfield would be 32 bits. That requires 5 bits (32 positions) to store "where" to apply the bit\, plus 1 bit for value\, a total of 6 bits needed from 26 spares.

IIRC you can't even make platform-agnostic assumptions about endian ordering of bitfields.

Perl already has "unportable" endian aware code\, grep for "endian" or "byteorder" in / source dir. As I said above\, whether to use C bitfields or bitfields doesn't matter too much\, it is the concept of turning 1 char into 1 bit that I am proposing. One more #if BYTEORDER == wont hurt if C bitfields are used.

So storing booleans as (actual) bitfields would need more complex and much more fragile code to implement the save/restore mechanism.

Nicholas Clark

-- bulk88 ~ bulk88 at hotmail.com

p5pRT commented 9 years ago

From @bulk88

On Wed Oct 14 04​:48​:18 2015\, nicholas wrote​:

To add something that has occurred to me recently about this\, which I'm not aware has been considered/mentioned

You can't take the address of a bitfield.

Use a C mask and & or |. Whether my proposal\, was to use C lang bitfields\, or conceptual bitfields (is SvFLAGS not a bitfield) doesn't matter. The fact is the currently implementation has 32 bools take up 32 BYTES while 32 bits take up 4 BYTES\, and some CCs/OSes say C "bool" is 4 BYTES long\, not 1 BYTE.

Perl 5's exception mechanism relies on being able to restore "global" values in the interpreter struct. The implementation relies on saving the address of the value\, and the value to restore (now in one 32 bit value\, to reduce memory usage. At the cost of a bit more CPU. Another "wrongness" I added). Hence the restore code looks like this​:

case SAVEt_BOOL​: /* bool reference */ *(bool*)ARG0_PTR = cBOOL(uv >> 8);

You can't do that if values in the interpreter struct are stored as bitfields.

void Perl_save_bool(pTHX_ bool *boolp) {   dSS_ADD;

  PERL_ARGS_ASSERT_SAVE_BOOL;

  SS_ADD_PTR(boolp);   SS_ADD_UV(SAVEt_BOOL | (*boolp \<\< 8));   SS_ADD_END(2); }

A SS type slot has atleast 26 unused high bits\, every SS slot UV sized (I have plans to change the SS slot to be ptr sized\, not UV sized in the future for mem savings on 64 IVs on 32 cpu).

#define SAVE_TIGHT_SHIFT 6 #define SAVE_MASK 0x3F

Since a bitfield must be fixed size (no UV allowed\, only U32 or U16 or U8)\, the largest bitfield would be 32 bits. That requires 5 bits (32 positions) to store "where" to apply the bit\, plus 1 bit for value\, a total of 6 bits needed from 26 spares.

IIRC you can't even make platform-agnostic assumptions about endian ordering of bitfields.

Perl already has "unportable" endian aware code\, grep for "endian" or "byteorder" in / source dir. As I said above\, whether to use C bitfields or bitfields doesn't matter too much\, it is the concept of turning 1 char into 1 bit that I am proposing. One more #if BYTEORDER == wont hurt if C bitfields are used.

So storing booleans as (actual) bitfields would need more complex and much more fragile code to implement the save/restore mechanism.

Nicholas Clark

-- bulk88 ~ bulk88 at hotmail.com

p5pRT commented 9 years ago

From @rjbs

* Reini Urban \reini@&#8203;cpanel\.net [2015-10-11T03​:04​:59]

On Oct 8\, 2015\, at 6​:31 PM\, Dave Mitchell \davem@&#8203;iabyn\.com wrote​:

Here's a suggestion. When engaging in a technical discussion\, don't immediately resort to a personal attack on someone. You'll find that it's a lot easier to get on with people that way. You'd be amazed.

I beg to differ.

Some of us are trying to getting perl5 in a better shape. If the problem are certain people and not certain mistakes\, it proved to be more effective to name the root cause\, and not the individual mistakes.

And it worked good so far. You should be amazed.

* Ricardo Signes \perl\.p5p@&#8203;rjbs\.manxome\.org [2015-10-14T07​:33​:51]

* Ricardo Signes \perl\.p5p@&#8203;rjbs\.manxome\.org [2015-10-11T12​:11​:24]

Either make a real technical point that isn't clearly wrong\, sincerely apologize for your remarks\, or go take your work to your own mailing list.

Well?

I'm taking your quotes\, and your refusal to apologize to constitute a general declaration of contempt of civility.  That interpretation is backed up by your other statements about p5p's policies.

Some day\, I will move on and let somebody else deal with this argument. I hope that when that happens\, you're able to engage more constructively with the community as it exists then.

Until then\, I'm removing you from the list. Do not post to it again.

-- rjbs