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. |
|||
00:04
chris2 left
00:06
icwiener left
00:12
cmarcelo left
00:30
hercynium left
00:33
Alias_ joined,
Limbic_Region joined
00:40
bacek joined
|
|||
pugs_svn | r21303 | ruoso++ | [smop] fixing memory leak in p6opaque. test/12 is valgrind clean again... | 00:41 | |
00:50
nipotan is now known as nipotaway
01:09
alester_ joined
01:15
alester left
|
|||
pugs_svn | r21304 | ruoso++ | [smop] test/14_p6opaque_methods compiles and runs, but it is obviously not passing yet. | 01:17 | |
01:44
alanhaggai left
02:02
redicaps left
02:05
Southen_ joined
|
|||
speckbot | r14561 | larry++ | [S12] s/bool/Bool/ | 02:07 | |
02:08
rhr_ is now known as rhr
02:20
alanhaggai joined,
simcop2387 joined
02:25
kanru left,
Southen left
02:28
Jamtech joined
02:32
justatheory left,
[particle]1 joined
02:39
meteorjay left
02:48
[particle] left
|
|||
ingy | hola | 02:55 | |
ingy fires up his Perl 6 machine | 02:56 | ||
02:57
kanru joined
|
|||
pmichaud | TimToady: Are there more changes in the queue for the synopses wrt .Bool, .true, etc? Or should I go ahead and start asking questions? | 03:04 | |
TimToady | feel free | 03:05 | |
pmichaud | what's the relationship between .true and .Bool ? | ||
TimToady | true is an Any method | ||
Bool is a coercion via type name | |||
pmichaud | so, given an object in a boolean context, how do we decide what to return? | 03:06 | |
e.g., for prefix:<?> | |||
TimToady | true() and prefix:<?> coerce to 0 or 1, I think | 03:08 | |
pmichaud | what logic do they use to decide the boolean value of an object? Do they check .True first, and fall back to .true? | ||
TimToady | I think all types should define .true, probably | 03:09 | |
pmichaud | yes, .true is defined in Any | ||
er, Object | |||
TimToady | defaults to .defined, I think... | ||
pmichaud | (S02 says .true is defined in Object) | ||
(and yes, it defaults to .defined) | |||
but if I have | 03:10 | ||
my $x = $a but True; say ?$a; | |||
how does that "but True" get handled in prefix:<?> | |||
sorry, I meant say ?$x | |||
(I really can't type these days. I should type slower.) | 03:11 | ||
TimToady | prefix:<?> calls .true on the object, and the anon type overrides the .true method | ||
pmichaud | it overrides the .true method because...? | ||
TimToady | it mixes in a role that defines .true, I guess | 03:12 | |
pmichaud | but that role isn't the Bool role? | ||
TimToady | why not? | ||
pmichaud | oh. Bool isn't strictly an enum, then | ||
i.e., it's not just our bit enum *Bool <True False> because there's also a .true method in there somewhere | 03:13 | ||
TimToady | Bool is a valid type for an object or a property. True and False are subset types | ||
well, .true may be built-in to bit as a 1 bit int already | 03:14 | ||
pmichaud | but then bit would autobox to Bit in that case? | 03:15 | |
TimToady | bit :: uint1 | ||
if you had to pass it somewhere as an object, it would box to some variety of Int | |||
pmichaud | (since native types autobox to their uppercase counterparts when treated as objects) | ||
TimToady | not sure if that always has to be the case | 03:16 | |
pmichaud | ah. I was reading from S02. | ||
TimToady | native types are really a funny kind of subset type | ||
except the hardware enforces the limit :) | 03:17 | ||
pmichaud | yes, but adding methods to native types sounds.... tricky | ||
TimToady | well, you have to know the container type; you can't ask it what it is... | ||
pmichaud | okay, that lost me. | 03:18 | |
TimToady | an "int" is a container, but not an object, so you have to implicitly know the .HOW of it | 03:19 | |
pmichaud | okay | ||
so, .true is a method on bit (or int) | 03:20 | ||
and role composition causes it to override | 03:21 | ||
TimToady | mixin, not composition | ||
pmichaud | mixin, thanks. | ||
(still learning all the terms here) | |||
okay, I can follow that, I think. | 03:22 | ||
TimToady hides the hands he was waving... | |||
pmichaud | one more question: what's the output of say (?0).perl ? | ||
TimToady | perl6: say (?0).perl | 03:23 | |
p6eval | elf 21304: OUTPUT[0ā¤] | ||
..pugs: OUTPUT[Bool::Falseā¤] | |||
..rakudo 29275: OUTPUT[Bool::Falseā¤] | |||
03:24
redicaps joined
|
|||
pmichaud | (rakudo does Bool::False simply because that's what Pugs and the test suite do.) | 03:24 | |
TimToady | I am still slightly undecided on whether ? should be returning a bit or a Bool. can argue it either way, typologically | ||
pmichaud | oh, I was able to see lots of ways to argue it, which is why I asked :-) | 03:25 | |
TimToady | there's probably a lot to be said for trying to preserve enumness | 03:26 | |
and the Bool-is-really-bit-at-runtime is kind of a compiler-centric view | 03:27 | ||
where compiler is defined as that thing that throws away all the useful type info :) | |||
certain +?$x should return 0 or 1 | 03:28 | ||
pmichaud | I just think of it as lossy compression :-) | ||
TimToady | but darn it, computers treat all bits as booleans, in some sense... | ||
and certainly P5 programmers are used to thinking of booleans numerically | 03:29 | ||
(if you consider "" to be a variant of 0...) | |||
03:31
Limbic_Region left,
alanhaggai left
03:33
nothingmuch left
|
|||
TimToady | I also get a bit tired of seeing Bool::True and Bool::False everywhere... | 03:33 | |
pmichaud | also Order::Decrease, Order::Same, Order::Increase (from cmp) | 03:34 | |
TimToady | for most purposes, if there is no conflict, True/False or Decrease/Same/Increase is sufficient for clarity | 03:35 | |
but maybe it's a false economy | 03:36 | ||
maybe a pragma is the appropriate solution here | 03:37 | ||
use perl :enum<explicit> | 03:38 | ||
hmm | |||
pugs: say perl(1+2); | 03:39 | ||
p6eval | pugs: OUTPUT[3ā¤] | ||
TimToady | perl6: say perl(1+2); | ||
p6eval | elf 21304: OUTPUT[Undefined subroutine &GLOBAL::perl called at (eval 119) line 3.ā¤ at ./elf_f line 3861ā¤] | ||
..pugs: OUTPUT[3ā¤] | |||
..rakudo 29276: OUTPUT[Could not find non-existent sub perlā¤current instr.: '_block11' pc 36 (EVAL_11:16)ā¤] | |||
TimToady | 'nother one of them little spec holes... | 03:40 | |
03:40
pbuetow_ joined
|
|||
TimToady | I wonder if we should make .repr spit out Python code. :) | 03:41 | |
pmichaud | :-) | ||
I don't need an immediate answer to any of these -- just want to be able to answer questions for Rakudo and the test suite | |||
TimToady | in some of these cases there really isn't a best answer, but it'd be nice if the implementations all agree at least | 03:43 | |
(but I do hate arbitrary decisions...) | |||
pmichaud | I have another question from the earlier questions, but I'm not quite sure how to phrase it | 03:44 | |
so bear with me | |||
(keeping in mind I still don't _completely_ understand roles/properties) | |||
if we have our bit enum *Bool <False True> | 03:45 | ||
and then my $x = 0 but True; | |||
then $x has a .Bool method, a .True method, and a .False method mixin'ed, yes? | |||
and it also gets all of the methods defined on the 'bit' type as well? | 03:48 | ||
TimToady | if so, it would indicate the object in $x is of type Bool rather than just type bit | 03:49 | |
and the "bit" type is really just a storage hint for compaction purposes | 03:50 | ||
presumably 1.False returns a Failure | 03:51 | ||
03:52
cain_22 joined
|
|||
TimToady | you automatically get all typenames as methods, I think | 03:52 | |
03:52
pbuetow left
|
|||
pmichaud | as methods on.... ? | 03:53 | |
TimToady | and maybe those are special cased as coercions, so can be defined either incoming or outgoing to a type | 03:54 | |
pmichaud | well, that kinda brings up another question: my enum Foo @foo; # valid? | 03:55 | |
TimToady | would have to value of @foo at compile time | 03:56 | |
pmichaud | okay. | ||
TimToady | like in use Foo @foo; | ||
family calling; will backlog & | |||
pmichaud | no problem. I still don't quite understand the "indicate object in $x is of type Bool" and how .true ends up in the mixin'd value | 03:57 | |
(I can understand that it's in 'bit', but I don't see how we get the methods from 'bit' into the mixin'd value -- that seems like more than a simple role mixin) | 03:58 | ||
afk for a while | 04:11 | ||
04:20
wknight8111 left,
c1sung left
04:24
Jamtech left
04:45
casyn left
04:51
simcop2387 left
04:54
simcop2387 joined
05:07
kanru left,
kanru joined
05:14
Ara5n joined
05:17
[particle]1 left,
kattana_ left,
cognominal_ left,
Guest16015 left,
p6eval left,
orafu left,
yves_ left,
ilbot2 left
05:18
Patterner left,
cj left,
Psyche^ joined,
Psyche^ is now known as Patterner
05:19
Grrrr left,
Grrrr joined
05:22
pugs_svn left,
pugs_svn joined,
[particle]1 joined,
kattana_ joined,
cognominal_ joined,
p6eval joined,
yves_ joined,
Guest16015 joined,
orafu joined,
ilbot2 joined,
bacek left
05:23
baest left,
bacek joined
05:24
baest joined
05:25
Psyche^ joined
05:28
alanhaggai joined
05:29
c1sung joined,
Ara4n left
05:30
redicaps left,
s1n left
05:31
mtve left
05:34
s1n joined
05:38
stevan_ left
05:42
Patterner left,
Psyche^ is now known as Patterner,
cj joined
05:43
GeJ_ is now known as GeJ
05:47
sri_work left
06:29
alanhaggai left
06:32
alester_ left
06:34
alanhaggai joined
06:50
barney joined
06:57
pmurias joined
|
|||
pmurias | TimToady: how does an object specifiy it's hash function? | 06:58 | |
lambdabot | pmurias: You have 1 new message. '/msg lambdabot @messages' to read it. | ||
07:01
jiing left
07:20
nothingmuch joined
07:22
mtve joined
07:24
alanhaggai left
07:25
redicaps joined,
nothingmuch left
|
|||
pmurias | pugs: module Foo {our $foo=7};say $foo; | 07:40 | |
p6eval | pugs: OUTPUT[*** ā¤ Unexpected ";"ā¤ expecting "::"ā¤ Variable "$foo" requires predeclaration or explicit package nameā¤ at /tmp/y87Qe9eh8O line 1, column 33ā¤] | ||
pmurias | pugs: module Foo {our $foo=7;};say $foo; | ||
p6eval | pugs: OUTPUT[*** ā¤ Unexpected ";"ā¤ expecting "::"ā¤ Variable "$foo" requires predeclaration or explicit package nameā¤ at /tmp/ikMRRsLrnP line 1, column 34ā¤] | ||
pmurias | pugs: module Foo {our $foo=7;};say $Foo::foo; | ||
p6eval | pugs: OUTPUT[ā¤] | ||
pmurias | pugs: module Foo {our $foo=7;};say $*Foo::foo; | ||
p6eval | pugs: OUTPUT[ā¤] | ||
pmurias | pugs: $Foo::foo=7;say $Foo::foo; | ||
p6eval | pugs: OUTPUT[7ā¤] | ||
pmurias | pugs: $Foo::foo=7;say $*Foo::foo; | ||
p6eval | pugs: OUTPUT[ā¤] | ||
pmurias | pugs: $*Foo::foo=7;say $*Foo::foo; | ||
p6eval | pugs: OUTPUT[7ā¤] | 07:41 | |
07:43
tuxdna joined
|
|||
pmurias | ruoso: hi | 08:05 | |
08:08
iblechbot joined
|
|||
pmurias | ruoso: is there any sort of reference counting debugging mode? | 08:11 | |
i have found SMOP_LOWLEVEL_MEM_DEBUG, but it floods me with not very usefull data | 08:31 | ||
08:44
kattana_ left
08:50
jiing joined
|
|||
pmurias | moritz_: the current evalbot backends don't offer any security right? | 09:11 | |
moritz_ | pmurias: pugs does | 09:12 | |
pmurias: and the others offer security by inability ;) | |||
at least a bit ;) | |||
actually kp6 also has a safe mode | |||
let's ask the other way round - how much would you benefit from evaling sm0p code on evalbot? | 09:13 | ||
ruoso | pmurias, SMOP_LOWLEVEL_MEM_DEBUG is one way... other way is valgridn... it will show you where the unfreed memory was allocated... | 09:21 | |
pmurias | moritz_: kp6 does not have a *working* safe mode | 09:24 | |
09:26
meppl joined
|
|||
pmurias | ruoso: i'm debuggin memory being freed twice | 09:27 | |
09:28
chris2 joined
|
|||
pmurias | * debugging | 09:28 | |
is there an equivalent of caller in c? | 09:30 | ||
09:34
elmex joined
|
|||
pmurias | i could add a log of reference counter increments and decrements to SMOP__Objects if it did | 09:36 | |
rakudo_svn | r29285 | bernhard++ | [Rekudo] Some tidbits in docs/compiler_overview.pod and README | 09:38 | |
pmurias | maybe scripting the gdb would work... | 09:39 | |
ruoso: would a tool showing where was the reference counter of a prematurly free'ed of leaking smop counter changed be helpfull to you? (i don't know if it's worth doing something like that) | 09:42 | ||
buying a gsm modem& | 09:46 | ||
09:46
pmurias left
10:06
ruoso left
10:09
iblechbot left
10:19
wknight8111 joined
10:21
bacek left
10:22
meppl left
10:24
donaldh joined
10:26
Kattana joined
10:29
meppl joined
10:38
redicaps left
10:58
b_jonas joined
11:04
wknight8111 left
11:35
pbuetow_ left,
pbuetow joined
11:43
ruoso joined
11:47
wknight8111 joined
11:57
broquaint left
12:04
broquaint joined
12:09
tuxdna left
12:11
mjk joined,
alanhaggai joined
12:38
wknight8111 left
12:40
rindolf joined
12:44
cmarcelo joined
12:47
iblechbot joined
|
|||
moritz_ is offline for the weekend, see you call | 12:58 | ||
13:01
alc joined
13:04
rurban joined
13:08
awwaiid_ is now known as awwaiid
|
|||
rakudo_svn | r29290 | pmichaud++ | [rakudo]: spectest-progress.csv update: 95 files, 1691 passing tests | 13:09 | |
13:09
alanhaggai left
13:19
rindolf left
13:21
ruoso left
13:36
rindolf joined,
mjk left
13:40
alc left
13:41
Schwern joined
13:42
pmurias joined
13:50
rdice joined
14:00
wknight8111 joined
14:02
rindolf left
14:05
rindolf joined,
barney left
|
|||
rurban | Can somebody please update the pugs webpage with the recommended installation method? (Install ghc, Cabal, cabal-install, HTTP, zlib, Pugs) | 14:05 | |
14:06
thepler_ joined
|
|||
rurban | BTW: How to submit an pugs installation guide for cygwin? | 14:09 | |
14:18
rindolf left
|
|||
pmurias | rurban: isn't the general windowsy best practice to make a installer? | 14:22 | |
rurban | win32 yes, cygwin not. | ||
I'm just writing it to my use.perl journal.... | |||
14:26
rindolf joined
|
|||
pugs_svn | r21305 | pmurias++ | [smop] | 14:34 | |
r21305 | pmurias++ | hashes are DESTROYEDALL'ed corretly | |||
r21305 | pmurias++ | fixed sm0p.pl bug | |||
r21305 | pmurias++ | added untested infix:eq | |||
14:35
pmurias left
14:38
hercynium joined
14:43
scrottie left,
jhorwitz joined
|
|||
rurban | cygwin pugs installations at use.perl.org/~rurban/journal/36897 | 14:48 | |
lambdabot | Title: Journal of rurban (7989) | ||
14:54
alanhaggai joined
14:56
[particle]1 is now known as [particle]
15:01
alester joined
15:04
rurban left
15:12
rdice_ joined
15:19
barney joined
15:28
rdice left,
donaldh left
15:31
lumi left
15:33
nothingmuch joined,
jjore left
15:38
lambdabot left
15:40
lambdabot joined
15:42
lumi joined
15:43
b_jonas left
15:44
Lorn_ joined
15:50
jan_ left
15:51
justatheory joined
15:57
Lorn left
16:11
zamolxes joined
16:16
b_jonas joined
16:35
zamolxes left
16:56
Schwern left
17:02
ruoso joined
|
|||
ruoso | @tell pmurias, please remember of adding your changes to the Changelog in the smop wiki | 17:08 | |
lambdabot | Consider it noted. | ||
17:10
cain_22 left
17:13
nipotaway is now known as nipotan
17:48
kanru left
17:49
pmurias joined
|
|||
pmurias | ruoso: rehi ;) | 17:50 | |
ruoso | pmurias, hi | ||
pmurias | the changelog should contain only full changes ? | 17:51 | |
pugs_svn | r21306 | ruoso++ | [smop] More advances in p6opaque_methods. skeleton for the p6opaque methods array proxy object | ||
ruoso | pmurias, not really... I tend to log as something advances, even if not finished yet... | ||
my idea is that someone would have how to help in this something I still am working on | 17:52 | ||
pmurias | why do we need a changelog, isn't svn log enough? | ||
ruoso | hmmm... well... | ||
I don't know... to have it side-by-side with the roadmap? | |||
for instance... you're working in a lowlevel hash | 17:53 | ||
that is in the roadmap... | |||
pmurias | ruoso: any other reasons? | 17:57 | |
ruoso | it will also serve as a report on the progress for the grant | 17:58 | |
pmurias | having the svn log side by side could be arranged | ||
ruoso | pmurias, I know... but I usually don't add in the changelog as often as I commit... | ||
Usually, for an unfinished activity, I log once a day | |||
18:01
rindolf left
|
|||
pmurias | food& | 18:03 | |
ruoso: once i finish the Hash i'll add my changes to the changelog | 18:09 | ||
ruoso | that's cool | 18:10 | |
pmurias | ruoso: i haven't finish it yet ;( | ||
* finished | |||
ruoso | no problem... | 18:11 | |
pmurias | it's strange that $a eq $b compiles to &infix:<eq>($a,$b) not to $a.infix:< | ||
18:11
rindolf joined
|
|||
pmurias | sorry, it's the reverse actually | 18:11 | |
rindolf: hi | |||
how is your lisp dialect | |||
? | |||
rindolf | Hi pmurias | 18:12 | |
pmurias: what's up? | |||
pmurias: it's in deep design stages. | |||
pmurias: and it would be hard for me to work directly on Parrot. | |||
Because I'm banned from both IRC and email. | |||
pmurias | rindolf: you can write a smop backend (once smop matures a bit) | 18:13 | |
rindolf | pmurias: ah. | ||
pmurias: what is smop? | |||
ruoso | rindolf, www.perlfoundation.org/perl6/index.cgi?smop | 18:15 | |
lambdabot | Title: SMOP / Perl 6 | ||
rindolf | ruoso: checking. | 18:16 | |
My Internet is stupid now. | |||
pmurias | my internet is stupid two after the so called upgrade | ||
rindolf | pmurias: not sure I understand what it is exactly. | 18:17 | |
pmurias | * stupid too | ||
rindolf: it's a vm/interpreter | 18:18 | ||
rindolf | pmurias: ah. | ||
ruoso | rindolf, it's actually a runtime library for Perl 6 very much in the same sense perl 5 is the runtime library for Perl 5 | 18:19 | |
rindolf | ruoso: ah. | 18:20 | |
ruoso | several ideas were stolen from the p5 runtime... | ||
18:20
Alias_ left
|
|||
pmurias | ruoso: how should i pass a value from a q:sm0p {...} to the enclosing C? | 18:24 | |
ruoso | you don't | ||
because the code inside q:sm0p won't be executed at that time | 18:25 | ||
so you can't get the value from that result | |||
you can have a callback method in your object | |||
that will receive the value you want | |||
and do something about it... | |||
take a look at the p6opaque DESTROYALL code... | |||
pmurias | a SM0P_RUN(q:sm0p {...}) would be handy | 18:26 | |
ruoso | pmurias, you don't want to do that | ||
because you will be recursing in the C stack | |||
and that's a bad thing when you want to interact with interpreted code | |||
pmurias | ruoso: interpreted code = sm0p? | 18:27 | |
ruoso | yes | ||
sm0p is interpreted in the interpreter runloop | 18:28 | ||
that's why I always return immediatly with false from the functions where I have a sm0p block | |||
to let the interpreter call the sm0p instructions later | |||
pmurias | callbacks and c don't play very well | 18:30 | |
ruoso | why not? | ||
but you can always think of your callback as a method call | 18:31 | ||
as I do in p6opaque.DESTROYALL | |||
which in the sm0p block calls .^!DESTROY | |||
that call is received as a standard method call... | 18:32 | ||
pmurias | i'll have to implement sm0p labels ASAP | 18:36 | |
ruoso | pmurias, yes... it's starting to be a real pain | 18:37 | |
pmurias | will need something like SM0P_RUN if we want sm0p to be embeddable | 18:38 | |
ruoso | but you can call loop on the interpreter | 18:39 | |
as the tests do | |||
but you shouldn't do that inside the code... | |||
18:39
tuxdna joined
|
|||
ruoso | because you would be recursing in the C stack | 18:39 | |
18:40
Alias_ joined
|
|||
pmurias | re callbacks c doesn't even have closures and complex control flow gets turn into state machines | 18:40 | |
* turned | |||
ruoso: the Hash is temorary | 18:41 | ||
ruoso | pmurias, but you have a capture that you can build in the sm0p block and call your method | ||
instead of returning the value, use it as a parameter to a method call | |||
you can build the capture in the sm0p block | |||
and receive the value in the other dispatch call | 18:42 | ||
pmurias | the sm0p call is in a loop | ||
18:44
gaal joined
|
|||
pmurias | the s1p Hash will be replaced by a Hash in perl6 shortly after in the initialisation sequence | 18:44 | |
18:44
Exodist joined
|
|||
ruoso | pmurias, but still, recursing in the C stack is a bad idea... | 18:44 | |
pmurias | i don't think any body will be calling continuations at this stage | 18:46 | |
ruoso | pmurias, smop is doing it already | 18:47 | |
smop_lowlevel counts on continuations... | |||
it already uses Continuation-Passing-Style | |||
that's how it intercepts the execution to call DESTROYALL | |||
pmurias | i'm using only constat identifiers keys than | 18:49 | |
* constant | |||
ruoso | that's an acceptable restriction for the moment | ||
no object is accepting non-constant idenfier for method dispatch yet | 18:50 | ||
pmurias | shower& | 18:51 | |
18:59
Alias__ joined,
Alias_ left
19:02
chris2 left
|
|||
pmurias | ruoso: how do you plan to achive half-decent performance with smop? | 19:03 | |
ruoso | pmurias, by someday replacing SLIME with something less lame | 19:04 | |
but do you think the performance is too bad already? | 19:05 | ||
I still couldn't find anything worth benchmarking | |||
pmurias | ruoso: we don't execute anything yet, and most of the objects are still in C | 19:11 | |
ruoso | I think test/14 will already give us some idea on how heavyweight it is, since the method dispatch will already be delegated by non-c code... | 19:13 | |
pmurias | was just comparing the way we do things with parrot | ||
ruoso not used to handle parrot... | 19:14 | ||
how do we do things with parrot? | 19:15 | ||
pmurias | i meant i compared the way we do things with the way parrot does them | ||
ruoso | and I meant, how do parrot do them? | 19:16 | |
;) | |||
pmurias | faster | ||
; | |||
) | |||
they have vtables, int and string registers | 19:17 | ||
ruoso | hm... but they still don't know how they will handle representation polymorphism | ||
19:17
tuxdna left
|
|||
ruoso | I was talking with jonathan some time ago, and they're assuming they'll find a way to handle it | 19:18 | |
pmurias | handle is as a special case most likely | ||
s/is/it/ | 19:19 | ||
19:19
Chillance joined
|
|||
ruoso | but if the vtable is visible to the interpreter... there isn't really a way to special case it | 19:19 | |
(of course they are probably smarter then me and they'll find a way... but I just can't think on a way to do it) | 19:20 | ||
pmurias | you could use SMOP_OBJECT's as pmc if you want | ||
19:20
barney left
|
|||
pmurias | ruoso: the vtable contains only the most common methods | 19:20 | |
ruoso | the most common being? | ||
smop abstracts one more level | 19:21 | ||
spinclad | i expect vtables will not map one-to-one with .HOWs | ||
19:22
Alias__ left
|
|||
ruoso | spinclad, I'm not sure about it... but afaics... it's something like that... | 19:22 | |
pmichaud and [particle] could probably shed a brighter light on it | |||
pmurias | ruoso: the most common ones are the ones parrot developers feel will be called most | 19:23 | |
ruoso | pmurias, but at which level? | ||
pmurias, is it just an optimization? | 19:24 | ||
pmurias | MESSAGE in smop terms | ||
sort of | |||
it's designed in | |||
ruoso | except that in smop, the vtable is abstracted inside the message call | ||
pmurias | which is slower | ||
ruoso | but might be required to support different representations | 19:25 | |
which in turns can result in faster again | |||
because I can use optimized low-level values as if they were standard objects | |||
pmurias | the parrot folks can to | ||
ruoso | well... | 19:26 | |
as I said... I'm not really aware on the internals of parrot... | |||
pmurias | they sort of assume standard objects are optimized low-level values | ||
ruoso | but from what I've talked with jonathan, they still didn't sort out how to deal with different representations... | ||
pmurias | * as special case of optimized low-level values | ||
19:27
Alias_ joined
|
|||
spinclad | vtable perhaps corresponds with responder interface | 19:27 | |
pmurias | spinclad: no | ||
ruoso | spinclad, that's what smop does | ||
spinclad | no? | ||
ruoso | parrot is one level more concrete | 19:28 | |
pmurias | spinclad: sort of yes | ||
;) | |||
ruoso | smop is one level more abstract | ||
spinclad, the vtable in parrot is exposed, in object is hidden inside a responder interface | |||
pmurias | spinclad: they are responder interfaces with hard coded common operations | ||
ruoso | s/object/smop/ | ||
spinclad | the vtable is exposed to parrot opcodes, unlikely (as i see it) exposed to Perl 6 (or other HLL) level | 19:29 | |
ruoso | pmurias, it would be like if we take the lookup inside the message calls of smop and turn it into some static vtable lookup | ||
the difference is one level of abstraction | 19:30 | ||
spinclad | sorry, is exposed to parrot opcode dispatch, as RI is to operation invocation | 19:31 | |
ruoso | but again.. I'm not familiar with parrot internals... pmichaud and [particle] would probably give a correct explanation on that | 19:32 | |
pmurias | ruoso: but if an operation is not in the hard-coded set it's handled by a special method code operation, just as in sm0p | 19:33 | |
ruoso | pmurias, which means that in the end parrot will need as much indirection as smop does? | 19:34 | |
pmurias | for the less common operations yes ;) | ||
19:35
Jedai joined
|
|||
ruoso | is the vtable subject to cache invalidation or something like that? | 19:35 | |
pmurias | it's propably pmc specific | 19:36 | |
i haven't seen one with cache invalidation but i haven't looked much | |||
spinclad | if you replace a sub it points to? you may generate a new vtable and start using it; don't think that's a core operation now. | ||
ruoso | well... | ||
btw... it's intersting to make clear that I really think parrot in the end will be a full fletched vm that supports Perl 6 entirely... but one core feature (representation polymorphism) is not addressed yet... | 19:39 | ||
[particle] | parrot has four core data types, with register types to support each: int, num, string, pmc | ||
pmc is an abstract data type | |||
each core data type can be converted to the other, for example $I0 = $S0 | |||
parrot uses ops for this | 19:40 | ||
set_i_s $I0, $S0 | |||
pmurias get back to coding seeing much more competent people took up the discussion ;) | |||
[particle] | these are hardcoded for int num string types | 19:41 | |
spinclad | i think vtables apply only to pmcs? | ||
[particle] | since pmcs are abstract, the vtable is there to allow pmc writers the ability to write their own functions | ||
for example to convert pmc to int | |||
set_i_p $I0, $P0 | 19:42 | ||
this calls the pmc's get_integer vtable function | |||
$I0 = $P0.'get_integer'() | |||
all pmcs inherit from default.pmc to get some common methods | |||
and all vtable methods can be overridden | 19:43 | ||
freeze, thaw, init, invoke, get_string, etc | |||
additionally, pmcs can have attributes and methods | |||
19:43
rindolf left
|
|||
[particle] | for example, the p6meta pmc has a 'register' method to register a class | 19:44 | |
so, you're not limited to use vtable functions in your pmcs | |||
spinclad | for get_attribute operation, does this go through the vtable? | ||
[particle] | in fact, the Exporter pmc (for namespace export) only uses methods, no vtable functions | ||
(other than freeze/thaw) | |||
get_attribute is a vtable function. | 19:45 | ||
ruoso | get_attribute meaning high-level object attributes? | 19:46 | |
[particle] | meaning pmc attribute | ||
pmc is an abstract data type. it defines an structure and an api | |||
spinclad | mid-level anyway; not necessarily high-level | ||
ruoso | let me rephrase | 19:47 | |
is get_attribute vtable function going to be used to fetch the attribute of some Perl 6 Object? | |||
or that is never part of the HLL runtime... | 19:48 | ||
spinclad | yes, 'has $.x' translates to a pmc-level attribute | ||
and accessing it to get_ and set_attribute | |||
[particle] | actually, get_attribute is a macro | 19:49 | |
something like SET_ATTR_ns_src(interp, SELF, src); | |||
19:49
lde joined
|
|||
[particle] | sorry, GET_ATTR_ns_src(interp, SELF, tmp_ns_src); | 19:49 | |
spinclad | (at C level?) | ||
[particle] | yes | ||
this is converted to PMC *tmp_ns_src = exp->ns_src; | 19:50 | ||
where exp is Parrot_Exporter *exp = PARROT_EXPORTER(pmc); | |||
Parrot_Exporter is a c struct | |||
pointer | |||
obviously :) | |||
ruoso | so every PMC must have the same Parrot_Exporter struct format... | 19:51 | |
[particle] | i mean, exp is a pointer. uggh | ||
every Parrot_Exporter has the same format | |||
this is for exporter.pmc | |||
float.pmc has a Parrot_Float struct | |||
ruoso | so the attribute lookup is static... | ||
[particle] | the pmc header is the same struct everywhere | ||
spinclad | (i would say 'details, details', but some of the details at least matter for judging how things map between smop and parrot) | 19:52 | |
[particle] | the pmc data segment is different, based on the attributes it contains | ||
ruoso | but the attribute-lookup-process is static, I mean | ||
[particle] | what do you mean by static? | ||
ruoso | meaning that if you have a Glib object, you need to make a proxy object that map the glib object attributes to pmc attributes | 19:53 | |
[particle] | yes, then you do your access through the proxy | ||
spinclad | the glib object might be a single attribute | ||
ruoso | that's the major difference between parrot and smop | ||
[particle] | but it's not an incompatible difference | ||
ruoso | sure... | 19:54 | |
but it's the same difference smop has from perl 5... | |||
one more level of abstraction... | 19:55 | ||
in smop, the attribute lookup will be entirely delegated to glib | 19:56 | ||
spinclad | one difference i see: the RI for an object need not be found at a fixed slot in it; as long as at invocation time you have the object and its RI, you can invoke an operation of it | ||
ruoso | yes... and that's everything smop defines... not a milimeter more... | 19:57 | |
everything is delegated to the object itself, not a single static lookup.... | 19:58 | ||
(except for the RI, of course)... | |||
spinclad | as in haskell the type of an object need not be stored in it, and may be compiled away entirely | 19:59 | |
merely implicitly known throughout the code | |||
ruoso | that's where the one more level of indirection might buy extra room for optimization... | ||
pmurias | ruoso: i'm giving up on writing hash tests and hacking in labels to get rid of those stupid integers | 20:00 | |
ruoso | pmurias++ heh | ||
that's why it's called SLIME ;) | |||
pmurias | the target integer in capturize is relative forward :( | 20:01 | |
ruoso | pmurias, yes. | ||
20:02
icwiener joined
|
|||
ruoso | spinclad, for instance... in p6opaque, the REPR api returns other objects... but this objects will belong to the p6opaque "community", which means that they will know the internal format of p6opaque and navigate directly in it... but the interpreter doesn't know about it, so it is still completely dynamic... | 20:02 | |
in fact... the only way to get instances of the other types of the p6opaque "community" is by calling p6opaque REPR methods | 20:03 | ||
pmurias | ruoso: it's possible to that in parrot too | ||
sometimes you will just end up having an extra layer of indirection to esacape the optimalisation | 20:04 | ||
* escape | |||
ruoso | anyway... I think it doesn't matter if smop is superceded by parrot in the very near future... the experience of stressing the representation polymorphism is already fruitfull enough imho... | 20:07 | |
spinclad | then in the interpreter either you pass around two things for the object (object and RI) or you put together one (p6opaque?) thing that refers to both | 20:08 | |
ruoso | spinclad, actually every smop object either has a RI or is a RI | ||
p6opaque implements the REPR api | 20:09 | ||
spinclad | 'has an RI': perhaps implicitly? does it have to be represented in its storage footprint? | ||
ruoso | spinclad, in smop, yes... | 20:10 | |
20:10
nothingmuch left
|
|||
ruoso | spinclad, I couldn't think on a way of doing it other way... | 20:10 | |
spinclad, www.perlfoundation.org/perl6/index...._bootstrap | 20:11 | ||
lambdabot | Title: SMOP OO Bootstrap / Perl 6 | ||
spinclad | an int object, for instance: when used in a community where its RI is known to be Int_RI (say), that could be supplied whenever an operation on it happens | ||
and the int itself takes up just its 2^n bits | 20:12 | ||
ruoso | but how do you introspect? | ||
pmurias | ruoso: re superceded, do you plan on throwing away smop? | ||
spinclad | i.e. in the scope of my int $n | ||
ruoso | pmurias, not really... in fact I think smop will merge with p5 loop somewhere in a not-so-far future | ||
and I think smop will be specially succesfull in the p5-p6 bridge | |||
spinclad, hm... the thing is that in smop even the interpreter is a SMOP__Object* | 20:13 | ||
spinclad | introspection is just such operations, you supply the Int_RI (at least implicitly) and do introspection ops through it | ||
ruoso | spinclad, probably some optimizations could be done like that... | 20:14 | |
but the standard is that the object must be self-contained | |||
pmurias | spinclad: as i have it planned such optimalisations belong to the JIT | 20:15 | |
s/to/in | |||
spinclad | if by 'the standard' you mean the same as 'outside its community, e.g. the interpreter', i agree, it will need some wrapping then | ||
ruoso | yes... but inside p6opaque, for instance, the additional data that builds p6opaque is not SMOP__Object* | 20:16 | |
the objects in the same "community" can use the data as plain C structs... | 20:17 | ||
spinclad | agreed | ||
ruoso | spinclad, but a simple test like if (SMOP_RI(foo) == SMOP__NATIVE__int) | ||
allows me to call C-level functions for native types | |||
instead of high-level method calls | 20:18 | ||
and that is how SMOP is bootstrapping its type system | |||
by special casing the known responder interfaces | |||
and using the high-level calling convention otherwise | 20:19 | ||
for instance... | |||
spinclad | at that point, within the community, that '(SMOP_RI(foo) == SMOP__NATIVE__int)' constant-folds to 'true' | ||
ruoso | yes... | ||
in smop_lowlevel.sm0p | |||
spinclad | and if you have to ask what its SMOP_RI is, you're not a full insider | 20:20 | |
ruoso | if the object is SMOP__NATIVE__int, the destruction code recurses in the C stack, otherwise it uses CPS to call DESTROYALL on the object... | ||
spinclad, although it's probably a good idea to always ask that, to avoid segfaults... | 20:21 | ||
pmurias | what is a good label sigil? | ||
spinclad | i see great potential to compile away overhead here | ||
ruoso | pmurias, ^\s*([A-Za-z]): ? | 20:22 | |
ah... you mean to use the label later... | |||
can you use bare word? | 20:23 | ||
pmurias | ruoso: not really | ||
ruoso | and check for a label before assuming it's a constant identifier? | ||
spinclad | (another representation: foo lives in a pair of variables/registers, $foo and ^$foo; SMOP_RI(foo) -> ^$foo) | ||
pmurias | ruoso: i can only check for a label after assuming it's a constant identifier | 20:24 | |
[particle] | can you use the colon? | ||
ruoso | spinclad, except that ^$foo means $foo.HOW which is something completely different... | ||
spinclad | (if all references to the latter in the code get constant-folded away, the register can go too) | ||
pmurias | [particle]: you mean $SMOP__SLIME__CurrentFrame.move_responder(:foo,:bar); ? | ||
ruoso | I like that | 20:25 | |
[particle] | yeah, that | ||
spinclad | sorry, i do mean the low-level SMOP_RI, not the high-level .HOW here | ||
ruoso | except that it looks like named arguments | ||
but that's ok for sm0p | 20:26 | ||
[particle] | you can use ` | 20:27 | |
that's reserved for the user, so not in any normal perl 6 | |||
ruoso | spinclad, anyway... compiling away overhead happens all the time in smop... it happens by hand yet ;) but it does | 20:28 | |
and it's actually the way smop is bootstrapping the type system | |||
spinclad | (sure, it has to be, to break the meta-loop) | 20:29 | |
(the MOP loop) | |||
ruoso | spinclad, have you seen the SMOP slides? | 20:30 | |
pmurias | ruoso: :label or `label? | ||
spinclad | i read at least part way through them, sometime in the spring | ||
ruoso | pmurias, `label... :label is named arguments (although sm0p doesn't support it) | ||
spinclad, please, consider taking another look, after this conversation it will probably have another meaning ;) | 20:31 | ||
spinclad | sure. i also got partway through the wiki pages but got bogged down by a slow browser... i'll read them again in links (much easier i expect) | 20:33 | |
pmurias | spring? are the SMOP slides so old? | 20:35 | |
spinclad | unless i misremember, which is not at all unlikely, i thought there was some slide set early on. please remind me of a best slide set's URL? | 20:38 | |
might as well read afresh or anew, whichever it be. | 20:39 | ||
(misc/sm0p/README could use a pointer to the wiki at least) | |||
pmurias | ruoso: what was the slides url? ;) | ||
ruoso | pmurias, the wiki has a link | 20:40 | |
pmurias | spinclad: misc/sm0p/ is not smop | ||
ruoso | spinclad, the sources are in v6/smop | ||
pmurias, moving misc/sm0p to v6/smop/sm0p is probably a good idea | |||
pmurias is trying to get label to work | 20:41 | ||
spinclad | thanks | ||
(i've been in there before, and keep forgetting. forget me own head next.) | 20:42 | ||
pmurias | i can only one label per q:sm0p to parser, argh | 20:56 | |
even though i have <node_with_label>* | 20:58 | ||
pugs_svn | r21307 | ruoso++ | [smop] $p6opaque.^!methods() works. "push" and "shift" are not implemented yet, but the test metaclass already tries to call the method. three values leaking atm. | 21:02 | |
pmurias | i'll attempt labels in the near future again (tommorow likely), in the meantime if anybody is intrested feel free | 21:04 | |
21:07
rdice_ left
|
|||
ruoso home & | 21:08 | ||
21:08
ruoso left
21:13
cggoebel left
21:16
donaldh joined
|
|||
pugs_svn | r21308 | pmurias++ | [smop] primitive label support | 21:16 | |
pmurias | got something working somehow... | 21:17 | |
sleep& | |||
21:17
pmurias left
21:29
donaldh left
21:41
Alias_ left
21:43
jan__ joined,
hercynium left
21:50
Exodist left
21:53
iblechbot left
22:33
Jedai left
22:58
armagad joined
23:06
yewenbin joined
23:20
alester left
23:23
Alias_ joined
23:26
silug left
23:40
cmarcelo left
23:43
nothingmuch joined
23:47
Chillance left
23:54
jhorwitz left
|