-Ofun: xrl.us/hxhk | pugscode.org | pugs.kwiki.org | paste: paste.lisp.org/new/perl6 or sial.org/pbot/perl6
Set by apple-gunkies on 11 November 2005.
luqui Perl is multicultural, which means people come from all sorts of backgrounds 00:00
some people would use hyphens, other underscores
dbrock sure, but it would all mean the same thing
luqui and that's not the kind of thing humans remember easily (did this module use a hyphen or an underscore?)
dbrock people indent differently too
luqui oh, you're proposing that _ and - are interchangable?
dbrock that's exactly what I'm proposing
luqui sub foo-bar ($x) { say $x } foo_bar(42); # says 42 00:01
dbrock right
luqui okay, well, that kills that concern
SamB dbrock: I hope you don't propose that foo-bar_baz be allowed!
dbrock SamB: in fact, I do
luqui SamB, why not?
nobody would do it
dbrock I sometimes use _foo-bar-baz myself
SamB luqui: you have a point there 00:02
dbrock (where the leading underscore usually means "internal" or something like that)
luqui dbrock, well, as far as I can tell, the proposal seems harmless
but it's a taste issue, so you'll come up against a lot of opposition
dbrock great, thanks for being open-minded :-) 00:03
luqui also we probably wouldn't allow - to be the first character in the identifier
dbrock that sounds sensible
luqui because people like to crunch their unaries up against their names
dduncan personally I think that no characters in ids should be substitutable for others
if you're going to go that route, then you might as well make A = a as well
luqui dduncan, that is another point. canonicalization is a pain
dbrock Lisps have been case-insensitive for, like, ever 00:04
luqui Larry says "Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in"
dduncan lots of languages are case sensitive, and being case sensitive is more expressive
luqui so you probably won't get anywhere arguing that Lisp did something syntactically
dduncan SQL gives you a choice of being sensitive or insensitive
bareword identifiers in SQL are insensitive, delimited identifiers are sensitive 00:05
if you want to compare one of each type, then an insensitive matches as an uppercase sensitive
luqui dduncan, but do you also think that we shouldn't have more than one way to print something to the screen? 00:06
dduncan I don't want perl to be case insensitive for identifiers, by default
luqui dduncan, you seem to have a lot of opinions. please back them up :-) 00:07
dduncan being able to print is a matter of a choice of what function you call ...
not whether pr_int is interpreted as pr-int or vice versa
its a separate issue
I don't like two different characters automatically being equivalent 00:08
luqui dduncan, but you also have the choice of saying $foo.meth(arg) or meth $foo: arg
dduncan not the same thing
luqui how so? they may feel different to you, but I really can't see much different
dduncan if I declare my_func(), I don't want someone saying my-func() to result in that one's invocation 00:09
luqui the latter form was introduced to help readability. maybe in some situations hyphens are more readable than underscores
(for instance, I loathe writing BNFs with underscores)
dduncan if the - is accepted, it should be a different function name
luqui dduncan, that has many more problems
dduncan as I recall, BNFs use dashes
luqui exactly
but perl 6 has rules
and you have to use underscores in those :-)
dduncan but BNFs also have delimited identifiers 00:10
eg,
<foo> ::= <bar-thing> BAZ
identifiers have the <>
luqui so do perl 6 rules
but you can't use - because it's an identifier
you can say rule foo {...} and refer to &foo
dduncan I should point out that people generally use underscores in place of "spaces" 00:11
dashes likewise
they are word separators, when whitespace isn't allowed inside an identifier 00:12
luqui yeah
anyway, I think it's a bikeshed issue 00:13
dduncan so if we're going to allow underscore and dash to be interchangeable, then the collection should be conceptually a space
kind of like how several whitespace chars are conceptually a \n
luqui dduncan, yeah
I think that's what dbrock is arguing for 00:14
dduncan if we don't think of those as spaces, then simply dash for underscore seems to arbitrary to be accepted
dbrock dduncan: in natural language, hyphens join words; identifiers are joined words
luqui and it makes sense that they should be interchangable
dduncan so maybe have a substitutable character class called word-joiner, which includes, dash, underscore, etc
luqui because nobody seems to know how to use hyphens correctly 00:15
stevan luqui: ping
luqui did you really need to ping me?
stevan yes :)
luqui: so I have been reading about SML Functors, which is makeing theory.pod seem less insane 00:16
luqui what are SML functors?
stevan and I am pondering some kind of Functor like device for the core Object Space stuff
Standard ML
luqui right, I don't know SML
stevan hmm...
stevan looks to see if he can find a link
they are basically the basis of SML's module system,... which is quite nice and very powerful 00:17
luqui ack 00:18
dduncan what causes all that, exactly? 00:19
all the mass leave and join
luqui maybe freenode is moving us around
dduncan not all of us ... I wasn't told that I left and rejoined the room 00:20
dbrock hmm, I didn't notice anything 00:22
I guess my IRC client "conveniently" hides that stuff
did you get the last two messages I adressed to you, dduncan?
dduncan dbrock, my list says you were one of those 20-30 who left and rejoined
dbrock okay 00:23
dduncan: in natural language, hyphens join words; identifiers are joined words
dduncan: do you think of "foo_bar" as "foo followed by underscore followed by bar", or do you just think of it as "foo followed by bar" and infer from context (Perl culture) that underscore is used to separate them
dduncan not that that should matter
stevan_ luqui: sorry,... had to tuck the kids in
luqui: SML's module system is basicall 3 components... signatures, structures and functors 00:24
dduncan dbrock, as I wrote earlier, I consider both _ and - to both be word separators ... humans would use spaces
stevan_ signature are just that,.. signatures
structures are basically a grouping of functions, datatypes, etc
dduncan dbrock, see 13 mins ago, where I said that 00:25
stevan_ and functors (and I am still grokking them,... so I may be a little off here) are parametric structures
luqui ahh
stevan_ they are very similar to your theory/model/etc
luqui theory.pod is really modeled after Haskell's type classes, with more dynamism built in, but maybe we use ML's functors as an extension of parameterization to modules
dduncan anyway, I've said what I wanted to on that subject
dbrock dduncan: that's what I replied to 00:26
so since you consider both of them to be word separators, doesn't it make sense for them to be synonymous? 00:27
dduncan that's what I think they are conceptually, but I don't necessarily think Perl should consider them the same ... 00:28
as I said, bring this matter up on p6l and see what they say
stevan_ luqui: so if you have a moment I would like to discuss how I see these functors, theories and roles fitting together 00:29
luqui sure
dduncan dbrock, suffice it to say that I'm willing to accept this change if @Larry endorse it, but I don't plan to propose it to them myself
luqui I might be a bit laggy, as I'm pugs hacking too
dbrock dduncan: I'm writing the post as we speak
stevan_ luqui: ok 00:30
dduncan attaboy
dbrock dduncan: okay, that's great
stevan_ so ,.. the ObjectSpace work has centered around getting a core set of "things" which are needed in order to bootstrap the metamodel
dduncan strictly by myself, I'm on the fence on the issue
stevan_ it basically works, the only issue is that these core "things" are not meant for "userland" 00:31
luqui mmk
stevan_ and the metamodel expects these "things" in it's method parameters and returns them from said methods as well
my initial thought was to wrap the metamodel post-bootstrap using Roles 00:32
the Roles would then handle all the boxing/unboxing needed
but this feels ugly
the next idea (which is actually robkinyon's idea) was to have two signatures,.. one for bootstrapping, the other for userland,.. and boxing/unboxing would probably be assumed to "just work" 00:33
This felt like more work than I wanted to undertake 00:34
luqui hmm
the role thing sounds very right to me, actually, but go on
stevan_ so my last thought.. is the Functors
if I wrap all the core "things" in some kind of module signatures/functors, then I can program "to the interface" rather than the implementation 00:35
luqui how is that different from roles? 00:36
stevan_ then we would provide some kind of "bridge" between the functors/signatures and Roles
they are not all that different actually
the key is to find a clean way to bridge the gap between core-runtime and userland 00:37
of course,.. all this made me think about theory.pod again,.. hence why I am bugging you :)
00:38 stevan_ is now known as stevan
luqui to me, the native types in the metamodel are the unnamable "classes" of theory.pod 00:39
they do roles, and they have instances, but you can't actually talk about them
stevan yes, but I am talking about one level deeper than that
the primative bit, num, str types which make up the metamodel
luqui yeah
those are the classes
or am I misunderstanding something? 00:40
stevan they are not classes, they are the building blocks which we use to make classes
luqui I don't think we're on the same page 00:41
stevan the unnameable classes thing I see as a language level issue,.. because even if p6 userland can't see them... the runtime must be able to 00:42
luqui hm... the runtime
that's up to the runtime :-)
I was thinking that just because we use num and str to build classes that they can't themselves be classes 00:43
I mean, you could smack a vtable on to them and make them just like any other concrete thing
stevan well I was seeing that as being roles
role Str { ... do things with str primitive ... } 00:44
so the Roles basically function as the Box in "boxed types"
does that make sense? 00:45
luqui hmmm.... sortof, but not really
how can a role be a box
a role just defines the shape of a vtable
if you want to talk implementation level
stevan vtable?
vtables are sooo C++ :P
luqui vtables are soo fast 00:46
compared to string lookup like p5
stevan so how exactly are you viewing the classes?
structurally?
luqui you mean the bootstrappy primitive classes or the language concrete classes? 00:47
you must mean the latter
stevan yeah
luqui an opaque pointer
just some stuff behind a black box
and you can ask it for its role vtables 00:48
and then call the role vtable methods
(in Haskell, the compiler fills in the role vtables)
(so you don't even have to ask; but full type inference is not a luxury we have)
stevan but vtables (IIRC) are really just compiled "caches" for method lookup 00:49
Perl 6 is far to dynamic for this IMHO
we would end up with more code dealing with the cache than it would take to deal with dynamic lookup on demand
luqui don't think of a vtable like that
stevan ok
luqui a vtable is an object that specifies how some opaque thing does a role 00:50
stevan ok
luqui "this method is implemented here, that method is implemented there"
type classes (i.e. theories) provide a nice way to do that for multimethods 00:51
stevan so all "classes" are an opaque pointer with an attached vtable which itself is just a set of pointers to functions somewhere
luqui er, not quite
so, when I say Foo{^T} # pretend ^T is some concrete type that we weren't allowed to name
I'm asking the compiler whether Foo is instantiated for ^T 00:52
stevan ok
luqui if the answer is no, then there's a type error (you can think of this stuff happening at runtime, too, though)
but if the answer is yes, it's not just a plain old yes
the answer is the vtable for *how* ^T does Foo 00:53
So there is a vtable for every (type,role) pair, as long as the type does the role
at least conceptually...
er, semiconceptually...
stevan does the vtable have implementation? or just the signature?
luqui the vtable is precisely the implementation 00:54
stevan ok
luqui (or it points to the implementation somewhere else)
stevan I am not sure this is a good basis for the metamodel
luqui possibly not
hmm...
stevan it sounds a lot like Java/C++ etc, which are not known for their flexibility/extensibility
luqui well, this doesn't preclude looking up methods by name 00:55
stevan and makes classes and roles into "things" which the runtime needs to supply
luqui stevan, uh, didn't it have to do that anyway?
stevan nope :)
luqui or do you mean that the metamodel should provide them instead?
stevan the metamodel only needs a basic opaque type 00:56
which has a pointer to it's "parent" (or class if you like), and room to hold some data
luqui so this could be the opaque pointer... 00:57
stevan that,.. along with a very basic sendmsg primative and you can build Classes and roles from it
yes, it could
but classes are just another instance
of Class
they are not anything special
luqui well, perhaps the vtable view is still too high-level 00:58
stevan the same building blocks could be used to build any metamodel (prototype if you like)
luqui I don't think anything is saying that the vtable couldn't be implemented by some lower-level machinery within the metamodel
stevan oh, it is implemented in the metamodel,.. but it is not attached to the opaque type (at least not as directly as I think you were talking about)
but actually ....hmmm 00:59
if we look at your vtables as being the "module signatures" I was talking about
this all fits together
luqui side note, do you know how to force rebuilding of the precompiled prelude? 01:00
without recompiling the rest of pugs?
stevan no idea,.. but i suspect make clean would do it
luqui yeah, that kills the latter goal :-)
stevan or delete the compiled code (if it exists seperately)
the vtables/module-signatures could be a primitive form of Roles 01:01
and if we apply them to the metamodel "things" as well as the core "things" as well, hmmm 01:03
luqui could you try to explain a module signature again? 01:04
stevan ok,.. a function has a signature,.. its parameters (and their types) and its return value (and it's type) 01:05
a module signature is basically like that, but for modules 01:06
so the module has the following functions in it, and here are thier signatures
then there is some mechanism by which the signature "hides" the implementation
think about downcasting in Java 01:07
luqui downcasting?
stevan or upcasting I forget which
luqui has so little Java experience... he is so proud
stevan :D
ok,.. in java,.. you have a collection,. it returns items,.. those items are types as Object cause Java sucks 01:08
so you need to cast those Objects into the things you want them to be
sometimes though it make sense to cast them into an interface instead,.. so you end up programming just to the interface, and not to the actual concrete impl
luqui ahh. that sounds like "downcasting" is the right word
stevan ok 01:09
so,.. think of that in a non-OO sense
luqui yeah, that makes sense
and actually, that is the basis for allomorphism, and it is a principle I hold quite dearly
stevan :) 01:10
luqui I don't think it should be possible to hard-code a particular implementation
stevan you and chromatic both
me either
my other motivation for this is to be able to easily swap out runtimes like PyPy does
so have the FlowObjectSpace , etc etc
if I wrap all my primitive "things" into these signatures/interfaces/whatever then I program "to" them,.. and not the impl 01:11
make sense?
luqui yep 01:12
stevan good :)
does this fit closer to what you talking about in theory.pod?
luqui I think so 01:13
stevan I think the main difference is that I am not talking about multis here
luqui I think we've been basically thinking the same thing all along, but just talking circles around it
stevan of course :)
luqui are you talking methods?
stevan you say theory, I say functor,...
I am not sure exactly what I am talking about re: multis & methods 01:14
you say model and I say modal
luqui :-)
stevan to-may-toe, to-mah-to
etc etc etc
luqui I say toe-mah-two
stevan stops singing old jazz standards 01:15
luqui starts
damn you!
stevan LOL
ok,.. you be Ella and i will be Louis 01:16
luqui incidentally, I'm listening to Ella atm
stevan is listening to really great Joy Division bootleg,.. which doesn't match well with Ella/Louie really :) 01:17
Ella++ though :)
ok,.. so I will mess around with this module sig thing and see what I get 01:18
then maybe we can shoehorn it into the theory.pod ideas
or vise versa
in the meantime I suggest you read up on ML's module system.. it may be very enlightening
stevan digs for a good link for luqui 01:19
01:19 Lopo_ is now known as Lopo
luqui will 01:19
luqui has been meaning to learn ML/OCaml for a while
stevan has always loved ML even though he has never programmed anything in it :)
luqui it should be fairly easy to learn now that I'm comfortable with haskell 01:20
stevan yes, Haskell "comes from" ML IIRC
luqui it is about as related to ML as Perl is to C 01:21
stevan yeah
on the same side though
luqui Perl and C are fairly related...
stevan the more dynamic side being LISP/Scheme, and the "typed" side being ML, Haskell, etc
luqui ahh, in that respect Perl isn't that close to C 01:22
stevan luqui: www.diku.dk/users/tofte/publ/oregon/ 01:23
luqui *click*
stevan grab the ps
luqui what's with the circumflex on "secondary ro^le" 01:26
stevan ? 01:27
luqui on the first page
stevan no idea 01:28
bad typesetting maybe
this is not bad,.. very high level and doesnt cover functors -> www.dcs.ed.ac.uk/home/stg/NOTES/node95.html 01:29
luqui ?eval multi sub foo ($x) { say "one" } multi sub foo ($x, $y) { say "two" } foo(3); foo(3,4); 01:34
justatheory shoehorns steven.pod
01:34 evalbot_7959 is now known as evalbot_7961
evalbot_7961 OUTPUT[one two ] bool::true 01:34
justatheory er,stevan.pod
stevan :)
robkinyon luqui: ping 02:46
luqui robkinyon, pong 02:54
robkinyon mind if I throw a few thoughts onto the fires of the metamodel/theory discussion you just had with stevan? 02:55
luqui yes I mind! Geez, what do you think, we're open minded or something!?
robkinyon stevan didn't explain my thoughts very well (which isn't surprising because I didn't explain them to -him- very well)
LOL
Basically, my idea is that the runtime provides, at a minimum, one primitive - the opaque instance.
luqui we were both having trouble explaining our thoughts
robkinyon This instance provides two messages : get( primitive) -> primitive and set(primitive, primitive) -> primitive 02:56
with the guarantee that set( P, Q ) implies that get(P) -> Q
luqui where primitive is like str or num or something?
robkinyon anything you want
(Literally)
luqui hmm 02:57
okay, go on
robkinyon So, to get the metamodel, you need two other primitives - Block and Signature
Block is a unit of work (a la function/sub/method/etc), plus its associated lexical environment.
Block is a closure
luqui the lexical environment can be simulated, but that's beside the point 02:58
robkinyon Signature provides what it says - a list of types that can be accepted and a list of types that will be returned
luqui or, I guess that would be the runtime's job to simulate it
robkinyon My hands a waving a smidgeon
it's assumed that the runtime can and will provide these items
or, that a wrapper can be written between the metamodel and the runtime to fill in the gaps
(From the metamodel's perspective, the wrapper becomes the runtime) 02:59
So far so good?
luqui I think so
go into a little more detail about "signature", please
that is, according to the runtime, what is a "type"?
robkinyon According to the runtime, a type is a primitive 03:00
So, it's two lists of primitives
You'll see in 3 seconds why it needs to be a primitive
so far so good?
luqui okay 03:01
robkinyon so, we have 3 mandatory primitives - Opaque, Block, and Signature
the runtime can now provide any number of optional primitives (string, int, float, bit, etc)
luqui and Type
robkinyon No - Type is not a primitive
luqui robkinyon: According to the runtime, a type is a primitive
robkinyon Ignore the current runtime 03:02
luqui I was just quoting you, but okay
robkinyon No - the runtime defines "type" to be "any primitive I know about"
sorry - i misspoke.
luqui oh, okay
robkinyon Now, the metamodel continues along its merry way as Stevan has handled it 03:03
attributes are easily handled - opaque.set( name, value ) and opaque.get( name )
luqui what is "name" if you don't have string? 03:04
robkinyon Whatever primitive you want it to be
this model doesn't do much if you don't provide other primitives
it just doesn't specify what other primitives you have to provide
So, if the runtime only provides Int, then all your names and values are Ints
luqui .... oh...kay. remember the goal is to implement perl 6 on top of this
robkinyon Well, the Perl6 runtime will provide String, Int, Float, Bit, List, Hash ... and this model will simply handle them 03:05
The metamodel doesn't need to know about those primitives
(There's a userland on top of the metamodel, which enforces language policy.)
The userland is an important concept to keep in the back of your mind - we'll need it in about 5 minutes 03:06
luqui okay
then continue
robkinyon So, attributes are handled sanely
Methods are also handled sanely - opaque.get( methodname ) retrieves the Block
opaque.get( Block ) retrieves the Signature for that Block
So far so good? 03:07
luqui yep
so opaque is kind of like a generic hash
robkinyon Then, you just invoke the Block with the appropriate Signature and the method call occurs
opaque is whatever the runtime wants it to be, so long as it responds to set(primitive,primitive) and get(primitive) -> primitive
The metamodel doesn't want to know 03:08
luqui robkinyon, think in terms of algebra
robkinyon Ok ... ?
luqui nobody cares what the real numbers are, as long as they satisfy all the properties that the real numbers do
robkinyon exactly what I'm getting at
luqui opaque *behaves* like a generic hash
robkinyon fair nuff
yes - it behaves as a hash that can take any primitive as a key
there is no auto-conversion between the primitives - this is also important 03:09
If I set a key Int == 2 and another key Float == 2, they are different keys
luqui alright 03:10
robkinyon Now, the metamodel goes ahead and defines Class, class, Object, etc. 03:11
Just like it always has
luqui it uses strings pretty prolifically IIRC
robkinyon stevan's might have, and the final P6 one probably will as well, but that's userland policy, not a metamodel requirement 03:12
luqui okay
robkinyon Now, every primitive provided by the runtime, except for Opaque (and possibly Block and Signature), is boxed up by a class of the appropriate name 03:13
So, the String primitive is boxed by String, the int primitive by Int, etc.
Actually, Signature has to be boxed, as well.
It needs to be in order to handle the full range of P6 signatures
Another class Type is created, to handle the P6 types 03:14
luqui Signature will probably be something completely different from the metamodel's Signature
robkinyon The userland Signature will most definitely be different than the runtime Signature
luqui so it's not so much "boxed" as "reimplemented". anyway, continue.
robkinyon However, it makes sense for the userland Signature to box the runtime Signature so that it can mediate between the two
yeah - boxing === reimplementation to some degree, in my mind 03:15
luqui ... alright
robkinyon So, now - when a method gets called, the metamodel checks the parameters passed against the userland Signature(s) for that method
if there's a problem, it throws an error right there - the runtime is never involved
So, type-checking P6 types is the responsability of the metamodel in conjunction with the userland. 03:17
They may be the same thing, or not - it's unclear which is the better approach
luqui I seem to be unclear on something: 03:18
robkinyon go on
luqui what is the metamodel's responsibility?
what is it supposed to be implementing?
robkinyon It implements the framework to handle classes/objects/method dispatch/etc. 03:19
everything stevan's was doing
luqui yeah, I know, I just wasn't sure how far-reaching it is supposed to be
robkinyon I don't think that was ever decided
luqui "as much as we can cleanly theorize" :-) 03:20
robkinyon "As much as makes sense for something else to not handle"
right now, i think it's the garbage pile
or that drawer in your kitchen that doesn't have a name
luqui Isn't the garbage pile the responsibility of the garbage collector? :-)
robkinyon LOL 03:21
it's the kitchen sink
stevan's started to discuss the idea of a userland which implements language policy, and i think that's a very important distinction to make
I'd argue that "userland" is really very close to PGE
and PGE (or whatever other grammar engine is used) may or may not convert everything into calls into the metamodel 03:22
Which is partly why i didn't want to agree that strings are very important - it may be useful to have a PGE extension that doesn't use strings as method names
luqui by PGE you mean the compiler? 03:23
robkinyon the compiler/lexer/semantic'er/etc
luqui It's probably best to separate your concerns there
robkinyon it's whatever facility will allow me to redefine the language at runtime
luqui I don't think the parser has much at all to do with the metamodel 03:24
at runtime?
robkinyon fair enough
it's the thing that converts my statements into useful P6 constructs
luqui that's compile time, no?
robkinyon is a little fuzzy on some details
I thought I would be able to redefine syntax in a lexical scope
luqui yeah, that's a compile time operation
robkinyon ok 03:25
luqui anyway, I guess that's not your area of expertise :-). Go on with the metamodel.
robkinyon well, i think that whatever-it-is is really close to the "userland" concept stevan and i are starting to bandy about
it enforces what constructs are legal from a language perspective
the metamodel provides constructs to the userland to be used as it sees fit 03:26
i'm not concerned with a lot of the metamodel constructs - that stevan's gig 03:27
my focus in this discussion is the mediation between the metamodel and the runtime
and how that percolates up to the userland 03:28
luqui The details are fuzzy... and I have to go to bed.
I'd recommend creating a diagram or writing something up more formally 03:29
so you can cover your bases
robkinyon ok
i'll see what i can come up with
luqui night 03:30
thanks, btw. we need more theorists 'round here; TSa, Stevan and I never fight about anything 03:31
robkinyon LOL
luqui which means we probably aren't doing the right thing
robkinyon stevan's been pulling me into this kicking and screaming
i think he hired me just so he could bounce this stuff off of me
luqui makes sense 03:32
sayonara
Khisanth there is a typo in perl5/README :) 04:51
dbrock can someone help me understand the humor in this quote? 04:53
"premature optimization is the root of all evil"
- Tad McClellan in clpmisc, "Re: Whats the variable holding the dir seperator?"
Khisanth why do you think there is humor in the quote? 04:54
rep supposedly that quote is really from Donald Knuth 04:56
dbrock Khisanth: because someone had it in their signature 05:01
so, strictly speaking, we're not specifically looking for humour per se, but rather "reasons why someone would find the quote interesting enough to put in their signature file" 05:02
Khisanth it is highly agreeable :) 05:03
dbrock rep: oh, I thought it was Hoare 05:04
rep dbrock www.cookcomputing.com/blog/archives/000084.html 05:05
dbrock Khisanth: well, sure, but then why attribute the quote to a Tad McClellan in some newsgroup, specifying the exact topic under which he said it?
rep so i guess you're right :) 05:06
dbrock C.A.R. Hoare's name is Tony?
rep uhm 05:07
dbrock ah, the A is for Anthony :-) 05:08
Sir Charles Antony Richard Hoare (Tony Hoare or C.A.R. Hoare, born January 11, 1934) is a British computer scientist, probably best known for the development of Quicksort, the world's most widely used sorting algorithm, in 1960. [...] <en.wikipedia.org/wiki/C._A._R._Hoare> 05:09
Cryptic_K is away 08:31
Cryptic_K is asleep!
svnbot6 r7962 | gaal++ | livecd fixes: 10:11
r7962 | gaal++ | * work around debian's magic db not having ext2(!?)
r7962 | gaal++ | * a few typos / better diagnostic messages
r7962 | gaal++ | * make a few more options configurable from the command line
r7962 | gaal++ | * bump up the size (should this be automated?)
rafl gaal: WTF is Debian's magic db? 10:12
gaal file some_file 10:13
somefile: text
file pugs 10:14
pugs: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
file initrd.img
initrd.img: # oops, ext2 isn't there :(
10:32 Lopo_ is now known as Lopo
theorbtwo file -sk /dev/hda1 # /dev/hda1: \012- Linux rev 1.0 ext3 filesystem data (needs journal recovery) (large files) 11:27
Interestingly, without -k, it just gives me emptystring.
(I don't have any plain ext2 around.)
wolverian wow, file is _really_ verbose about NTFS filesystems 11:30
SamB wolverian: heh 11:41
Juerd How many tests does Pugs have? 13:15
Is there a way to find out without running the entire suite? 13:16
rafl Juerd: If all tests have a plan it isn't that hard.
Juerd I don't know if they do. 13:17
rafl I guess most of them do. 13:18
robkinyon rafl: Run them - there should be a final count at the end. 14:08
Errr ... Juerd: Run them
it shouldn't take -that- long. :-)
14:50 wolv is now known as wolverian 14:56 PerlJam_ is now known as PerlJam
gaal Juerd: you can look at existing smokes on smoke.pugscode.org 15:02
also, our Test.pm doesn't have no_plan, so yes, they all have a plan. 15:03
15:03 whiteg_ is now known as whiteg
gaal seventeen .ts (or so) have programmatically determined plans. 15:06
(that's only in t/.) r7962 has 8663 tests (including ext/.) 15:07
also, since Test.pm has an explicit plan function and not something like Test::More tests => nnn, you could hack a version of it to do 'sub plan ($n) { say $n; exit }' and then run the whole test suite. That'd be pretty fast (especially if you precompile this hacky Test.pm . ;-) 15:16
Juerd gaal: I've already had a look; There are more than 8000, and that's a number I can use :) 15:17
I actually did a grep|perl
gaal yup 15:20
svnbot6 r7963 | iblech++ | t/builtins/control_flow/die.t: Added tests for die() in primitive constrol 15:24
r7963 | iblech++ | structures (map,grep,for,etc.). (See
r7963 | iblech++ | www.xray.mpe.mpg.de/mailing-lists/p...189.html.)
r7964 | iblech++ | util/perl6.vim: min and max should be highlighted in the same way as
r7964 | iblech++ | map,grep,sort,reduce etc. are (consider min { abs $_ } @numbers).
Limbic_Region am I the only one noticing that nmake realclean; svn up; perl Makefile.PL; nmake takes two tries to get through the build on Win32 cause GHC runs out of heap? 15:46
and the abyss was silent 16:03
well that, and has anyone notices that Pugs is S-L-O-W on Win32 16:05
svnbot6 r7965 | stevan++ | Perl6::ObjectSpace - 16:43
r7965 | stevan++ | * a rough sketch of the module/functor idea in API_sketch.pod
r7965 | stevan++ | * a basic (really badly done) code gen for the s-expr metamodel
r7965 | stevan++ | * added method::params and method::signature (they just inherit
r7965 | stevan++ | from their closure counterparts)
r7965 | stevan++ | - fixed the tests which deal with these
r0nny re 17:21
gaal Limbic_Region: you can increase heap size in config.yml (perl Makefile.PL after editing it) 17:31
as for slowness, d'you think it's slower than on linux? 17:32
Limbic_Region right - I saw that in the IRC log, was just relogging back in to say thanks
gaal - I can't get to feather from here, but it took a full 8 seconds to run a trivial piece of code 17:33
Limbic_Region really hates this client since when you get disconnected you have no way of knowing it
gaal - I haven't been keeping up with compiling pugs after every revision and testing its speediness but I would say that it is magnitudes slower then the last time I checked it 17:35
Limbic_Region needs to wander off
18:59 theorbtwo is now known as one, one is now known as theorbtwo 19:50 Lopo_ is now known as Lopo
svnbot6 r7966 | autrijus++ | * remove unneccessary System.Process import in Pugs.Embed.Pugs. 21:14
r7967 | autrijus++ | * After "make install", do not warn about "make register"
r7967 | autrijus++ | if it's actually implicitly done by the install target
r7967 | autrijus++ | (as is the usual case for DESTDIR-less situations)
r7968 | autrijus++ | * oops, squash a redundant 'make register' message 21:32
r7968 | autrijus++ | from pure_vendor_install target.
22:24 ntgrl is now known as integral 22:31 stevan_ is now known as stevan

Powered by Cro and the Raku® Programming Language.

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

Thank you!