svn switch --relocate svn.openfoundry.org/pugs svn.pugscode.org/pugs/ | run.pugscode.org | spec.pugscode.org | paste: sial.org/pbot/perl6 | pugs.blogs.com
Set by avar on 16 November 2006.
TimToady luqui: I've been thinking a lot about Num semantics lately for some reason. :) 00:01
luqui :-) 00:02
TimToady there are various approaches we could take
I think we should generally steer the naive user away from having to think about Rats. 00:03
but that doesn't mean we can't have the available
either lexically 00:04
or possibly Num semantics do "lazy division".
much like Int semantics are "better" than int semantics, we could leave num semantics as bare floaters and make Num a little smarter.
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.
luqui but you want eg. sum to be polymorphic 00:06
and still use +
TimToady most things just work "right" with MMD, but division wants to kinda be special
and **$fraction etc. 00:07
luqui (that one has to be approximate, unless we implement algebraic numbers :-/ )
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
yes
luqui I don't think the lexical pragma should control what / means
TimToady I agree, I'm just wondering if it buys us anything to defer 1/3 division
till we really need the floater.
luqui I think, if it exists, it should control whether numbers without decimals are treated as rats or nums
hmm
wait, that doens't work
because we still want Int (do we?) 00:09
TimToady I think people think they want Int whether it turns out they do or not... 00:10
svnbot6 r14961 | perlDreamer++ | adding smartlinks to operator tests
luqui there's always the haskell route: use a different operator for exact division 00:11
or construction of rationals...
svnbot6 r14962 | perlDreamer++ | These splat tests are no-ops. | and * only work with Capture objects.
luqui that is
TimToady I think Num can choose any internal representation it wants for a given number
idiv fdiv rdif
luqui I don't know about haskell's route there 00:12
I do know that I like that they have a separate operator for integer division
because it's useful, but it is surely different than division
TimToady if we went the pragmatic route then lexically infix:</> ::= infix:<rdiv> for instance. 00:13
and then it make Rats.
luqui but rdiv on floats would still result in a float?
TimToady and Rats presumable dispatch differently
bly
er 00:14
I mean "my infix:</> (Int, Int) { rdiv }" actually
Num/Num would presumably still call fdiv, or ndiv, or whatever we call it. 00:15
luqui hm...
TimToady long form should probably be intdiv, numdiv, ratdiv for clarity
00:15 Psyche^ is now known as Patterner
TimToady make that "my multi infix:</>" 00:16
so it still MMDs correctly to nonInt
svnbot6 r14963 | diakopter++ | fixing bad smartlink for goto.t
perlDreamer karma diakopter
jabbot perlDreamer: diakopter has karma of 2
perlDreamer karma perlDreamer
jabbot perlDreamer: perlDreamer has karma of 16
TimToady would have to think about Int/Num Num/Int etc oto
too even
diakopter perlDreamer++ for querying my karma
TimToady and other operators like **
luqui TimToady, I think of Nums as numbers that have some sort of error in them 00:17
so I think Num sucks up more precise forms into itself
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?
no 64 bit int is large enough to handle 1e300...
TimToady but potentially with loss when using 64-bit float
I think we need to think about it from the use case end--who wants which guarantees? 00:19
a lot of people just want fast and "accurate enough"
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
TimToady a lot of other folks want "as accurate as possible" and don't care very much how fast.
luqui dduncan, at runtime? really?
I suppose they do
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
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
luqui dduncan, oh, of course
I don't see the win
00:22 Tene joined
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 ...
luqui they are accurate up to 64 bits..
dduncan eg, you parameterize a generic numerical type to indicate what the maximum accuracy you care about is ...
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
dduncan and if it is too big, we get bigint or something that auto-switches
luqui I think we best worry about when to do things exactly, and when not to
TimToady default should be "not exact" like Perl 5 00:24
luqui agreed
TimToady but Int gives us infinite precision anyway, unlike P5
luqui I'm inclined to say that we should just have a rational constructor
but that is tricky, because Int/Int is allowed
so... maybe not
luqui knows he's a nerd because he's talking about this instead of getting ready for his date 00:25
I'd better go :-)
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
luqui &
dduncan portability is good after all
TimToady yes, to both of you. :)
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
still, we'll see how that actually works out in practice once implemented ... 00:29
TimToady sort of the Ada approach.
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 ...
TimToady in Ada you say "I want something 0..1_000_000" and let it worry about the representation
dduncan okay 00:30
I've never used Ada
as far as all that goes, integers are the easy part ... making this work with non-integers is more tricky to specify
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
eg, when implementing the DBMS over Perl
and the underlying will just handle its own scaling 00:32
00:32 Daveman joined
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
not all problems have to be solved before any are functional
svnbot6 r14965 | perlDreamer++ | remove pod comments for tests that are now passing and add smartlink
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
00:35 weinig|bbl is now known as weinig
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
finite can be derived from infinite in a way similar to Perl 6's subset of Int where 1..100 or something
TimToady which is more or less the Ada approach in disguise. 00:37
dduncan I see
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
TimToady Ada has the concept of "universal integer" which is your infinite integer
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.
anyway P6 Int is "universal integer" 00:39
dduncan yes
TimToady not sure whether it makes sense to let Num be an infinite type though.
part of why I was wondering about whether a Num could decide to be a Rat inside.
at least up to a point. 00:40
dduncan yes, Num is more complicated
and has at least 3 popular representations that I know about
TimToady it might make it easy to do lossless scaled arithmetic on money, for instance.
dduncan floating point, rational (2 integers), and as strings of digits
afaik, Python or Ruby does nums as rational 00:41
TimToady Rexx used exact decimal arithmetic
so "string of digits" approach
so I wonder how polymorphic/generic Num can be in a given lexical scope. 00:42
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?
dduncan and afaik, Perl 5's BigNum or BigRat is parameterized
00:43 neonse left
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.
dduncan if unparameterized, I suppose it could be dynamic, but the question is when to switch
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.
dduncan I can't yet say
TimToady well, arguably floaters punt all the time on / and * 00:46
and on +/- when the numbers are ~15 digit precision or so.
if there is a pragmatic lexically-scoped solution, I wonder how many knobs it has. 00:47
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
dduncan one knob should be sufficient with integers, but with nums, I would have 2-4 or so
TimToady I don't know for sure, but I suspect Mathematica does some of that.
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"
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...
dduncan which is loosely like "precision and scale" of some systems
but is agnostic to the base of the number system
and of course, zero is supported in addition to the minimum, which isn't zero
eg, if a user says I want to support as large as 10**30 with precision as little as 10**-10 ... 00:51
then a representation could be used that has around 40 digits of accuracy
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. :)
dduncan since the spec counts in actual boundary values of a sort, rather than count of digits etc
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!
dduncan anyway, the abovementioned is how I'm currently approaching parameterizing a Num on my system 00:54
or intending to ... that represents 2 knobs for a Num anyway
TimToady the mere mortal just wants it to be a Num, and run fast, and don't bug me about it. 00:55
so probably different kinds of Num have to be taught to interoperate as seamlessly as possible.
probably MMD gets us most of that, with enough definitions for conversion functions. 00:56
though perhaps we might distinguish lossless from lossy conversions and make the latter a little harder to get.
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
now ...
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:58
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
TimToady this has been attempted in the past, with notable lack of long-term success.
people would usually rather have a fast answer and just guess about whether it's accurate. 01:00
so they stick with floaters, and external analysis.
(or more frequently, non-analysis :/ )
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:01
TimToady as long as you stick to integer arithmetic on the Int type, yes. 01:02
and ** get problematic though
er, / and **
dduncan but presumably ** will have a multi, where one takes just integers, and the other nums
er ...
though a negative integral exponent won't be an int
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
as for / , I would say have 2 division operators
users specify behaviour they want by which one they use 01:04
01:04 AtomicStack joined
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:04
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
TimToady dduncan: that is not what the naive user would expect.
theorbtwo dduncan: 2/3 being 0 wouldn't be least surprise.
dduncan well then ...
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
theorbtwo Is int($a/$b) too longwinded/nonoptimizable?
dduncan I wouldn't do that 01:07
I would say either $a idiv $b or $a ndiv $b ... rename ops to something better
theorbtwo Too bad integer doesn't have a nice type indicator like ~.
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)
dduncan yes
theorbtwo Mm, g'point.
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
theorbtwo Well, the point most of the time, I think, is optimizability, and that means the rule has to be truncate first.
dduncan sure, whatever, they are just turned into ints first
theorbtwo a ./ b ? Is that too misparsable as concat followed by regex? 01:10
TimToady . isn't concat in P6
theorbtwo Hm, or as a decimal point after a, for that matter.
d'oh.
s/concat/method call/, then.
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:11
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.
TimToady I think pugs already supports a bunch of them.
dduncan though one op can be picked as a default
a documented default
TimToady a lexically scoped pragmatically selected default.
dduncan sure
TimToady just wondering if / is the same.
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
but it would default to something 01:14
theorbtwo Promoting the int to a num, I should think.
TimToady I think the minimum convertibility between any two types has to be guaranteed to be with at least the precision of floating point.
theorbtwo I still don't think we really care what the types of the args are for /, though.
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.
TimToady and two given types can negotiate greater precision of conversion if they like via MMD
dduncan so how is modulus spelled in Perl 6 again? "%" or "mod" or something else ? 01:16
if it is "mod", then "div" would be a perfect complement for integer division, leaving "/" for num
TimToady I think we could be rather more regular about this
dduncan since modulus makes no sense with non-integers 01:17
TimToady make / and % default the default to ndiv and nmod
dduncan: yes it does.
theorbtwo ...and make the stringy versions be div and mod?
dduncan well I suppose if the modulus doesn't have to be an integer, then yes
TimToady but also have idiv and imod, rdiv and rmod, etc. 01:18
theorbtwo Er, make the stringy versions be idiv.
dduncan for some reason I thought mod always applied to integers, but I suppose it doesn't have to
theorbtwo Er, if i* truncates, shouldn't it be t*?
(Assuming r* is round.)
TimToady r is rational
Int/Num/Rat 01:19
theorbtwo Oh, that's more sensical.
TimToady and maybe D for Dec
theorbtwo If int/int -> rat and rat/rat -> rat as well, then it sounds wonderful.
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.
TimToady int/int -> rat would not be the default default, but could be selected if we make / mappable to one of the others.
theorbtwo (As in (a*pi+b)/(c*pi+d).)
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?
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.
not sure if that's well defined though.
theorbtwo Hm, should be reasonable well defined... though not if you want near-exact repeatability in all/most cases, though... 01:22
Er, right. That sentence contains so much faffing about as to be more or less meaningless.
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.
I think in practice / is where almost all the decisions are made on which type to return. 01:23
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:25
(because / really wants to use a more exact representation when possible, but trig functions make it impossible) 01:26
TimToady RealFrac being floating point?
allbery_b RealFrac incorporates both Real (for trig) and Fractional (for division) 01:27
TimToady wait, you just said that.
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).
TimToady okay, what I've been arguing for is that Num be something like RealFrac then.
allbery_b sorry, RealFLoat. I started out with RealFrac 01:28
Floating for /, Real for sin()/cos()
TimToady what's the difference?
being more familiar with Fortran where real is floating
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
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?
eg, when $a and $b are 2 imprecise numbers, how is $a == $b determined? 01:29
TimToady P5 just punts that to the user.
allbery_b lemme see if I can find it again, I've already forgotten the fine distinctions :/
TimToady Ada has a huge section on it.
ingy merry merry 01:30
dduncan with integers it is trivial, with nums we should have something workable ...
TimToady ingy: we're almost to happy happy now.
ingy noted noted
dduncan perhaps multiple numeric equality operators ... or lexical pragmas ... are useful here
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 ...
allbery_b and RealFloat is atan2
dduncan or there is some fuzzy variance range ...
allbery_b RealFrac was sufficient to get both trig and / until I needed atan2...
TimToady the latter is the Ada approach.
dduncan where numbers within a certain value of each other are declared equal
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
TimToady quick answer: miniperl6
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
that said, in real life ...
ingy TimToady: is that the name of an executable?
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
TimToady see v6/v6-MiniPerl6 01:34
ingy ok
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
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.
TimToady Ada had a very complicated answer to that that basically boils down to "It depends." 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?
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
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
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
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
TimToady if you want to parameterize the test, use an eqv variant.
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
of course, floating point is a common extension which then breaks the rules
dduncan that's a thought
and I was trying to make my system agnostic to whether numbers were floating point or not 01:39
but thanks for the rationale
theorbtwo ...unless mmd says otherwise, presumably.
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
allbery_b unconstrained FP is forbidden si equality istestable
*so
TimToady floating point is like the basic rules of diplomacy. any two countries are free to negotiate better or worse relationships...
ingy my checkout don't have v6/v6-MiniPerl6, I must be way out of date
upping slooooowly 01:42
TimToady well, yes, considering that mp6 has been the main push for the last couple of months...
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... :/
TimToady I wouldn't worry about that too much; the test suite is what is supposed to guarantee eventual convergence. 01:44
and mp6 is really only going to replace the current Haskell compiler in lambdaland.
anything in the runtime is likely to be useful for a goodly long time yet. 01:45
after all, the specs merely say that the parser for Perl 6 has to be written in Perl 6, not the run-time.
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
did I forget to commit it or did it get reverted?
TimToady dunno, svn should be able to tell you.
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)
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
because if that code vanished they're based on the unix epoch instead of the perl epoch
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
allbery_b huh. no, the code is correct, the comment is obsolete 01:50
TimToady Alaska or Southwest are usually the cheapest.
dduncan eg, can I get it for under $500 each way, or am I looking much higher?
TimToady but nothing is terribly cheap these days, what with fuel prices...
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?
TimToady just OSCONs
have always flown to YAPCs 01:52
dduncan I see
TimToady also tend to fly to EuroOSCON for some reason... :)
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
for strange reasons
TimToady probably
dduncan either way, Seattle is a ferry trip away if I need to go that way
theorbtwo Hm, wouldn't have thought it'd make much difference CA/US, but shrug. 01:54
You'd probably know much better then I would.
01:55 Aankh|Clone joined
ingy TimToady: wanna kayak to Tokyo this spring? 01:55
dduncan: where do you live?
dduncan I live a half-hour drive out of Victoria BC
if you visit the Buchard Gardens or something else around here, you're real close 01:56
what about you?
ingy Tofino?
TimToady currently Southwest will round-trip in April from seattle to austin for about $200
dduncan thanks for the tip
svnbot6 r14967 | allbery_b++ | remove obsolete comment left over from filetime test development
TimToady 329 for fully refundable.
ingy I live in Seattle proper
TimToady not sure which city is YAPC though... 01:57
allbery_b @slap allbery_b
lambdabot why on earth would I slap allbery_b
allbery_b ...because I'm a yutz?
TimToady also, they don't book far enough in advance to see what it would be in June
allbery_b :p
dduncan University of Houston, apparently
that's what www.yapc.org/America/ says
lambdabot Title: YAPC 2007: Yet Another Perl Conference
allbery_b confused himself badly by leaving that comment in place... 01:58
ingy Houston? egads
dduncan still, I've never been to the south-east US before, so it'll be interesting
theorbtwo Texas isn't south-east.
dduncan mainly I've been along the whole west coast of it, and the north-east corner
well, its south-middle 01:59
theorbtwo 1;
dduncan but I haven't been in the middle either
ingy I hate how west coast people say Chicago is East Coast
dduncan what I said before was a slip ... and I consider Chicago, the north middle
ingy Houston is the home of the breast implant
TimToady actually, I'm looking at it wrong, round-trip is minimum of about 300
houston same as austin
dduncan actually, I was in Chicago briefly myself ... was driving through it in 1994 with family 02:00
ingy dduncan: are you near tofino?
theorbtwo The closest I've been to Chicago was YAPC::NA::200... er, 3?
dduncan we had to drive to Ontario in a hurry, and decided that the US interstate was more expedient
just a minute ...
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
ingy canada is hardly crossable afaiac
especially in winter
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.
ingy canada's cross-coutry highway is 36000 feet above sea level
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
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
er, was driven
TimToady you shoulda kayaked across Canada instead.
dduncan I leave that up to others, I'm not really a kayaker
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
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
ingy I <3 Tofino 02:06
dduncan unfortunately, the result url isn't copyable, as it looks like a post request
theorbtwo dduncan: Zoom in, double click close, hit "link to this page".
dduncan one moment ...
sorry, I didn't see that link, but here it is: www.google.ca/maps?f=q&hl=en&am...iwloc=addr 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.)
lambdabot Title: Google Maps, tinyurl.com/yms6nk
buubot xrl.us/t3j4
lambdabot Title: Google Maps
ingy later all.
theorbtwo Wow. You can probably get *really* good planespotting photos. 02:08
dduncan later
theorbtwo G'localtime.
dduncan that's true, actually
02:09 rafl joined
dduncan if you pick the second-to-closest zoom level, you can see my house, car, and various greenhouses quite clearly 02:09
02:12 buetow joined 02:22 Aankh|Clone is now known as Aankhen`` 02:30 thseiler joined 02:52 dduncan left
meppl gute nacht 02:55
03:03 dolmans joined 03:07 mr_ank joined 03:14 vel joined 03:29 thestarslookdown joined
allbery_b sighs --- of course deketing that one comment causes nearly everything to be rebuilt :( 04:49
^k^l
05:15 baest joined 05:30 Aankhen`` joined 05:46 TubaChuck joined 05:48 luqui joined 05:53 Schwern joined 06:21 pstickne joined 07:05 lambdabot joined 07:30 luqui joined
avar I like Pugs's Test.pm a lot better than Test::More 07:46
07:49 wilx joined
gaal where would we be if we didn't build on past experience 07:56
08:00 Belaf joined
Khisanth gaal: the same place we were before! 08:12
dolmans no, there is no before, so nowhere indeed. 08:20
gaal you can never throw out the same baby twice with the same bathwater, etc. 08:42
09:24 polettix joined 09:27 luqui joined 09:43 Schwern joined 09:54 bernhard joined 10:25 elmex joined 10:32 lambdabot joined 10:52 b_jonas joined 11:02 devogon joined 11:09 thseiler joined 11:32 iblechbot joined, lambdabot joined 11:33 chris2 joined
b_jonas checking the url hortening: maps.google.com/maps?hl=en&q=sa...k&om=1 11:35
lambdabot Title: Google Maps, tinyurl.com/yj74x5
allbery_b lambdabot was "recently" modified to only shorten urls above some particular length, fwiw 11:36
b_jonas I was trying the interaction between buubot and lambdabot really 11:37
allbery_b ah. I'd been wondering about that myself 11:38
(since they both listen to leading "?")
b_jonas I don't think buubot listens to leading "?". buu? 11:44
allbery_b not buubot, actually. evalbot
b_jonas oh 11:45
ok
allbery_b is a little fuzzy; insomnia
tired but can't sleep for some reason
(likely the same reason the cats are bouncing off the walls and swinging from the chandeliers...)
buu buubot was just bugged 11:47
I have absolutely no idea why. 11:48
12:03 agentzh joined
agentzh xinming: socks proxy is needed for irc traffic, i think. i'm paying for the socks server that i'm currently using. :) 12:06
perlDreamer++ # for fixing smartlinks 12:07
perlDreamer: the cron on feather told me 2 min ago that "486 smartlinks found and 2 broken." :) 12:08
12:17 thseiler joined 12:20 Alias_ joined 12:38 ofer1 joined
avar fixed a bunch of smartlinks the other day, boring 12:48
perlDreamer++
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 12:55 dmq joined
dmq waves hello 12:56
12:59 thseiler left 13:11 buetow joined 13:19 agentzh joined
agentzh avar: yeah, i know that feeling. ;-) and that was exactly why i didn't fix many smartlinks myself in the summer. :) 13:20
sleep & 13:22
Alias_ Already?
And Happy New Year one and all 13:23
agentzh happy new year!
21:23 here. :) 13:24
just a few hours to go.
Alias_ 2007 is looking good so far
dmq happy new year upside down one.
agentzh hopefully we'll have a perl 6 alpha in 2007. :)
Alias_ We do! 13:25
It's awesome!
:)
agentzh hah! 13:26
Zzz &
avar the official perl6 isn't doing that well 13:33
wolverian there's an official perl? :) 13:34
s,perl,perl6,
Alias_ There is?
13:35 luqui joined
avar parrot/languages/perl6 13:35
Alias_ takes a last swig from the Champagne bottle and heads to bed
avar t/w 4
13:48 diakopter joined
diakopter agentzh: did you see why several of the smartlinks were broken (utf8 nbsp in the Snn)? 13:50
oh, you're Zzz'ing. 13:51
13:55 b_jonas joined 14:12 riffraff joined
riffraff hi 14:12
diakopter hi 14:18
svnbot6 r14968 | tumulus++ | Fixing autovivification tests: extracting a value from a non-existent 14:37
r14968 | tumulus++ | array/hash element should not autovivify.
14:37 larsen_ joined 14:38 weinig is now known as weinig|bbl 14:49 foo\ joined
riffraff mh.. is it normal that I can't load Test.pm due to ' Unexpected "Str" 14:50
expecting "\\", ":", "*", parameter name or ")"' ?
it seem that Str +$foo causes problems 14:52
svnbot6 r14969 | tumulus++ | More hash/array autovivification tests. 14:55
gaal riffraff: you once did 'make install' and have an old Test.pm in your @INC 15:08
hunt it, kill it, try again 15:09
15:18 bonsai joined 15:28 drbean left 15:41 hugues23 joined 15:55 kanru joined 16:09 weinig|bbl is now known as weinig, Daveman joined 16:14 Southen joined 17:01 weinig is now known as weinig|bbl
svnbot6 r14970 | kudra++ | Added a reminder about thread_uri syntax 17:07
17:20 kanru joined
svnbot6 r14971 | kudra++ | Anticipation 17:25
17:36 LCamel_ joined 17:54 weinig|bbl is now known as weinig 17:58 Alchemy joined 18:03 dmq joined 18:04 prism joined 18:06 demq joined 18:27 kanru joined 18:55 TubaChuck left
svnbot6 r14972 | kudra++ | Last summary of the year 19:14
Alias_ kudra: A bit late, we're already into next year :) 19:15
YOU'RE LIVING IN THE PAST! :)
allbery_b heh 19:16
Alias_ Of course, it's really cooler than that 19:17
svnbot6 r14973 | kudra++ | Added in a new year's message
Alias_ Because she's managed to post a superposition of both the first and last summary of the year
That doesn't collapse into EITHER the first or last post until it is observed
:)
qmole now that's clever 19:18
Alias_ Indeed, I'm feeling awfully clever at the moment 19:19
There's only one thing to do at a time like this 19:20
Strut!
allbery_b .oO { drink? }
qmole drink then strut
Alias_ indeed
(cues stayin' alive music)
19:26 b_jonas joined 19:54 Nei left 20:13 weinig is now known as weinig|bbl 21:41 Aankhen`` joined 21:47 weinig|bbl is now known as weinig 22:10 neonse joined 22:38 ayrnieu joined 22:43 b_jonas joined
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:47
Alias_ :) 22:48
Hello from breakfast tomorrow!
allbery_b hello from dinner yesterday :p 22:51
22:55 devogon joined 23:11 wilx joined 23:22 Psyche^ joined 23:31 penk joined 23:35 penk joined 23:39 wilx joined, Psyche^ is now known as Patterner 23:42 penk joined 23:48 mako132 joined 23:50 neonse left 23:56 wilx joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!