| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Comments:
<0> avar: nope
<1> eval: join$",map"$_.",unpack"a*",kissing # longer
<2> Juerd: kissing.
<1> Hm
<1> And doesn't work :)
<1> eval: join$",map"$_.",unpack"C*",kissing # longer
<2> Juerd: 107. 105. 115. 115. 105. 110. 103.
<1> heh.
<1> eval: join$",map"$_.",unpack"(a)*",kissing # longer
<3> eval: join$",map"$_.",unpack"A*",kissing
<2> Juerd: k. i. s. s. i. n. g.
<2> avar: kissing.
<3> eep
<4> So much so, I wrote a C library, libpack, to use the same idea from C
<3> oh yes, parens
<3> LeoNerd: did you publish it?
<4> avar: http://www.leonerd.org.uk/code/libpack
<3> dongs
<3> is it enterprise-ready?
<3> GumbyBRAIN: hello picard
<5> picard/kirk?
<4> Heh.. Hardly.
<3> C code with unit tests
<4> Version 0.1. It's got a longer TODO list than features list
<4> Though it does have unit tests
<3> isn't that against the law?
<4> I don't claim 100% coverage, but I think it's not far off
<3> GumbyBRAIN: You are in violation of the lawl
<4> And it even has.. *gasp* documentation
<0> GumbyBRAIN: well, you have to give them something to play wiht
<5> Well skyler it is to play wiht.
<3> hrm
<1> LeoNerd: Does it do b prototypes with non-octet boundaries?
<4> And I've tested it on x86, amd64, ppc and sparc/32.
<4> Juerd: Not yet. See my TODO list
<3> eval: *CORE::GLOBAL::pack = sub { "dong" } pack "penis"
<2> avar: Error: syntax error at eval line 1, near "} pack"
<4> Juerd: For now, it presumes that CHAR_BITS == 8, unfortunately. :/
<1> LeoNerd: When it does that, I will use it in Perl :)
<3> eval: [ prototype "CORE::pack" ]
<2> avar: ['$@']
<3> eval: *CORE::GLOBAL::pack = sub ($@) { "dong" }; pack "penis"
<2> avar: Error: Invalid type 'e' in pack at eval line 1.
<1> LeoNerd: That's okay. It's B3/a that I need... :(
<3> eval: *CORE::pack = sub ($@) { "dong" }; pack "penis"
<2> avar: Error: Invalid type 'e' in pack at eval line 1.
<4> Juerd: But that's the only ***umption. Specifically, it doesn't ***ume anything about word sizes or endianness
<3> eep!
<4> Not even to presume the host must be either big or little.
<4> So it would even run on a PDP-11 :)
<3> can't you override pack?
<1> LeoNerd: So my characters are 8 bit, but shifted over octets.
<1> Parsing that quickly becomes very hairy
<4> Juerd: Umm...? I don't get what you mean... An octet is 8 bits.
<6> ah the vaunted, storied, legendary PDP-11 ;-)
<4> 0x2143 byte order :)
<3> LeoNerd: license?
<4> avar: Ahh.. yeah... about that.. I need to come up with a good wording
<4> avar: Basically, I want to express "here, do what you like, including closed-source commercial software, just make sure you credit me"
<1> LeoNerd: I have [aaabbbbb][bbbccccc][cccddddd][ddd000000], where bbbbbbbb, cccccccc, dddddddd are ASCII characters :(
<1> (high bit always 0 in those ASCII chars)
<6> LeoNerd: try a CreativeCommons license?
<3> LeoNerd: without ****ING SHOUTING AT PEOPLE like the bsd license does?
<1> (They might as well have made it real 7 bit...)
<4> Juerd: OK.. So.. um... shift-down 5 bits, then you've got [00000aaa]BCD
<1> LeoNerd: Unfortunately, this happens in the middle of other mind screwing malaligned things :)
<1> LeoNerd: So yes, shifting helps, but it's still a mess.
<4> somian: Pondered it... But I thought CC was more about creative artistic works, rather than technical engineering works like source code...
<1> A pack that could handle this would help me out :)
<1> Code is art, LeoNerd
<3> a "CC license" makes no sense
<4> Juerd: mail me.. My address is on the website. If you want it, I'll consider adding it
<1> (Actually, unpack)
<4> Juerd: It's in my TODO list anyway - arbitrary bitfields
<1> LeoNerd: If it's on your TODO already, I'll just wait :)
<6> It's definitely said by the CC folks to be for any, but the number of examples given for software programs might seem small
<1> LeoNerd: Thanks for having great ideas and implementing them :)
<4> Juerd: See my introductory rant on why :P Also... I could do with having real users actually using it..
<1> I'd be a Perl user
<1> Inline::C++
<4> somian: I had a look over the FSF's collection of Free software licences... I think MIT is close to what I want. Nice and short...
<7> Good choice.
<4> And straight to the point
<6> You'll be more loved by the F/OSS centrists / mainstream; CC licensing is not considered congruent the OSD last I checked.
<6> with the*
<4> Right.
<8> LeoNerd: what's the URL of your pg?
<8> org uk?
<9> is there a switch/case construct in perl?
<4> yango: Main site is just the toplevel of the link above.
<4> datrus: Not as such. But several ways you could do it. Depends what you're switching on.
<3> perldoc Switch
<9> LeoNerd: on a string
<10> yes datrus
<1> LeoNerd: i[c] may be nice from a C perspective, but it does introduce a difference between data order and prototype order: the c is first in the data, the i is first in the prototype
<4> for $string { m/case a/ and do { .... }, last; m/case b/ and do { .... }, last; m/case c/ and do { .... }, last; defaultcodehere... }
<4> Juerd: Yeah... It's not perfect, I know... But it was the neatest and most readable thing I could think of
<1> LeoNerd: Maybe I'm used to c/i too much :)
<4> Juerd: Bear in mind it's a C library - a library for C programmers to use. I think i[c] is a more readable notation fo rthem
<9> LeoNerd: looks complicated, will just use if/elsif...
<11> that would be "for ( $string ) { ...", right?
<4> datrus: Wait for perl 5.10. I hear that has given/when
<4> anno_: er.. Yes :)
<1> LeoNerd: c/i never made sense for Perl either :)
<1> But you're right that i[c] is easier to learn. Would be easier in Perl too.
<4> Juerd: By the way... For some of the motivation, you might want to read the DBus protocol specs. They use strings similar to mine, to give the message argument prototypes
<1> "making sure we don't do silly things with pointers, guard against buffer overflows"
<1> I read that as "making sure we don't ... guard against buffer overflows"
<4> Mmm...
<4> I've often held the belief that English would be more understandable either with brackets, or with (reverse) polish notation
<1> :)
<1> afk
<12> That sort of categorization is amusing.
<4> It's nice to know my work is appreciated :)
<3> eval: BEGIN { *CORE::GLOBIAL::pack = sub { "dongs" } } [ pack "penis" ]
<2> avar: Error: Invalid type 'e' in pack at eval line 1.
<3> eval: BEGIN { *CORE::GLOBIAL::pack = sub ($@) { "dongs" } } [ pack "penis" ]
<2> avar: Error: Invalid type 'e' in pack at eval line 1.
<4> You can't spell GLOBAL
<4> eval: BEGIN { *CORE::GLOBAL::pack = sub { "dongs" } } [ pack "penis" ]
<2> LeoNerd: ['dongs']
<3> haha
<3> damn caps
<13> the grep problem was a ^M character
<6> ^M represents the control code for carriage return.
<14> sometimes...
<14> matters what text formatting is used... doesnt it?
<13> On my system ^M is treated as a line delimiter. It's PHP and UTF-8 that doesn't like each other perhaps. Currently I'm switching to perl anyways to get better char set control prettier OO syntax and such.
<6> ^M (what it represents) is _always_ CR, carriage return. Not "sometimes".
<13> on my sys it just cut the lines when I GNU grep them
<13> cut as in takes away
<6> Whether that control char alone is the EOL (end of line) or line delimiter is OS-dependent
<4> And terminal
<14> cool
<13> when I grep topic on http://slzone.got-game.org/DAs/index the right line are showing but not the stuff before the ^M (not only in GNU-term)
<13> err. gnome-term
<13> also in tty
<11> sure. ^M returns the cursor to the margin
<13> ok. thanks for the info
<15> isn't ^M just enter?
<16> CR = carriage return = think typewriter carriage
<6> cart-horse confusion
<11> for a carriage return you need to put the horse behind the carriage
<6> nanonyme, you are confusing, somehow, "how to make the control code" with "what the control code does".
<6> anno_++ :-)
<13> anyways the line before the ^M disappears
<17> perlbot, karma c++
<18> Karma for c++: -12
Return to
#perl
or
Go to some related
logs:
#oe
nx lpadmin
lcdproc irtrans
#math
irad ubuntu
#debian
#perl
Mismatch between target UID suphp
mkpart =-1s
#bash
|
|