Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2014-10-07

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
06:22 travis-ci [travis-ci] RPerl build passed. Will Braswell says 'Standardize Development Entry Point Comments ("START HERE")'
06:22 travis-ci [travis-ci] http://travis-ci.org/wbraswell/rperl/builds/37257680 https://github.com/wbraswell/rperl/compare/39326913a676...30a30e7bdaa0
06:24 willthechill yay!  :)
07:50 basiliscos joined #perl11
07:52 rurban joined #perl11
07:56 willthechill rurban: which is faster, text or IRC?
07:56 willthechill also, am I going to be charged money for texting you while you are in Germany?
08:03 rurban maybe. irc is better
08:04 rurban no, this is my company phone, which has a US number and free text roaming
08:04 rurban but aren't your daytime habits a bid odd? :) 3am
08:05 willthechill oh wow, free text roaming with a US number, super gut!
08:05 willthechill 3am?  I'm just getting some work done.  :)
08:05 willthechill it will be dinner and star trek time for me soon
08:05 willthechill :P
08:05 rurban I'm just having breakfast with coffee and cake
08:05 willthechill oh yum!
08:06 willthechill :D
08:06 willthechill rurban: what do you think are the top 3 most important Perl projects, currently?
08:07 willthechill (don't count anything you or I are working on)
08:08 rurban buh, Dancer2, Inline refactor and the ongoing Test::Builder destruction
08:10 willthechill what is special about Dancer 2?
08:10 rurban hopefully better than Dancer
08:10 rurban which is already awesome
08:11 rurban I'm not so sure about Mojo yet, so Dancer still the best
08:11 willthechill I use Catalyst, why do you think Dancer is better?
08:12 willthechill Catalyst is more mature and stable and respected
08:18 willthechill Bender trust rurban
08:18 Bender OK, willthechill
09:59 basiliscos joined #perl11
10:09 basiliscos joined #perl11
13:22 rurban joined #perl11
15:17 davido___ joined #perl11
17:51 basiliscos joined #perl11
19:35 bulk88 rurban, any opinion on removiung SVt_NULL from core and making SVt_IV being the first/initial type for everything?
19:36 bulk88 SVt_NULL becomes a macro def to SVt_IV for back compat reasons
19:36 rurban uh?
19:36 rurban which data had this SVt_NULL type?
19:36 rurban PL_sv_undef maybe?
19:37 rurban I need the B::NULL type, but this should be not affected, when it's a macro
20:23 willthechill bulk88: I may be using this in RPerl, I will try to check later today
20:25 rurban bulk88: I'm not convinced that it is a good idea, but I'm off p5p now. SVt_NULL checks sound faster, and it costs nothing to keep it
20:33 willthechill a few quick greps do not show this usage in RPerl
20:55 bulk88 the idea is, doing sv_Pupgrade to get to an IV is pointless
20:56 willthechill well for some reason I thought I was using the NULL or undef types...
20:57 willthechill but then I think I decided against it because there was no matching type in C/C++
20:57 willthechill NULL doesn't count as a data type in C/C++
20:58 rurban1 joined #perl11
21:04 rurban1 indeed, that might be a win.
21:04 bulk88 undef in PP is determined by SVf and SVp flags, never  the type
21:04 bulk88 type for scalars is simplyv an allocation length
21:04 rurban1 undef should just be a ptr cmp
21:05 rurban1 same for yes,no
21:05 bulk88 what would a refernece to undef be?
21:05 rurban1 if ptr == &PL_sv_undef
21:06 rurban1 every language does it like that. either NULL or some allocated my_null
21:07 rurban1 but I forgot whet else could be of type NULL
21:07 rurban1 there are 6 special values (B::SPECIAL), undef, yes, no, and 3 more
21:08 rurban1 ah, the 3 simple warnings I guess
21:08 bulk88 my ($a, $b, $c); $a = \$c; $b = \$c; $c = "true"; #what is $b? how will the assignment to $c appear in both $a and $b?
21:09 bulk88 perl isn't a objects/strings are immutable thing lie javascript
21:09 bulk88 *like
21:09 rurban1 undef is a singleton
21:09 rurban1 strings and other values are copies, undef not
21:09 bulk88 i dont understand the sterm
21:10 rurban1 yes, no are also singletons, with a high refcount (> 50)
21:10 bulk88 in that case undef is a function which returns under value
21:10 rurban1 only one instance, with many symbols pointing to it
21:10 * bulk88 is having problkems typing at 4 seconds poing time
21:11 rurban1 undef has the highest refcounts of all perl SV's
21:11 rurban1 but there are also some array and hash placeholders, which behave the same as undef
21:11 bulk88 that is because its immortal and has an infinite refcount, you can't store &PL_sv_yes/immortals in a HV or AV since then the slice can't be assigned to
21:12 bulk88 perl SV *s have no pass by copy feature, &PL_sv_* sorta does, but you can't write to it
21:13 bulk88 for your idea to work, HV's and AVs would have to change to not store SV*s but be arrays of of SV heads
21:15 rurban1 That's nit an idea. that;'s how it's implemented.
21:16 rurban1 that's why father wanted to protect it a 2nd time, even if it's SVf_READONLY already
21:17 rurban1 and HVs and AVs already store SVs (which are SV heads)
21:17 bulk88 if a 3rd RO SV flag is added, someone will add a feature request for blessed objects to have unix modes on them
21:17 bulk88 8 layers of permissions to write to an object'shv's keys
21:18 bulk88 $>< to set current priviliage level for writing to objects
21:18 bulk88 taint verison 2
21:18 bulk88 lol
21:19 rurban1 the new system is total nonsense and I hope everyone knows that. But they blocked my patch so they will not see how the probkem should have been solved.
21:19 bulk88 hash key uitil's key locking should have been done with a MG struct
21:19 bulk88 which is a sentinal value which says that hash key util locked it in the first place
21:19 rurban1 nope. there are only 3 values which needs to be kept READONLY when unlocked
21:20 rurban1 but a MG to store the prev state when being locked is also good, yes
21:20 rurban1 nobody cares about hash lock states, can easily be MG
21:21 bulk88 also make it fatal to lock a RO flagged SV*, thereis SVIMMORTAL for the specific problem
21:21 bulk88 and the == &PL_sv* you mentioned earlier
21:21 rurban1 But using Internals::SvREADONLY is not safe. Always was. Is documented as such.
21:22 bulk88 that are protecting the guy that shot himself in the foot
21:22 bulk88 there is no "bad usage" of internals::svreadonly tro protect against
21:22 rurban1 there is. this is critical compiler and optimizer information.
21:23 rurban1 since p5p refuses to do such optimizations it's up to 3rdparty to do it. so it's me
21:24 rurban1 hence I need a reliable SvREADONLY bit, and not a softened as now
21:24 bulk88 the readonly flag can't be safely used as a const flag in its current implementation since  ppl use it form XS for sanity checking
21:24 bulk88 and it comes on and off an SV through execution
21:24 rurban1 that's their problem then. readonly means readonly, nothing else
21:24 rurban1 some releases ago it meant something else with FAKE, but this case is gone
21:25 rurban1 classes will be locked and final, methods can be inlined and early bound, the constant folder can do some work
21:25 bulk88 a week ago I made NV's be SV head stored on 64 bit platforms BTW
21:25 rurban1 but it needs 2 words
21:26 rurban1 I see, yes. doable
21:26 rurban1 good idea!
21:26 rurban1 just long double and 32bit need an SvANY then
21:27 bulk88 im surprised that the fix wasnt done in 2005 by nick when the original sv head union (4th member of sv head) was added in 5.9
21:27 bulk88 SVt_NV on x64 still uses SvANY, it is just there is no areana now
21:28 bulk88 if you compile perl on x32 with 64 bit IVs, you also get NVs stored in the head
21:29 rurban1 And I made p2 as fast as C on small samples, but the bigger samples are almost as slow as perl5. Too dynamic methods still, and no compiler-time optimizations at all yet (readonly, early bindings, types, …)
21:29 rurban1 luajit is far ahead
21:29 basiliscos joined #perl11
21:30 rurban1 but at least array access is not jitted and fast
21:30 rurban1 now jitted, sorry
21:31 rurban1 done for today, bye
21:34 bulk88 https://rt.perl.org/Ticket/Display.html?id=15667#txn-1310142
21:34 bulk88 a write up I did of how bad perl's SVs are vs all the other major engines
22:23 dalek joined #perl11
22:41 basiliscos joined #perl11
23:19 dalek joined #perl11
23:25 davido__ joined #perl11

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary