# IRC log for #perl6, 2006-12-31

All times shown according to UTC.

Time Nick Message
00:01 TimToady luqui: I've been thinking a lot about Num semantics lately for some reason.  :)
00:02 luqui :-)
00:02 TimToady there are various approaches we could take
00:03 TimToady I think we should generally steer the naive user away from having to think about Rats.
00:03 TimToady but that doesn't mean we can't have the available
00:04 TimToady or possibly Num semantics do "lazy division".
00:04 TimToady much like Int semantics are "better" than int semantics, we could leave num semantics as bare floaters and make Num a little smarter.
00:05 luqui so that counts out the mathematica way (which is the most obvious, but not obviously correct, to me): 1 is exact, 1.0 is approximate...
00:05 TimToady or we could make a lexical pragmatic choice about which division / etc means.
00:06 luqui but you want eg. sum to be polymorphic
00:06 luqui and still use +
00:06 TimToady most things just work "right" with MMD, but division wants to kinda be special
00:07 luqui (that one has to be approximate, unless we implement algebraic numbers :-/ )
00:08 luqui I think most programmers are going to want floating point
00:08 TimToady well, Perl 5 gets along quite well with just int and double
00:08 luqui I don't think the lexical pragma should control what / means
00:08 TimToady I agree, I'm just wondering if it buys us anything to defer 1/3 division
00:08 TimToady till we really need the floater.
00:08 luqui I think, if it exists, it should control whether numbers without decimals are treated as rats or nums
00:08 luqui hmm
00:08 luqui wait, that doens't work
00:09 luqui because we still want Int (do we?)
00:10 TimToady I think people think they want Int whether it turns out they do or not...
00:11 luqui there's always the haskell route: use a different operator for exact division
00:11 luqui or construction of rationals...
00:11 svnbot6 r14962 | perlDreamer++ | These splat tests are no-ops.  | and * only work with Capture objects.
00:11 luqui that is
00:11 TimToady I think Num can choose any internal representation it wants for a given number
00:12 luqui I do know that I like that they have a separate operator for integer division
00:12 luqui because it's useful, but it is surely different than division
00:13 TimToady if we went the pragmatic route then lexically infix:</> ::= infix:<rdiv> for instance.
00:13 TimToady and then it make Rats.
00:13 luqui but rdiv on floats would still result in a float?
00:13 TimToady and Rats presumable dispatch differently
00:14 TimToady I mean "my infix:</> (Int, Int) { rdiv }" actually
00:15 TimToady Num/Num would presumably still call fdiv, or ndiv, or whatever we call it.
00:15 luqui hm...
00:15 TimToady long form should probably be intdiv, numdiv, ratdiv for clarity
00:15 Psyche^ is now known as Patterner
00:16 TimToady make that "my multi infix:</>"
00:16 TimToady so it still MMDs correctly to nonInt
00:16 perlDreamer karma diakopter
00:16 jabbot perlDreamer: diakopter has karma of 2
00:16 perlDreamer karma perlDreamer
00:16 jabbot perlDreamer: perlDreamer has karma of 16
00:16 diakopter perlDreamer++ for querying my karma
00:16 TimToady and other operators like **
00:17 luqui TimToady, I think of Nums as numbers that have some sort of error in them
00:17 luqui so I think Num sucks up more precise forms into itself
00:18 TimToady used to be that floaters could completely suck up ints until we went from 32-bit to 64-bit ints.
00:18 luqui well, they still can, right?
00:18 luqui no 64 bit int is large enough to handle 1e300...
00:18 TimToady but potentially with loss when using 64-bit float
00:19 TimToady I think we need to think about it from the use case end--who wants which guarantees?
00:19 TimToady a lot of people just want fast and "accurate enough"
00:20 luqui and probably don't want any math to run out of memory...
00:20 dduncan but there should be an easy way to specify that we want more accuracy at runtime
00:20 TimToady a lot of other folks want "as accurate as possible" and don't care very much how fast.
00:20 luqui dduncan, at runtime? really?
00:20 luqui I suppose they do
00:21 TimToady dduncan: part of what makes the fast kinds fast is to commit to it.
00:21 luqui but, eg., computing the mandelbrot set using rationals instead of floats will quickly eat up all your memory
00:21 nperez joined perl6
00:21 dduncan I'll rephrase that ... I don't want to have to compile Perl with different flags to switch modes
00:21 TimToady which is why I'm thinking about Nums that do Rat up to a point and then revert to floaters
00:21 luqui dduncan, oh, of course
00:21 luqui I don't see the win
00:22 Tene joined perl6
00:22 luqui why not just use floats?
00:22 dduncan in my mind, the best way to do it is have something akin to different data types for different behaviours ... probably along the lines of a parameterized numerical type ...
00:22 luqui they are accurate up to 64 bits..
00:22 dduncan eg, you parameterize a generic numerical type to indicate what the maximum accuracy you care about is ...
00:23 dduncan and if that is something that will fit in an ordinary int or float, we get that fast performance ...
00:23 luqui dduncan, I think that is best left to a scientific computing library
00:23 dduncan and if it is too big, we get bigint or something that auto-switches
00:23 luqui I think we best worry about when to do things exactly, and when not to
00:24 TimToady default should be "not exact" like Perl 5
00:24 luqui agreed
00:24 TimToady but Int gives us infinite precision anyway, unlike P5
00:24 luqui I'm inclined to say that we should just have a rational constructor
00:24 luqui but that is tricky, because Int/Int is allowed
00:24 luqui so... maybe not
00:25 luqui I'd better go :-)
00:25 dduncan but regardless, I think we can all agree that if you take an identical Perl 6 program and run it on machines with different CPU architectures, any math in them will produce the same answers, or alternately, that Perl 6 has explicitly documented a particular variance that is allowed or may happen
00:25 * luqui &
00:25 dduncan portability is good after all
00:25 TimToady yes, to both of you.  :)
00:28 svnbot6 r14964 | perlDreamer++ | add smartlink to repeat operator test
00:28 dduncan fyi, in my DBMS type system, I'm making my numerical types parameterizable, so that implementations can appropriately optimize when people say they only need to represent integers in 0..2**31 vs they want to represent 0..2**10000 with full precision
00:29 dduncan still, we'll see how that actually works out in practice once implemented ...
00:29 dduncan but besides users indicating what precision they want, they don't say anything else to specify implementation ... the system figures it out for them ...
00:29 TimToady in Ada you say "I want something 0..1_000_000" and let it worry about the representation
00:30 dduncan okay
00:30 dduncan I've never used Ada
00:30 dduncan as far as all that goes, integers are the easy part ... making this work with non-integers is more tricky to specify
00:31 TimToady but it always bothered me a little to have arbitrary boundaries when the actual base type probably can store more...
00:31 dduncan I also anticipate having numerical types that are not parameterized, but I'm less sure how to make their behaviour portable
00:31 dduncan eg, when implementing the DBMS over Perl
00:32 dduncan and the underlying will just handle its own scaling
00:32 Daveman joined perl6
00:33 dduncan still, I don't have to do everything at once ... I can just make something that works for some tasks, and let it evolve
00:33 dduncan not all problems have to be solved before any are functional
00:33 svnbot6 r14965 | perlDreamer++ | remove pod comments for tests that are now passing and add smartlink
00:35 dduncan so on that note, my very first releases of QDRDBMS, which are over Perl, won't parameterize numeric types ... it will just become more important to do so when making a back-end for it that is over some other storage engine, like a SQL one, where they have different base types depending on max precision supported
00:35 weinig|bbl is now known as weinig
00:36 dduncan fyi, the terminology I use in my docs is "finite types" vs "infinite types" ... the distinction being how many values the data type can have ... 1 to 100 is finite, while all integers is infinite
00:36 dduncan finite can be derived from infinite in a way similar to Perl 6's subset of Int where 1..100 or something
00:37 TimToady which is more or less the Ada approach in disguise.
00:37 dduncan I see
00:37 dduncan the idea is that with a finite type, we can guarantee that all values of the type are representable some how, but with an infinte type we can't
00:38 dduncan okay ... I just call my infinite integer "Int" though, because afaik that's what the Perl 6 Int represents
00:38 TimToady but my memory is fuzzy, it may be that universal integer is only supported at compile time.
00:39 TimToady anyway P6 Int is "universal integer"
00:39 dduncan yes
00:39 TimToady not sure whether it makes sense to let Num be an infinite type though.
00:39 TimToady part of why I was wondering about whether a Num could decide to be a Rat inside.
00:40 TimToady at least up to a point.
00:40 dduncan yes, Num is more complicated
00:40 dduncan and has at least 3 popular representations that I know about
00:40 TimToady it might make it easy to do lossless scaled arithmetic on money, for instance.
00:40 dduncan floating point, rational (2 integers), and as strings of digits
00:41 dduncan afaik, Python or Ruby does nums as rational
00:41 TimToady Rexx used exact decimal arithmetic
00:41 TimToady so "string of digits" approach
00:42 TimToady so I wonder how polymorphic/generic Num can be in a given lexical scope.
00:43 dduncan but as you know, a main problem with arbitrary precision non-integers is when we have an irrational or some such result of an operation ... how much of its detail is stored ... this is one place where a parameterization of a Num type could come in handy ...
00:43 TimToady and if one scope thinks Num is strictly floaters, while another thinks it's strictly decimal strings, what happens then?
00:43 dduncan and afaik, Perl 5's BigNum or BigRat is parameterized
00:43 neonse left perl6
00:44 dduncan if parameterized, I would use floats for low-precision-required nums and decimal strings or such with high-precision ones
00:44 TimToady one approach is to say that we attempt to do exact arithmetic until something ridiculous comes up like you mention, and then just punt to floaters for irrationals or approximations.
00:44 dduncan if unparameterized, I suppose it could be dynamic, but the question is when to switch
00:45 dduncan and on that note, we shouldn't have to punt until an operation that isn't +|-|/|* comes along
00:45 TimToady and the Big question is whether lexically scoped multis give us all the flexibility we need.
00:45 dduncan I can't yet say
00:46 TimToady well, arguably floaters punt all the time on / and *
00:46 TimToady and on +/- when the numbers are ~15 digit precision or so.
00:47 TimToady if there is a pragmatic lexically-scoped solution, I wonder how many knobs it has.
00:48 dduncan do you know any languages that internally maintain numbers as formulae ... which is the most precise possible, but doesn't scale well?
00:48 TimToady or whether one knob with several settings will suffice
00:48 dduncan one knob should be sufficient with integers, but with nums, I would have 2-4 or so
00:48 TimToady I don't know for sure, but I suspect Mathematica does some of that.
00:49 TimToady seems like you'd have to do that to do reasonable integration/differentiation
00:49 dduncan eg, at least 2 knobs for a Num that are implementation agnostic are "what are the maximum and minimum in magnitude values that need to be accurately remembered"
00:50 allbery_b mathematica, macsyma, ...
00:50 TimToady or you won't know when you can get away with multipling infinity by 0 and get a reasonable answer...
00:50 dduncan which is loosely like "precision and scale" of some systems
00:50 dduncan but is agnostic to the base of the number system
00:50 dduncan and of course, zero is supported in addition to the minimum, which isn't zero
00:51 dduncan eg, if a user says I want to support as large as 10**30 with precision as little as 10**-10 ...
00:51 dduncan then a representation could be used that has around 40 digits of accuracy
00:52 dduncan and the spec is agnostic to whether it is actually decimal or binary or whatever
00:52 TimToady heck, let's just make everything a 256-bit floater.  :)
00:52 dduncan since the spec counts in actual boundary values of a sort, rather than count of digits etc
00:53 * diakopter tries to fit 200,000,000 256-bit floaters in 2GB of ram
00:53 TimToady free ram upgrades for everyone!  three chickens in every pot!
00:54 dduncan anyway, the abovementioned is how I'm currently approaching parameterizing a Num on my system
00:54 dduncan or intending to ... that represents 2 knobs for a Num anyway
00:55 TimToady the mere mortal just wants it to be a Num, and run fast, and don't bug me about it.
00:55 TimToady so probably different kinds of Num have to be taught to interoperate as seamlessly as possible.
00:56 TimToady probably MMD gets us most of that, with enough definitions for conversion functions.
00:56 TimToady though perhaps we might distinguish lossless from lossy conversions and make the latter a little harder to get.
00:57 dduncan indeed ... and doubtlessly we will get many different representations in use, as they each have their advantages ... but all still under the hood
00:57 dduncan now ...
00:58 dduncan might it be worthwhile to have some sort of flag attached to a numerical value or container that says whether or not the value it contains is an exact or inexact result of the operation the produced it? ... sort of like a taint flag but not for tainting
00:59 TimToady dunno.  if you're gonna go that far, most scientific type people would just as soon it calculate your error bars for you.
00:59 dduncan mayhaps this could be abstracted or extended into a "significant figures" flag
00:59 TimToady this has been attempted in the past, with notable lack of long-term success.
01:00 TimToady people would usually rather have a fast answer and just guess about whether it's accurate.
01:00 TimToady so they stick with floaters, and external analysis.
01:00 TimToady (or more frequently, non-analysis :/ )
01:01 dduncan what about integers? ... is it reasonable that a Perl 6 integer will never be represented by or failover to floating point no matter how big it gets? ... so those at least remain fully accurate?
01:02 TimToady as long as you stick to integer arithmetic on the Int type, yes.
01:02 TimToady and ** get problematic though
01:02 TimToady er, / and **
01:02 dduncan but presumably ** will have a multi, where one takes just integers, and the other nums
01:02 dduncan er ...
01:02 dduncan though a negative integral exponent won't be an int
01:03 TimToady and you can't tell with / whether they *want* idiv or fdiv...
01:03 dduncan but we can define a multi variant taking a positive int, or a number
01:03 dduncan as for / , I would say have 2 division operators
01:04 dduncan users specify behaviour they want by which one they use
01:04 AtomicStack joined perl6
01:04 theorbtwo Can we have an int infix:<**>(int base, posint exponent), and define an int->nonnegint as operator that says "nope, can't do that" for \$_<0?
01:05 TimToady why not just MMD over to returning a fractional result?
01:05 dduncan the term / can be a multi, where if both of its arguments are Int typed, then it does integer division, else Num division
01:05 TimToady dduncan: that is not what the naive user would expect.
01:05 theorbtwo dduncan: 2/3 being 0 wouldn't be least surprise.
01:05 dduncan well then ...
01:06 dduncan back to my earlier suggestion of 2 operators that look different
01:06 luqui that is the single largest point of confusion in the intro to programming class i teach
01:06 theorbtwo Is int(\$a/\$b) too longwinded/nonoptimizable?
01:07 dduncan I wouldn't do that
01:07 dduncan I would say either \$a idiv \$b or \$a ndiv \$b ... rename ops to something better
01:07 theorbtwo Too bad integer doesn't have a nice type indicator like ~.
01:08 dduncan in any event, the idiv would take or cast its args as integers before doing the op
01:08 TimToady which gets a different result from int(\$a/\$b)
01:08 dduncan yes
01:08 theorbtwo Mm, g'point.
01:09 dduncan and I think casting args as integers first to give int division is what users expect
01:09 svnbot6 r14966 | perlDreamer++ | smartlinks for operator tests, finished
01:09 theorbtwo Well, the point most of the time, I think, is optimizability, and that means the rule has to be truncate first.
01:09 dduncan sure, whatever, they are just turned into ints first
01:10 theorbtwo a ./ b ?  Is that too misparsable as concat followed by regex?
01:10 TimToady . isn't concat in P6
01:10 theorbtwo Hm, or as a decimal point after a, for that matter.
01:10 theorbtwo d'oh.
01:10 theorbtwo s/concat/method call/, then.
01:11 dduncan on that note, if it doesn't already, Perl 6 should have multiple explicit ops where users can specify how a num becomes an int ... at least floor and ceil and round ... and truncate
01:12 dduncan if they are explicit about it, then code is more self documenting
01:12 theorbtwo dduncan: I'm fairly certian they're already in Snn.
01:12 dduncan though one op can be picked as a default
01:12 dduncan a documented default
01:12 TimToady a lexically scoped pragmatically selected default.
01:12 dduncan sure
01:12 TimToady just wondering if / is the same.
01:13 TimToady default default is ndiv, but user can change default to idiv or rdiv.
01:13 dduncan in a strongly typed language, / would refuse to compile if both arguments weren't the same type ... int or num ... in our case, I don't imagine that will be a compile time error
01:14 dduncan but it would default to something
01:14 theorbtwo Promoting the int to a num, I should think.
01:14 TimToady I think the minimum convertibility between any two types has to be guaranteed to be with at least the precision of floating point.
01:14 theorbtwo I still don't think we really care what the types of the args are for /, though.
01:15 dduncan if we always promote the args of / to num, it won't matter ... for normal numbers
01:15 theorbtwo For **, sure, there are lots of opts you can do if you can prove the result is real, or even better an int.
01:15 TimToady and two given types can negotiate greater precision of conversion if they like via MMD
01:16 dduncan so how is modulus spelled in Perl 6 again?  "%" or "mod" or something else ?
01:16 dduncan if it is "mod", then "div" would be a perfect complement for integer division, leaving "/" for num
01:17 dduncan since modulus makes no sense with non-integers
01:17 TimToady make / and % default the default to ndiv and nmod
01:17 TimToady dduncan: yes it does.
01:17 theorbtwo ...and make the stringy versions be div and mod?
01:17 dduncan well I suppose if the modulus doesn't have to be an integer, then yes
01:18 TimToady but also have idiv and imod, rdiv and rmod, etc.
01:18 theorbtwo Er, make the stringy versions be idiv.
01:18 dduncan for some reason I thought mod always applied to integers, but I suppose it doesn't have to
01:18 theorbtwo Er, if i* truncates, shouldn't it be t*?
01:18 theorbtwo (Assuming r* is round.)
01:19 theorbtwo Oh, that's more sensical.
01:19 TimToady and maybe D for Dec
01:19 theorbtwo If int/int -> rat and rat/rat -> rat as well, then it sounds wonderful.
01:20 TimToady arguably Dec is just Rat where the denominator is constrained to a power of 10
01:20 * theorbtwo wonders if math::trig will want to make a pirat.
01:20 TimToady int/int -> rat would not be the default default, but could be selected if we make / mappable to one of the others.
01:20 theorbtwo (As in (a*pi+b)/(c*pi+d).)
01:20 dduncan are users going to be allowed to pick the conceptual representation of a non-integer by picking a built-in type, eg Rat vs Dec, or is that strictly behind the scenes or pushed to libraries?
01:21 allbery_b 22/7?  arrr(g)!
01:21 TimToady Int/Int -> Num is the default.  But one of the approaches I mentioned to luqui earlier is to make Num do Rat internally when it makes sense.
01:21 TimToady not sure if that's well defined though.
01:22 theorbtwo Hm, should be reasonable well defined... though not if you want near-exact repeatability in all/most cases, though...
01:22 theorbtwo Er, right.  That sentence contains so much faffing about as to be more or less meaningless.
01:22 TimToady dduncan: you can pick the default results for certain operations, but once something is constructed a certain way most of the decisions are made by MMD.
01:23 TimToady I think in practice / is where almost all the decisions are made on which type to return.
01:25 allbery_b haskell's numeric typing indicates a problem with this whole thing; I recently found mysef forced to make everything RealFrac so I could use both trig and (floating) division because there are so many different type constraints involved with various operations in the name of choosing appropriate representations
01:26 allbery_b (because / really wants to use a more exact representation when possible, but trig functions make it impossible)
01:26 TimToady RealFrac being floating point?
01:27 allbery_b RealFrac incorporates both Real (for trig) and Fractional (for division)
01:27 TimToady wait, you just said that.
01:27 theorbtwo allbery_b: I think that'll be helped by perl coders being more willing to define conversions that will loose some information, and perl making it easier to create as operators (and use them implicitly where it thinks it needs to).
01:27 TimToady okay, what I've been arguing for is that Num be something like RealFrac then.
01:28 allbery_b sorry, RealFLoat.  I started out with RealFrac
01:28 allbery_b Floating for /, Real for sin()/cos()
01:28 TimToady being more familiar with Fortran where real is floating
01:28 allbery_b haskell is admittedly an extreme case, in the name of making te programmer do manually what is being proposed that perl6 do automatically
01:28 dduncan I don't know if this has been thought about yet, but when numbers get into the domain of being imprecise, what do we do about testing equality?
01:29 dduncan eg, when \$a and \$b are 2 imprecise numbers, how is \$a == \$b determined?
01:29 TimToady P5 just punts that to the user.
01:29 allbery_b lemme see if I can find it again, I've already forgotten the fine distinctions :/
01:30 ingy merry merry
01:30 dduncan with integers it is trivial, with nums we should have something workable ...
01:30 TimToady ingy: we're almost to happy happy now.
01:30 ingy noted noted
01:30 dduncan perhaps multiple numeric equality operators ... or lexical pragmas ... are useful here
01:31 allbery_b okay, Fractional is /, Floating is trig and exp/log
01:31 dduncan eg, either == only returns true if both numbers are using the same representation and are exactly the same ...
01:31 allbery_b and RealFloat is atan2
01:31 dduncan or there is some fuzzy variance range ...
01:31 allbery_b RealFrac was sufficient to get both trig and / until I needed atan2...
01:31 dduncan where numbers within a certain value of each other are declared equal
01:32 ingy quick question: what subset of Perl 6 translates to Perl 5 with a minimal runtime library?
01:32 allbery_b it all makes sense at an implementation level, but is just painful for the programmer
01:33 dduncan I would imagine that a purist approach would be that if 2 numbers are substitutable for each other in all operations and return the same result, they are equal, otherwise not ...
01:33 dduncan that said, in real life ...
01:33 ingy TimToady: is that the name of an executable?
01:33 dduncan I anticipate that people wouldn't be using inexact numbers to be the identity of anything ... and identity is where exact matches really matter
01:34 ingy ok
01:34 dduncan but I will have to figure out something for my DBMS, since the true relational model says that all data types can be compared for equality, and that any difference at all is a significant difference
01:35 allbery_b (that's another problem Haskell points up, Floating / Fractional / RealFrac / RealFloat are advertised as Eq but aren't :)
01:35 theorbtwo The problem with fuzz in my mind is where you stop.
01:36 theorbtwo If two numbers are very nearby, are they ==, !=, <, and > in all combinations?  Do you always return true if it could possible be true?
01:36 dduncan ... but I would solve that problem with parameterized types such that only the portions that are deemed significant are what are actually tested ... probably ... mainly the substitutability of the 2 values are the answer that truly matters
01:37 theorbtwo I expect what users generally want with the comparisign ops is to convert both to the least-accurate type, and see if they are numerically equal then.
01:37 dduncan makes sense to me
01:38 TimToady I'm inclined to say that == continues to behave much as it does in P5
01:38 dduncan especially if it is interpreted that they are doing an explicit truncation on both values
01:38 balony joined perl6
01:38 TimToady convert to floater, and check for exact.
01:38 dduncan then since that was explicit, and they compare the results, no fuzzyness is left to worry about
01:38 TimToady if you want to parameterize the test, use an eqv variant.
01:38 allbery_b dduncan: RDBMSes are supposed to handle that by not supporting floating point, you use something like NUMERIC(size, prec) and regardless of what's used internally values are the same if their declared "shape" gives them the same value
01:38 allbery_b of course, floating point is a common extension which then breaks the rules
01:38 dduncan that's a thought
01:39 dduncan and I was trying to make my system agnostic to whether numbers were floating point or not
01:39 dduncan but thanks for the rationale
01:39 theorbtwo ...unless mmd says otherwise, presumably.
01:41 allbery_b *shrug* you can use FP internally or not, the DBMS can use it internally or not, but the internal representation has to be able to express the declared size/prec and equality is computed in terms of that as well
01:41 dduncan sure
01:41 allbery_b unconstrained FP is forbidden si equality istestable
01:41 allbery_b *so
01:41 TimToady floating point is like the basic rules of diplomacy.  any two countries are free to negotiate better or worse relationships...
01:41 ingy my checkout don't have v6/v6-MiniPerl6, I must be way out of date
01:42 ingy upping slooooowly
01:42 TimToady well, yes, considering that mp6 has been the main push for the last couple of months...
01:43 ingy and my repos is exactly a couple months out...
01:43 * allbery_b essentially gave up when mp6 started revving up because he's afraid to touch anything... :/
01:44 TimToady I wouldn't worry about that too much; the test suite is what is supposed to guarantee eventual convergence.
01:44 TimToady and mp6 is really only going to replace the current Haskell compiler in lambdaland.
01:45 TimToady anything in the runtime is likely to be useful for a goodly long time yet.
01:45 TimToady after all, the specs merely say that the parser for Perl 6 has to be written in Perl 6, not the run-time.
01:46 allbery_b hm, reminds me I should look at diffs and see why some refactoring I did with the file time tests didn't seem to be in recent code
01:46 allbery_b did I forget to commit it or did it get reverted?
01:46 TimToady dunno, svn should be able to tell you.
01:47 TimToady usually if someone reverts something they're nice enough to put a comment or log entry explaining why.
01:47 allbery_b (basically:  factored out code for "time" so I could use it to set the script startup time, but the code to do *that* wasn't there last time I looked)
01:49 allbery_b right, "XXX factor "time" and use it here and in filetime tests" --- so the filetime tests are currently broken (in a way the test scripts won't catch)
01:49 allbery_b because if that code vanished they're based on the unix epoch instead of the perl epoch
01:49 dduncan On an unrelated matter, I'm thinking I would like to attend YAPC NA this year (my first YAPC), in Texas I think ... for those of you that fly a lot, about what would it cost to fly there from the general area of Seattle, WA?  ... that would probably be my largest expense
01:50 allbery_b huh.  no, the code is correct, the comment is obsolete
01:50 dduncan eg, can I get it for under \$500 each way, or am I looking much higher?
01:50 TimToady but nothing is terribly cheap these days, what with fuel prices...
01:51 TimToady you can almost certainly do better than that.
01:51 dduncan TimToady, you often drive, don't you ... and take your family along ... or was that just to the last 2 OSCON?
01:52 TimToady have always flown to YAPCs
01:52 dduncan I see
01:52 TimToady also tend to fly to EuroOSCON for some reason... :)
01:53 dduncan now technically I would be departing from Victoria BC, but I understand that flying's a lot cheaper if I depart in the US instead
01:53 dduncan for strange reasons
01:53 dduncan either way, Seattle is a ferry trip away if I need to go that way
01:54 theorbtwo Hm, wouldn't have thought it'd make much difference CA/US, but shrug.
01:54 theorbtwo You'd probably know much better then I would.
01:55 Aankh|Clone joined perl6
01:55 ingy TimToady: wanna kayak to Tokyo this spring?
01:55 ingy dduncan: where do you live?
01:55 dduncan I live a half-hour drive out of Victoria BC
01:56 dduncan if you visit the Buchard Gardens or something else around here, you're real close
01:56 ingy Tofino?
01:56 TimToady currently Southwest will round-trip in April from seattle to austin for about \$200
01:56 dduncan thanks for the tip
01:56 svnbot6 r14967 | allbery_b++ | remove obsolete comment left over from filetime test development
01:56 TimToady 329 for fully refundable.
01:56 ingy I live in Seattle proper
01:57 TimToady not sure which city is YAPC though...
01:57 allbery_b @slap allbery_b
01:57 lambdabot why on earth would I slap allbery_b
01:57 allbery_b ...because I'm a yutz?
01:57 TimToady also, they don't book far enough in advance to see what it would be in June
01:57 allbery_b :p
01:57 dduncan University of Houston, apparently
01:57 dduncan that's what http://www.yapc.org/America/ says
01:57 lambdabot Title: YAPC 2007: Yet Another Perl Conference
01:58 * allbery_b confused himself badly by leaving that comment in place...
01:58 dduncan still, I've never been to the south-east US before, so it'll be interesting
01:58 theorbtwo Texas isn't south-east.
01:58 dduncan mainly I've been along the whole west coast of it, and the north-east corner
01:59 dduncan well, its south-middle
01:59 theorbtwo 1;
01:59 dduncan but I haven't been in the middle either
01:59 ingy I hate how west coast people say Chicago is East Coast
01:59 dduncan what I said before was a slip ... and I consider Chicago, the north middle
01:59 ingy Houston is the home of the breast implant
01:59 TimToady actually, I'm looking at it wrong, round-trip is minimum of about 300
01:59 TimToady houston same as austin
02:00 dduncan actually, I was in Chicago briefly myself ... was driving through it in 1994 with family
02:00 ingy dduncan: are you near tofino?
02:00 theorbtwo The closest I've been to Chicago was YAPC::NA::200... er, 3?
02:00 dduncan we had to drive to Ontario in a hurry, and decided that the US interstate was more expedient
02:00 dduncan just a minute ...
02:01 ingy it is more expedient
02:01 dduncan fyi, the trip was made in less than a week ... left home on tuesday morning, arrived saturday at 4pm
02:01 ingy canada is hardly crossable afaiac
02:01 ingy especially in winter
02:02 dduncan there is a cross-country highway since the 1960s, but it isn't so straight as an interstate
02:02 TimToady I've been through the Rockies on it, not too bad.
02:02 ingy canada's cross-coutry highway is 36000 feet above sea level
02:03 TimToady well, at least it doesn't do loop-the-loops inside the mountain like the railroad tracks do...
02:03 ingy I started driving across canada and never got past Kamloops
02:04 ingy it can get sketchy
02:04 dduncan I drove from Victoria to Edmonton in 2 days, 1 night, so that's all of the mountainous area
02:04 dduncan er, was driven
02:04 dduncan I leave that up to others, I'm not really a kayaker
02:05 TimToady was taunting the ingyness
02:05 ingy google earth makes me understand why Seattle is so much closer to taipei than sfo, and why you go over alaska to get to the tropics from here
02:05 dduncan ingy, if you want to know exactly where I am, feed this into Google maps; its quite accurate: 724 Wain Rd., North Saanich, BC, V8L 5N8
02:06 ingy I <3 Tofino
02:06 dduncan unfortunately, the result url isn't copyable, as it looks like a post request
02:06 dduncan one moment ...
02:07 theorbtwo Er, actually, you just have to hit "link to this page".  (You only need to move it if you actually want an explicit lat/lon in the request.)
02:07 lambdabot Title: Google Maps, http://tinyurl.com/yms6nk
02:07 buubot http://xrl.us/t3j4
02:07 ingy later all.
02:08 theorbtwo Wow.  You can probably get *really* good planespotting photos.
02:08 dduncan later
02:08 theorbtwo G'localtime.
02:08 dduncan that's true, actually
02:09 rafl joined perl6
02:09 dduncan if you pick the second-to-closest zoom level, you can see my house, car, and various greenhouses quite clearly
02:12 buetow joined perl6
02:22 Aankh|Clone is now known as Aankhen``
02:30 thseiler joined perl6
02:52 dduncan left perl6
02:55 meppl gute nacht
03:03 dolmans joined perl6
03:07 mr_ank joined perl6
03:14 vel joined perl6
03:29 thestarslookdown joined perl6
04:49 * allbery_b sighs --- of course deketing that one comment causes nearly everything to be rebuilt :(
04:49 allbery_b ^k^l
05:15 baest joined perl6
05:30 Aankhen`` joined perl6
05:46 TubaChuck joined perl6
05:48 luqui joined perl6
05:53 Schwern joined perl6
06:21 pstickne joined perl6
07:05 lambdabot joined perl6
07:30 luqui joined perl6
07:46 avar I like Pugs's Test.pm a lot better than Test::More
07:49 wilx joined perl6
07:56 gaal where would we be if we didn't build on past experience
08:00 Belaf joined perl6
08:12 Khisanth gaal: the same place we were before!
08:20 dolmans no, there is no before, so nowhere indeed.
08:42 gaal you can never throw out the same baby twice with the same bathwater, etc.
09:24 polettix joined perl6
09:27 luqui joined perl6
09:43 Schwern joined perl6
09:54 bernhard joined perl6
10:25 elmex joined perl6
10:32 lambdabot joined perl6
10:52 b_jonas joined perl6
11:02 devogon joined perl6
11:09 thseiler joined perl6
11:32 iblechbot joined perl6
11:32 lambdabot joined perl6
11:33 chris2 joined perl6
11:35 b_jonas checking the url hortening: http://maps.google.com/maps?hl=en&amp;q=san+francisco&amp;ie=UTF8&amp;oe=UTF-8&amp;z=14&amp;ll=37.775871,-122.27869&amp;spn=0.050542,0.10849&amp;t=k&amp;om=1
11:35 lambdabot Title: Google Maps, http://tinyurl.com/yj74x5
11:36 allbery_b lambdabot was "recently" modified to only shorten urls above some particular length, fwiw
11:37 b_jonas I was trying the interaction between buubot and lambdabot really
11:38 allbery_b ah.  I'd been wondering about that myself
11:38 allbery_b (since they both listen to leading "?")
11:44 b_jonas I don't think buubot listens to leading "?". buu?
11:44 allbery_b not buubot, actually.  evalbot
11:45 b_jonas oh
11:45 b_jonas ok
11:45 * allbery_b is a little fuzzy; insomnia
11:45 allbery_b tired but can't sleep for some reason
11:45 allbery_b (likely the same reason the cats are bouncing off the walls and swinging from the chandeliers...)
11:47 buu buubot was just bugged
11:48 buu I have absolutely no idea why.
12:03 agentzh joined perl6
12:06 agentzh xinming: socks proxy is needed for irc traffic, i think. i'm paying for the socks server that i'm currently using. :)
12:07 agentzh perlDreamer++ # for fixing smartlinks
12:08 agentzh perlDreamer: the cron on feather told me 2 min ago that "486 smartlinks found and 2 broken." :)
12:17 thseiler joined perl6
12:20 Alias_ joined perl6
12:38 ofer1 joined perl6
12:48 * avar fixed a bunch of smartlinks the other day, boring
12:48 avar perlDreamer++
12:48 avar the real solution of course is to add it to make test and have it yell at people when they fuck it up:)
12:54 wilx left perl6
12:55 dmq joined perl6
12:56 * dmq waves hello
12:59 thseiler left perl6
13:11 buetow joined perl6
13:19 agentzh joined perl6
13:20 agentzh avar: yeah, i know that feeling. ;-) and that was exactly why i didn't fix many smartlinks myself in the summer. :)
13:22 agentzh sleep &
13:23 Alias_ And Happy New Year one and all
13:23 agentzh happy new year!
13:24 agentzh 21:23 here. :)
13:24 agentzh just a few hours to go.
13:24 Alias_ 2007 is looking good so far
13:24 dmq happy new year upside down one.
13:24 agentzh hopefully we'll have a perl 6 alpha in 2007. :)
13:25 Alias_ We do!
13:25 Alias_ It's awesome!
13:25 Alias_ :)
13:26 agentzh hah!
13:26 agentzh Zzz &
13:33 avar the official perl6 isn't doing that well
13:34 wolverian there's an official perl? :)
13:34 wolverian s,perl,perl6,
13:34 Alias_ There is?
13:35 luqui joined perl6
13:35 avar parrot/languages/perl6
13:35 * Alias_ takes a last swig from the Champagne bottle and heads to bed
13:35 avar t/w 4
13:48 diakopter joined perl6
13:50 diakopter agentzh: did you see why several of the smartlinks were broken (utf8 nbsp in the Snn)?
13:51 diakopter oh, you're Zzz'ing.
13:55 b_jonas joined perl6
14:12 riffraff joined perl6
14:12 riffraff hi
14:18 diakopter hi
14:37 svnbot6 r14968 | tumulus++ | Fixing autovivification tests: extracting a value from a non-existent
14:37 svnbot6 r14968 | tumulus++ | array/hash element should not autovivify.
14:37 larsen_ joined perl6
14:38 weinig is now known as weinig|bbl
14:49 foo\ joined perl6
14:50 riffraff mh.. is it normal that I can't load Test.pm due to '    Unexpected "Str"
14:50 riffraff    expecting "\\", ":", "*", parameter name or ")"' ?
14:52 riffraff it seem that Str +\$foo causes problems
14:55 svnbot6 r14969 | tumulus++ | More hash/array autovivification tests.
15:08 gaal riffraff: you once did 'make install' and have an old Test.pm in your @INC
15:09 gaal hunt it, kill it, try again
15:18 bonsai joined perl6
15:28 drbean left perl6
15:41 hugues23 joined perl6
15:55 kanru joined perl6
16:09 weinig|bbl is now known as weinig
16:09 Daveman joined perl6
16:14 Southen joined perl6
17:01 weinig is now known as weinig|bbl
17:20 kanru joined perl6
17:25 svnbot6 r14971 | kudra++ | Anticipation
17:36 LCamel_ joined perl6
17:54 weinig|bbl is now known as weinig
17:58 Alchemy joined perl6
18:03 dmq joined perl6
18:04 prism joined perl6
18:06 demq joined perl6
18:27 kanru joined perl6
18:55 TubaChuck left perl6
19:14 svnbot6 r14972 | kudra++ | Last summary of the year
19:15 Alias_ kudra: A bit late, we're already into next year :)
19:15 Alias_ YOU'RE LIVING IN THE PAST! :)
19:16 allbery_b heh
19:17 Alias_ Of course, it's really cooler than that
19:17 svnbot6 r14973 | kudra++ | Added in a new year's message
19:17 Alias_ Because she's managed to post a superposition of both the first and last summary of the year
19:17 Alias_ That doesn't collapse into EITHER the first or last post until it is observed
19:17 Alias_ :)
19:18 qmole now that's clever
19:19 Alias_ Indeed, I'm feeling awfully clever at the moment
19:20 Alias_ There's only one thing to do at a time like this
19:20 Alias_ Strut!
19:20 allbery_b .oO { drink? }
19:20 qmole drink then strut
19:20 Alias_ indeed
19:20 Alias_ (cues stayin' alive music)
19:26 b_jonas joined perl6
19:54 Nei left perl6
20:13 weinig is now known as weinig|bbl
21:41 Aankhen`` joined perl6
21:47 weinig|bbl is now known as weinig
22:10 neonse joined perl6
22:38 ayrnieu joined perl6
22:43 b_jonas joined perl6
22:47 prism depending on your time zone: Happy New Year (its 11pm while I am likely I wont be able to type in 1 hour ;))
22:48 Alias_ :)
22:48 Alias_ Hello from breakfast tomorrow!
22:51 allbery_b hello from dinner yesterday :p
22:55 devogon joined perl6
23:11 wilx joined perl6
23:22 Psyche^ joined perl6
23:31 penk joined perl6
23:35 penk joined perl6
23:39 wilx joined perl6
23:39 Psyche^ is now known as Patterner
23:42 penk joined perl6
23:48 mako132 joined perl6
23:50 neonse left perl6
23:56 wilx joined perl6