pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, smop: etc.) || We do Haskell, too | > reverse . show $ foldl1 (*) [1..4] | irclog: irc.pugscode.org/
Set by TimToady on 25 January 2008.
meppl good night 00:24
nothingmuch @tell ruoso c.f. meta slots in MO 03:11
lambdabot Consider it noted.
alester yessir 04:52
nothingmuch h 08:09
lambdabot nothingmuch: You have 1 new message. '/msg lambdabot @messages' to read it.
nothingmuch @tell ruoso re what stevan was talking about... p6opaque living together with p5 types, unboxed types, etc all fully introspectable 08:10
lambdabot Consider it noted.
masak what happens in perl6 if you assign to undef? 09:19
moritz_ pugs: undef = 3; 09:55
exp_evalbot OUTPUT[*** Can't modify constant item: VUndef␤ at /tmp/ZAEY1V1HM3 line 1, column 1-10␤]
ruoso hi 11:15
lambdabot ruoso: You have 2 new messages. '/msg lambdabot @messages' to read them.
moritz_ hi ruoso ;) 11:16
ruoso hi moritz_
ruoso nothingmuch, I don't think I understood what you said... 11:31
pugs_svnbot r19913 | ruoso++ | [smop] runtime declared constants now working... All tests pass! the problem was SMOP__Object** x SMOP__Object* confusion... 12:20
diff: dev.pugscode.org/changeset/19913
lambdabot Title: Changeset 19913 - Pugs - Trac
moritz_ ruoso++ # all tests pass ;) 12:58
rakudo_svn r25711 | jonathan++ | [rakudo] Initial work on parsing rule, token, regex and grammar, plus a first-cut implementation to make regex work. rule and token currently have regex semantics, however. 13:07
rakudo_svn r25712 | jonathan++ | [rakudo] Junctions should not have a pick method, so remove it. Also remove now-unsed attempt at auto-threading. 13:26
rakudo_svn r25713 | jonathan++ | [rakudo] Tweak to allow you to do all(@array) as well as all(42,45,...). 14:12
pugs_svnbot r19914 | rhr++ | [smop] fix a test number
diff: dev.pugscode.org/changeset/19914
lambdabot Title: Changeset 19914 - Pugs - Trac
pugs_svnbot r19915 | andara++ | [pugspc] 14:36
r19915 | andara++ | A stand-alone Perl6-to-PIR compiler branched off from Pugs. I basically resurrected Pugs' -CPIL1 and -CPIR backends and removed all the rest.
r19915 | andara++ | First commit, all help welcome.
r19915 | andara++ | Needs ghc 6.8, on feather set your path to /home/andara/usr/local/bin
diff: dev.pugscode.org/changeset/19915
lambdabot Title: Changeset 19915 - Pugs - Trac
moritz_ andara: no need to put it under misc/, if you are serious ;) 14:37
andara moritz_: serious? it was just for fun of course :-D 14:39
moritz_ andara: serious fun, that is ;) 14:40
andara moritz_: aye, rather. It's not far behind rakudo and mainly due to incomplete PIR builtins 14:41
moritz_ andara: did you build debian packages for ghc 6.8? 14:42
andara moritz_: no. never did that, is it hard? I just took the binary from haskell.org
moritz_ andara: dunno, if you did I would have used them as well ;) 14:43
andara moritz_: have a look here: haskell-unsafe.alioth.debian.org/ha...nsafe.html 14:45
lambdabot Title: Haskell Unsafe
moritz_ andara: I just looked at it, it's far too old 14:46
andara moritz_: yeah, I see. Is it against your principles to install a binary locally without .deb ;-) 14:48
moritz_ andara: no, I'll install it locally. Installing globally is evil, though ;) 14:49
andara moritz_: agree. Say, you seem to be online often. I've been away from per6 for a few months, did I miss much excitement? 14:51
moritz_ andara: depends on your notion of "excitement"
moritz_ are you asking about spec changes? or implementation? 14:51
andara rather implementation 14:52
moritz_ kp6 is nearly bootstrapped, waiting for a faster backend
ruoso++ is working on it, called "smop"
andara "smop"? 14:53
moritz_ A C preprocessor and runtime lib that takes care of the meta object stuff
"simple meta object programming"
andara ok
moritz_ or "small matter of programmiing"
andara :-)
moritz_ today he got to the "all test pass" status ;)
perl6 on parrot is now called rakudo 14:54
andara Yes, I gathered that
moritz_ and it's progressing 14:54
andara Yes, I checked it out, looks very promising. 14:55
moritz_ but slowed by some personal issues (pmichauds wife got sick, and a few other things)
but looks bright ;)
TimToady has hacked a preprocessor for the tests, called "fudge"
cosimo and a few others started to check tests, reorganize them, and move to t/spec/* 14:56
andara very brave :-)
I knew about the work on rakudo, but it seemed a shame to just drop the brilliant Pugs code, that's why I tried to resurrect the PIR backend 14:58
moritz_ the 'fudge' thing is there for making implementation specific TODO marks
ruoso pugs: class A { method a { say $!foo } }; A.new().a(); 15:21
exp_evalbot OUTPUT[␤]
[particle] hrmm, no error?
ruoso pugs: class A { method a { say $!foo }; method b ($a) { $!foo = $a }; my $a = A.new(); $a.a(); $a.b(1); $a.a(); 15:22
exp_evalbot OUTPUT[*** ␤ Unexpected end of input␤ expecting ";" or "}"␤ at /tmp/m53tbYqVAg line 2, column 1␤]
ruoso pugs: class A { method a { say $!foo }; method b ($a) { $!foo = $a } }; my $a = A.new(); $a.a(); $a.b(1); $a.a();
exp_evalbot OUTPUT[␤1␤]
ruoso so, pugs autovivifies the private storage 15:23
pugs: class A { method a { say $!foo.WHAT }; method b ($a) { $!foo = $a } }; my $a = A.new(); $a.a(); $a.b(1); $a.a(); 15:24
exp_evalbot OUTPUT[Scalar␤Int␤]
ruoso $!foo.WHAT should be Object when uninitialized, shouldn't it?
VAR($!foo).WHAT would be Scalar 15:25
anyway...
smop p6opaque current design would make it behave like this... 15:26
(autovivifying private storage)
I need a different API for declaring the private storage and later accessing it 15:27
so it can Fail on non-existent private slots in the second phase
[particle] autovivifying private storage isn't what i'd expect, but i'm not sure what the spec says
ruoso it's probably just wrong... 15:28
[particle] ok. good.
ruoso considering Perl 6 is strict by default
[particle] right.
ruoso although there must be a way to allow it
ruoso hmm... 15:35
I need a second BUILD submethod that cannot be overrided by the user (at least not easily)
which is the BUILD that initialize the instance using the REPR API 15:36
moritz_ ruoso: but can't non-strict behaviour be detected at compile time, and morphed into 'strict' code?
ruoso moritz_, I'm not sure... can you do $!"foo"?
pugs: class A { method a { say $!"foo" }; method b($a) { $!foo = $a } }; my $a = A.new(); $a.a(); $a.b(1); 15:37
exp_evalbot OUTPUT[*** ␤ Unexpected "\""␤ expecting term postfix, operator, ":", "," or "}"␤ at /tmp/FpBafdN9rk line 1, column 28␤]
moritz_ ruoso: like symbolic refs? don't think so, but not sure
ruoso at least pugs doesn't support it
Juerd andara: GHC 6.8.2 is in Debian; installing it on feather as I type
andara Juerd: brilliant, thanks a lot! 15:38
ruoso TimToady, is $!"$var" allowed? 15:47
andara Juerd: is there an extra library package for GHC 6.8.2? I seem to be missing some libraries 15:48
Juerd Let's see
There are many 15:49
I'll just install them all :)
andara Juerd: I'm missing in particular stm
Juerd Oh, all won't work because some are still for 6.6 15:50
andara Juerd: cool, thanks!
bbl &
TimToady I'm not even sure that $."var" is allowed
if you really want indirection, we should probably force use of the long form in either case
TimToady self!"$var" should presumably be allowed 15:50
Juerd Installing stm 15:51
TimToady though I don't think that's in STD yet
loki666 hi, sorry for my bad english... i need construct one module to create syn packages in perl
help please
moritz_ loki666: you're only right here if you want to use perl 6 ;) 15:52
Juerd loki666: Perl version 6?
loki666: If not, have a look over in #perl
moritz_ ... and I doubt that it's much fun right now
loki666 one moment please. 15:53
sorry, 15:54
ok, thanks
Juerd I wonder why people looking for help join #perl6 15:59
In a channel list, it's sorted right under #perl probably, and I think using a channel list is kind of weird anyway :) 16:00
[particle] maybe because they tried # perl 5 first and were disappointed 16:01
grr.
you know what i mean
moritz_ we all know what you mean 16:03
perhaps we need #perl5helpforreal ;) 16:04
ruoso pugs: class A { has $!a; has @!a; } 20:14
exp_evalbot RESULT[undef]
ruoso pugs: class A { has $!a; has @!a; method a { say $!a; say @!a; } } A.a() 20:15
exp_evalbot OUTPUT[*** Class prototype occured where its instance object expected: A␤ at /tmp/Z3mBTtDS4r line 1, column 40-47␤ /tmp/Z3mBTtDS4r line 1, column 40-47␤]
ruoso pugs: class A { has $!a; has @!a; method a { say $!a; say @!a; } }; A.a()
exp_evalbot OUTPUT[*** Class prototype occured where its instance object expected: A␤ at /tmp/nnDoJKC45Q line 1, column 40-47␤ /tmp/nnDoJKC45Q line 1, column 40-47␤]
ruoso pugs: class A { has $!a; has @!a; method a { say $!a; say @!a; } }; A.new().a()
exp_evalbot OUTPUT[␤␤]
ruoso pugs: class A { has $!a; has @!a; method a { say $!a.WHAT; say @!a.WHAT; } }; A.new().a() 20:15
exp_evalbot OUTPUT[Scalar␤Array␤]
nothingmuch ruoso: stevan was discussing the meta isntance 20:16
in Moose the meta instance is a provider of "slot" access
slot == actual storage an attr can use, without caring how the storage is organized
in MO it's a little more abstract
nothingmuch the attr requests a bunch of slots 20:17
and gets back slot manager objects
these are coordinated by a meta instance
and more decoupled
a p6 opaque generating meta instance would know how p6opaques are implemented
an unboxed meta instance for an int would have just one slot for the value
a Moose meta instance for p5 hash based objects will abstract hash access
ruoso hmm... ok... in smop this is determined by the responder interface 20:18
that intercept the meta calls
instead of doing the usual dispatch
yes... so you have repr and responder interface coupled 20:20
nothingmuch, do you think that might be a problem?
nothingmuch no, ri == interface 20:22
meta instance == representation
ruoso yes... I know...
nothingmuch the responder interface cares what to do with the box
the meta instance cares what to do with the inside of it
only the constructor/accessors gain access to the actual data
and even that is indirect
nothingmuch it can be optimized to be inline 20:22
but accessor implementations should be representation independant 20:23
ruoso nothingmuch, but that's why there's the REPR api
I think conceptually both apply
it might be just an implementation detail
nothingmuch (e.g. the same definition of the Int class can work for real objects that has $.value, and are p6opaque, or are really moose objects which are implemented with a hash)
ruoso yes...
nothingmuch but when it's Int,new 20:24
then there are no other fields
well, i forgot if Int is infinite or not
if it's int
ruoso in smop, that will be controlled by the responder interface
nothingmuch why?
ruoso because even the meta methods are called through the responder interface 20:25
nothingmuch so? 20:25
no method needs to know about the representation, ever
ruoso except the metamethods 20:26
nothingmuch the same accessor can be used with multiple implementation types
not even them
ruoso sorry...
except the repr methods
nothingmuch still not necessary =)
ruoso the metamethods will use the repr methods
nothingmuch it's the *slot*'s responder interface that might know more
but that's completely encapsulated 20:27
in practice the slot should be optimzied away 99% of the time
ruoso ah... wait... I think we're not talking about the same thing here...
nothingmuch OK, please resync me then =)
ruoso the slot inside p6opaque is an object like itself 20:28
or not
it's completely encapsulated by the slot's ri
nothingmuch let's talk low level for a sec
ruoso but you still need to know how to get to the slot
before talking to the slot
nothingmuch somewhere, soemthing is going to actually deref a pointer and write a value, right?
ruoso yes, but that's in a very late stage 20:29
the slot is a container
you'll STORE on the container
nothingmuch yes
ruoso by calling a method
nothingmuch exactly
it's the same level of metacircularity that Invocation has
or the fact that each responder interface has it's own responder interface
rindolf Hi all.
Hi nothingmuch
nothingmuch hola
rindolf nothingmuch: what's up? 20:30
nothingmuch: would you suggest Moosifying Test::Run? At the moment I'm using Class::Accessor.
nothingmuch not much perl 6 stuff, tbh
rindolf nothingmuch: oh.
nothingmuch sure, that should be a fun endaveor
rindolf nothingmuch: I enjoyed your presentation at the Perl Workshop.
nothingmuch thanks =) 20:31
rindolf About Devel::Events.
nothingmuch was very antisocial
rindolf There's a recording of it.
nothingmuch i had internets issues so I arrived only in time to give mine
missed the whole day
ruoso nothingmuch, the metacircularity is broken when a low-level implementation implements a container in C struct terms...
nothingmuch ruoso: precisely 20:31
rindolf ruoso: meta-circ of what? 20:32
nothingmuch the object that breaks this circularity is closed over in the responder interface of the resultant object
ruoso rindolf, by the fact that the attribute of an Object is an Object
nothingmuch ... and the fact that a method is an object
and that to call a method call you need to call a method call on an object that dispatches method calls =) 20:33
ruoso what do you mean by "closed over"
?
nothingmuch the metaclass gathers the meta attributes
asks them for their slot information
and provides these bundles to the meta instance 20:34
more accurately it constructs a meta instance with these slots
slot descriptions
ruoso in fact, you *can* implement it that way... but smop doesn't *require* you to do it
you can implement a responder interface that short-circuits everything to a C struct
nothingmuch then when the methods of the attribute are compiled by the attr (using the meta instance) 20:35
yes, but that's not extensible
might as well ditch meta altogether =)
nothingmuch the meta instance will give the attr meta slot object to use for value access 20:35
the accessors/constructor will close over these objects 20:36
ruoso nothingmuch, did you see the SMOP OO API and SMOP p6opaque Implementation wiki pages?
nothingmuch the p6opaque page no 20:37
wait, actually i think i see where our misunderstanding is
let's go back to Foo isa Int and a real Int
their responder interfaces though related are completely independant
ruoso might be or might be not
nothingmuch completely unrelated means "could possibly be" in this context 20:38
it *is* the responder interface who at the end of the line is responsible for locating (probably indirectly) the correct low level impl for the value access
ruoso if both use the same representation, they will probably use the same RI
nothingmuch no, because they have different methods
ruoso the RI will dispatch to the meta 20:39
s/dispatch to/talk to/
to do the dispatch
nothingmuch do you mean same RI class?
ruoso same RI instance
but different invocants 20:40
nothingmuch why?
ruoso ok... wait... RI prototype 20:41
an RI is never an instance
or almost never
there's no much point in it being instantiated
nothingmuch por que? 20:42
ruoso because every call is always invocant-dependant
so, in a higher-level-sense
nothingmuch well, for protype object RIs, yes
ruoso they will be two RI instances
nothingmuch but 'int' can't be a prototype object
because it's just n bits of integer data
ruoso nope... int is an SMOP__Object...
nothingmuch lowercase int, not Int 20:43
ruoso yes...
the only difference between int and Int
is that I can know for sure the repr of "int", and not of "Int"
nothingmuch well, it *can* be completely unboxed
ruoso in C? how? 20:44
when will that value be destroyed?
who will care about its destruction
nothingmuch because the prototype of all 'int's are statically known then the method set can be copied over to a static method table responder interface
ruoso but how do I know that something is an int? 20:45
nothingmuch if it needs to be destroyed then this is a specific responder interface variant for 'int' that supports tracking
the int constructor knows
ruoso how?
nothingmuch it binds the RI and the value
because it's the constructor
ruoso ah.. ok
that's what a SMOP__Object* is
nothingmuch if the constructor doesn't know what kind of object it makes, then we're way too meta ;-)
right, but you can go further
ruoso a SMOP__Object is simply something with a RI
nothingmuch in the case of 'int'
there is never any finalization guarantee, IIRC 20:46
since the class is closed
when you know that in the low level an 'int' value can live as parameters only
and get thrown away with it's continuation when it's no longer needed
then you don't need to box it at all, the value can just be the actual C repr of the int
the constructor will have two variants (Whether by some special optimizer flag, or really two distinct variants) 20:47
one returns an int, and the code calling on it is responsible for tracking the responder interface
ruoso how can I send a plain int into a capture and recognize it in the other side?
if it's not tagged with its RI?
nothingmuch the other returns a pointer to "something" boxed with a responder interface
that is something you must statically know 20:48
this is an optimization
ruoso ah... ok...
nothingmuch if you have a type annotation, for instance
ruoso we're in the JIT-land in that matter
nothingmuch but wait, i will actually take this further ;-)
now, in the case of a boxed int
it's a pointer to "something"
but that something can still be just an int*
so autoboxing a low level int is just a matter of allocating space for that int, writing it there, and and sending an object box with the right int 20:49
a third variant for the constructor would create a p6opaque
with one slot for value
*the value
this and the second variant are completely polymorphic 20:50
the calling code can never know which is which
without deconstructing the responder interface
this third object looks similar to what subclasses of int do 20:51
ruoso if "something" is just an int* how will you call it the same way as other things
nothingmuch it's a touple
(int*, ri)
ruoso ah...
ok..
that's SMOP__Object
nothingmuch wheras the third variant is
(dict*, ri) 20:52
yes
dict* in our case is a p6opaque
or HV
the responder interface for these guys doesn't need to know the difference though 20:53
if it's a method table
(it's expensive to copy the whole method table in every prototype object if it can be deduced that the slots for the methods are unused by everyone except the responder interface itself)
ruoso I won't copy the whole method table... 20:54
not even in p6opaque
nothingmuch s/whole/local/;
if it's a "real" prototype object, in the sense that it's a dictionary of values
and some values are methods 20:55
nothingmuch and the responder interface walks the parent chain at runtime 20:55
then the responder interface is compiled with slot access into it
but in 99% of the cases you can create a simpler responder interface
that knows the entire set of methods statically
and is just a dumb vtable
(fwiw, even in the prototype object case, the responder interface should delegate for the meta attr of each method) 20:56
ruoso nothingmuch, that's what I'm calling "low-level implementations" 20:57
for instance...
the Array of Method returned by .^!methods() 20:58
it will simply navigate into the p6opaque structure of the given object 20:59
ruoso it's what allbery_b was calling a "community" yesterday 20:59
but I need to go... 21:00
nothingmuch just briefly before
please disambiguate 'navigate'
ruoso it will go access the members of the C struct directly 21:01
because it *knows* the structure of that specific object
nothingmuch as an optimization
ruoso yes
nothingmuch ?
ruoso not only, actually
it needs to do that to avoid circularity also 21:02
nothingmuch ah right 21:03
ruoso several optimizations in smop have that same function
the constant identifiers are the best example
it's an optimization in the sense that it allows string matching with plain C pointer identity check 21:04
ruoso but it breaks circularity because it avoids the need of another method call to do the comparing 21:04
which would require other identifiers to be used
other is the constant capture returned when the invocant is the interpreter 21:05
it avoids creating and destroying an unecessary object
ruoso but it break circularity on the "current" call 21:06
that returns the current continuation
ruoso signing of in 5...
4.. 21:07
nothingmuch well, in any case of circularity breakage
ruoso 3.. 2...
nothingmuch there should always be a low level accessible unbreaking
ruoso basically, ues
nothingmuch so that in the level just slightly higher it doesn't appear to be broken
ruoso s/ues/yes/
nothingmuch OK, so we were in agreement after all, it seems
ruoso heh... yeah...
and it looks smop survived another massive peer review ;) 21:08
actually... massive review from a peer
heh
nothingmuch stevan too
=)
ruoso pressing the eject button 21:09
nothingmuch ciao 21:10

Powered by Cro and the Raku® Programming Language.

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

Thank you!