»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, niecza:, std:, or /msg p6eval perl6: ... | irclog: irc.perl6.org/ | UTF-8 is our friend!
Set by sorear on 4 February 2011.
00:11 mtk left 00:16 cdarroch left 00:19 mtk joined
donri can rakudo compile to pbc? 00:20
00:22 gdey_ left
sjohnson i wish Clippy from Microsoft Office was real so i could torture it to death 00:24
flussence_ just get a paperclip and draw eyes on it 00:25
sjohnson flussence_: or watch this video: www.youtube.com/watch?v=F6aXzMuYN7U ;)
lue Hello world o/ , and my condoloences (hope that's spelled right) to Japan. 00:35
00:35 nymacro left 00:36 araujo joined 00:41 icwiener left
Tene donri: iirc there are a few things left out of the generated pir for it to stand alone, but I don't know if they've been addressed since I last looked at it a year or two ago. 00:42
phenny Tene: 11 Mar 17:06Z <jnthn> tell Tene to post gsoc proposals
Tene: 11 Mar 23:47Z <jnthn> tell Tene got distracted hacking on other bits, but will write the REPR for you tomorrow 00:43
donri Tene: yea i tried --target=pir but parrot won't compile or run *that*
Tene donri: you'll want to run: perl6 --target=pir foo.pl > foo.pir; parrot -o foo.pbc foo.pir
donri: then there's shit missing from the pir
load_language perl6, some kind of loadlib, something like that
flussence_ lue: could've been worse - they really know how to build stuff to last. www.youtube.com/watch?v=JhJzdtzl6KY 00:44
donri Method 'Bool' not found for invocant of class 'Integer'
shit like that
do i need to point parrot to the perl6 pbc or somethingsuch? 00:45
Tene donri: no, that just means that perl6.pbc hasn't been loaded by the generated pir, and it should be. 00:46
17:43 < Tene> load_language perl6, some kind of loadlib, something like that
lue flussence_: can't watch it, but I know what you're talking about. I guess it's 'cause of the fact that Tokyo gets blown up all the time :) .
donri .loadlib 'perl6_ops'
.HLL "perl6" 00:47
Tene when rakudo is compiling, it doesn't produce instructions to call load_language because perl6.pbc is already loaded at that point. It's a bug.
donri: .HLL just sets a namespace; it doesn't load anything.
donri can i edit the pir manually perhaps
Tene You want to call the load_language op, as I keep saying.
Sure. 00:48
donri yea sorry i didn't understand that suggestion
it's actually doing that already in some sub "" 00:50
Tene Ahh, sorry, yeah, load_language is a parrot opcode (with a troubled history).
donri: you probably need to call it from a .sub with the :load :init flags 00:51
donri yea it's there
oh well :) was just playing 00:53
sorear psst. niecza can compile to .exe. 01:04
donri ;)
01:11 alester joined 01:16 ashleydev joined 01:57 bbkr_ left 02:01 noganex_ joined, risou joined 02:04 noganex left 02:11 envi joined 02:18 s1n joined 02:22 risou_ joined 02:25 risou left 02:36 alester left 02:37 risou_ left 03:08 bbkr_ joined
mberends rakudo: say now.to-posix[0]; say now.to-posix[0]; 03:20
p6eval rakudo a38d45: OUTPUT«1299900021.59199␤1299900021.7819␤»
mberends rakudo: say now.to-posix[0] ~ " " ~ say now.to-posix[0]; 03:21
p6eval rakudo a38d45: OUTPUT«1299900103.08304␤1299900102.80241 Bool::True␤»
mberends rakudo: say now.to-posix[0] ~ " " ~ now.to-posix[0]; 03:22
p6eval rakudo a38d45: OUTPUT«1299900119.07637 1299900119.27599␤»
03:28 aindilis left, aindilis joined
dalek kudo: b922c21 | mberends++ | Test.pm:
[Test.pm] change pir::time__N() to now.to-posix[0] for portability
 03:38
03:47 shachaf left 04:08 worrtemp joined 04:09 whiteknight left 04:11 shachaf joined 04:38 cosimo joined 04:47 s1n left 04:56 s1n joined 05:00 TheMartianGeek joined 05:15 coldhead is now known as temp0l 05:16 temp0l is now known as sorry, sorry is now known as soldhead 05:17 donri left 05:21 soldhead is now known as coldhead
worrtemp is there any desire for a build system for perl6 modules modeled after Module::Build? 05:39
I know about ufo and pseudo-package managers like proto and pls, but there are problems with all of them, and they don't really meet my needs 05:40
Tene worrtemp: Yes, there is.
05:40 orafu left 05:41 orafu joined
worrtemp neat, glad it isn't just me 05:41
I started working on one today, and I was just curious if the community would care, or if it would just remain a side project 05:42
05:47 s1n left, coldhead left 05:48 s1n joined
mberends worrtemp: your efforts would be very welcome. If possible, please try to also take into account multiple Perl 6 implementations such as Rakudo and Niecza, there is a lot of emerging work happening on that front. 06:04
worrtemp I'm writing for rakudo right now - I hadn't heard of niecza. I'll def give that a look after I've implemented the basic features for rakudo. 06:16
06:17 kaare_ joined 06:22 TheMartianGeek left 06:30 kaare_ left
sorear hi worrtemp 06:35
niecza: say "foo".IO.relative("bar") 06:37
p6eval niecza v3-67-geec33bf: OUTPUT«bar/foo␤»
06:41 risou joined 06:50 woosley joined
mberends niecza: say now.to-posix[0] 06:53
p6eval niecza v3-67-geec33bf: OUTPUT«===SORRY!===␤␤Action method term:sym<now> not yet implemented at /tmp/sO0PFJBzsV line 1:␤------> say now⏏.to-posix[0]␤␤Unhandled exception: Check failed␤␤ at /home/p6eval/niecza/boot/lib/CORE.setting line 387 (CORE die @ 2)␤ at
../home/p6eval/ni…
mberends sorear: I'm ready to try making a contribution to Niecza ^^
worrtemp sorear: niecza is looking really cool. how complete is it looking as far as implementing the spec? 06:54
Tene worrtemp: It's generally not as featureful as rakudo, but there are a few places it implements spec that rakudo doesn't yet. 06:58
I don't recall the details, unfortunately. I'd really like to look into niecza more, but haven't had the time.
07:01 justatheory left
worrtemp is at least more conformant than rakudo is? there a few places where rakudo seems to play fast and loose with the spec 07:05
tadzik worrtemp: whatcha writing actually? 07:13
Tene worrtemp: having *an* implementation of something is a lot closer to conformant than no implementation 07:14
07:14 Khisanth joined
worrtemp Tene: that's true. it just makes it difficult to code when the interpreter doesn't match the spec :) but that's what's nice about having the source so readily available 07:16
tadzik: I'm writing a build system that's kind of modeled after Module::Build. there are things I don't like about many of the existing ways of building/installing perl6 modules, so I thought I'd step up and write my own implementation 07:17
mberends Tene: thanks for the magpie reference a few days ago. It triggered me into an interesting investigation of Top Down Operator Precedence parsers. 07:18
tadzik I'm looking forward to see that 07:20
07:23 risou_ joined 07:24 risou left
sorear mberends: hi! I'd love to help anyway I can. 07:25
mberends :) soon 07:26
sorear how soon?
mberends today
sorear (I ask because it's t-(at most 4 hours) for me to sleep)
mberends your tomorrow
sorear is refactoring Op::SubDef... trying to figure out the sanest way to handle weird general combinations like "our multi method" 07:27
07:29 risou_ left 07:30 risou joined
worrtemp tadzik: thanks! hopefully I should be able to pound out an alpha version by wednesday 07:34
Tene mberends: "magpie reference"? 07:44
worrtemp: If you find ways that rakudo deviates from the spec, it would be great if you could file bug reports and/or contribute spectests. 07:45
tadzik worrtemp: sounds good. What exactly don't you like about the current solutions? 07:46
worrtemp Tene: yeah, I'll start writing patches for those parts sometime this week 07:48
tadzik: one of the bigger problems I've encountered is that it's difficult to install perl6 modules in non-standard environments 07:49
I'm running exherbo (think Gentoo), and since my parrot was built in a chroot, perl6's $*VM<libdir> and etc are off. I'd like an easy way to change that at build time 07:50
mberends irclog.perlgeek.de/perl6/2011-02-14#i_3291361 (you should read it ;)
Tene: ^^ 07:51
tadzik worrtemp: that's probably due to the lack of non-standard users. I once adapted neutro to work on windows, but there was no one to test it anyway
worrtemp yeah, I can understand. I'm a non-standard user, so that's why I'm writing a solution that can handle my case. :)
tadzik I see :)
but you could just point out your problems with the current solutions and we'll all benefit from it 07:52
But I understand your approach, I wrote neutro months ago because no module installer was working and I needed to install modules :) 07:53
worrtemp also I want more configurable dependency handling. I'd like to differentiate between build deps and run deps, and also add support for conflicts and recommends
and honestly, I don't want a depency on make 07:57
07:58 mtk left
worrtemp yeah, if people want to use it, then they will. I'm mostly doing it for my own sake right now. I jsut wanted to see if other people would be interested 07:58
tadzik there is no dependency on make nowadays 07:59
since September 12 as I see
Tene sorear: there *should* be compositional semantics there, instead of any unusual exceptions. If that's not the case, I recommend spec patches. 08:00
worrtemp: There have been issues in the past with rakudo relying on parrot's build dir being left around; I don't recall if they've been fixed or not. 08:01
08:05 mtk joined
sorear worrtemp: you want it to work in any case... so you're only considering one implementation in the design? I don't follow. 08:08
sorear out. 08:10
worrtemp tadzik: proto/pls don't, and ufo does. I don't like how proto does automatic fetching of modules. I'd rather have authors include something akin to Build.PL that acts as a richer/more cross-platform make replacement
sorear: yeah, I didn't know about niecza until you mentioned it. I'd like to get a quick and dirty working impl that works with rakudo, and then add in support for niecza after I get something working 08:12
tadzik worrtemp: feel free to criticise Pies/panda all the way you want, I can't quite speak of the ones you mentioned. The idea of ufo is to be make dependant, mbuild from Module::Tools was quite similar in the effect, but pure-perl, but not sure if it's not EBROKENASHELL
if that sounded weird: I'm open to constructive criticism about Pies 08:13
worrtemp I haven't heard of/played with pies or panda. I've just seen and used proto/pls, ufo, and Module::Tools, as well as some janky custom build scripts. 08:15
regardless, I'm going to write my own to test out my ideas. if panda/pies does what I want better, I'd love to help/contribute ideas. but at the very least I think this will be a fun project for myself. 08:18
08:19 nymacro joined
tadzik sure 08:22
worrtemp I'm sorry if I'm coming off as disrespectful or anything; I don't mean to. I'm just excited to write something like this 08:28
tadzik hey, no disrespect :) 08:32
08:32 bartolin left
tadzik glad to see youu amongst the Warriors 08:32
08:52 _twitch joined, maxs42 joined 08:56 Mowah joined 08:58 maxs42 left 09:03 cosimo left
moritz_ good morning Warriors from the Cult of the Zebra 09:24
colomon \o 09:29
09:37 masak joined
masak good Saturday, zebras. 09:38
moritz_ not a good Saturday in .jp, I fear :( 09:47
09:51 GinoMan joined
jdhore indeed, sadly :( 09:52
Although better than yesterday probably, to be honest
09:53 kfo joined
moritz_ I'm not sure (re nuclear reactors) 09:53
masak what was that thing with the nuclear reactor?
moritz_ insufficient cooling, an explosion 09:54
possibility of a meltdown
jdhore Basically, one of the largest nuclear reactors in the world which is in Japan may be about to have a meltdown
09:54 worrtemp is now known as worr
jdhore But I don't think it'll be a big deal because things are actually engineered well in Japan 09:54
moritz_ www.dnaindia.com/world/report_japan...00_1518951 09:55
jdhore: engineering can only do so much
you know, in .de a nuclear power plant has a 16 times redundant cooling system -- I guess it's much the same in .jp 09:56
jdhore True, but it won't have nearly as big an impact as say Chernobyl
moritz_ at least 8 of which don't need power supply to work
if those fail, what can think of the rest of the system?
jdhore Chernobyl was as much of a wreck as it was, and the zone of exclusion (radiation zone) is only like 30km
masak --> grocery store 10:14
10:27 risou_ joined 10:29 risou left 10:32 woosley left 10:53 isBEKaml joined 11:05 GinoMan left 11:08 whiteknight joined 11:12 starcoder2 joined 11:17 fisted_ is now known as fisted 11:28 risou_ left 11:29 risou joined 11:36 MayDaniel joined
jnthn morning o/ 11:49
masak good afternoon, jnthn. :) 11:50
11:52 risou_ joined
jnthn :P 11:53
11:55 risou left 12:29 zby_home joined 12:30 whiteknight left 12:42 risou_ is now known as risou
Tene morning 12:47
masak Tene: \o 12:54
13:05 cls_bsd left 13:07 isBEKaml left 13:12 cjk101010 joined 13:26 cjk101010 left 13:32 cjk101010 joined 13:33 Axius joined 13:37 Axius left, nadim joined 13:38 Axius joined 13:39 MayDaniel left 13:42 nadim left, nadim joined 13:47 nadim_ joined, nadim left 14:03 PacoLinux left 14:04 PacoLinux joined
masak here's a legitimate (maybe even excellent) reason for nesting classes in Perl 6: 14:17
inner classes gaining access to lexical variables in the outer class scope.
p5-colomon's $.node-count would have been an excellent example. 14:18
only methods of the outer class and one of the inner classes ever use the attribute. had it been a lexical, its scope would have been narrower, in some sense. and things outside of the outer class wouldn't have been able to get at it. 14:19
jnthn Would you make the inner class lexically scoped? 14:20
Should work etiher way but seems lexical inner classes may be the safe way to go 14:22
As then you know the variable was initialized.
dalek kudo: 778601a | kyleha++ | Test.pm:
[Test.pm] Enable Null PMC test in dies_ok
kudo: a357c9f | kyleha++ | Test.pm:
Merge branch 'master' of github.com:rakudo/rakudo
14:23 plobsing left
dalek ast: 3475a05 | (Kyle Hasselbacher)++ | S12-class/attributes.t:
Test for RT81718
 14:24
ast: 566396a | (Kyle Hasselbacher)++ | fudge:
Merge branch 'master' of github.com:perl6/roast
masak jnthn: with real static lexpads, I shouldn't have to care, methinks. 14:26
jnthn: in this particular case, the classes could (and probably should)'ve been lexically scoped.
masak thinks he prefers the term 'my'-scoped
sbp egoscopic 14:28
jnthn masak: You shoudln't have to care, was more curious about what you thought was the right way.
masak jnthn: by the principle of smaller scopes making less damage, I think classes should be 'my'-scoped when they can and 'our'-scoped when they must. even though that goes against the default. 14:29
jnthn masak: I sometimes wonder how long that default will last. 14:30
Then, these days I sometimes wonder why we still have package scope.
masak I hardly ever use 'our'. 14:31
14:38 pmurias joined, Axius left
moritz_ sometimes you want to access stuff without importing it 14:39
masak that's true.
even for classes, you might want the analogue of 'public static final' variables. 14:40
jnthn std: { module Foo { our sub bar() { } }; Foo::bar()
p6eval std 4608239: OUTPUT«===SORRY!===␤Unable to parse block at /tmp/uHc3FVZbC2 line 1:␤------> <BOL>⏏{ module Foo { our sub bar() { } }; Foo:␤Couldn't find final '}'; gave up at /tmp/uHc3FVZbC2 line 1 (EOF):␤------> le Foo { our sub bar() { } };
..Foo::bar()⏏[3…
jnthn std: { module Foo { our sub bar() { } } }; Foo::bar()
p6eval std 4608239: OUTPUT«ok 00:01 120m␤»
jnthn Just checking :)
std: { module Foo { sub bar() { } } }; Foo::bar()
p6eval std 4608239: OUTPUT«===SORRY!===␤Undeclared name:␤ 'Foo::bar' used at line 1␤Check failed␤FAILED 00:01 120m␤»
jnthn Nice. 14:41
14:51 Axius joined 14:55 donri joined 14:58 nymacro left, nymacro joined
masak rakudo: class A { my $x; class B { method foo { say $x } } }; B.new.foo 15:07
p6eval rakudo b922c2: OUTPUT«Any()␤»
masak \o/
rakudo: class A { my $x = 42; class B { method foo { say $x } } }; B.new.foo
p6eval rakudo b922c2: OUTPUT«42␤»
masak rakudo++
niecza: class A { my $x = 42; class B { method foo { say $x } } }; B.new.foo
p6eval niecza v3-67-geec33bf: OUTPUT«===SORRY!===␤␤Undeclared name:␤ 'B' used at line Any()1␤␤Unhandled exception: Check failed␤␤ at /home/p6eval/niecza/boot/lib/CORE.setting line 387 (CORE die @ 2)␤ at /home/p6eval/niecza/src/STD.pm6 line 1141 (STD P6.comp_unit @ 75)␤ at
../home/p6eval/niecza/src/S…
masak niecza: class A { my $x = 42; class B { method foo { say $x } } }; A::B.new.foo
p6eval niecza v3-67-geec33bf: OUTPUT«42␤»
masak niecza++ 15:08
jnthn std: class A { my $x = 42; class B { method foo { say $x } } }; B.new.foo
p6eval std 4608239: OUTPUT«===SORRY!===␤Undeclared name:␤ 'B' used at line 1␤Check failed␤FAILED 00:01 122m␤»
masak rakudo: class A { my $x = 42; class B { method foo { say $x } } }; A::B.new.foo
jnthn really rakudo++?
p6eval rakudo b922c2: OUTPUT«Can not find sub A::B␤ in main program body at line 1␤»
masak maybe not :)
I *think* that rakudobug is in RT already...
15:09 M_o_C joined 15:14 M_o_C left, M_o_C joined
jnthn TimToady: What's the relationship between the stuff in the compiler's view of GLOBAL and the stuff in the GLOBAL that it is constructing during the compilation process? At what point do those become unified? 15:18
TimToady: Concrentely: class Foo { }; eval('class Foo { }; BEGIN say 42') # Output? 15:19
TimToady: Noting that class Foo { }; eval('class Bar is Foo { }; BEGIN say Bar ~~ Foo;') probably should say True 15:21
TimToady: The issue I'm running into is that NQP bootstraps itself, so if you go installing into GLOBAL while compiling (which the second case wants us to) then compiler starts replacing its own symbols it wants to use with partially declared versions as it compiles itself.
15:22 [particle] left
jnthn
.oO( The cannibal compiler... )
 15:23
15:23 M_o_C left 15:25 M_o_C joined
masak om nom nom 15:26
15:29 [particle] joined, envi left 15:33 TheMartianGeek joined
jnthn heh...from Parrot: 15:41
#define INTERN_NS_CREAT 1 /* I'm a fan of the classics */
15:48 GinoMan joined
Tene :) 15:51
15:51 whiteknight joined 15:53 GinoMan left
Tene jnthn: is it actually a requirement for the bootstrapped version to gradually replace the bootstrapping version, or could you just keep them completely independent, and put the bootstrapping version in its own hll ns, for example? 15:54
jnthn Tene: It's more a requirement that they don't influence each other at all. 15:55
e.g. the thing we're compiling and the compiler shouldn't trample each other's symbols 15:56
Other than making everything lexical, though, I'm not quite sure what the right way to do that is.
Tene jnthn: in that case, I recommend putting the bootstrapping compiler in its own hll ns 15:57
TimToady it's worse than just compiler vs runtime; each module starts with its own idea of what's in GLOBAL, and those have to be reconciled at 'use' time 16:02
in STD I had a concept of GLOBALish, which is the nascent GLOBAL space 16:03
so yeah, by and large you don't want the program to confuse its globals with the compiler's
most of the globals that it can see are really in PROCESS instead, like $*PID 16:04
jnthn TimToady: So essentially, a compilation unit has a GLOBAL and when we use it, that's when we merge? 16:06
How does that fit in with eval?
Is an eval seen as use-ish?
masak GLOBAL and UNIT and PROCESS, oh my...
jnthn TimToady: Put another way, if I have a namespace implementation which has a single idea of a "root" namespace, is that going to be pretty unworkable from a Perl 6 perspective, since GLOBAL is kinda context-sensitive, and two of them meeting is always explict (e.g. by virtue of a 'use' happening)? 16:08
16:08 dima_ left
jnthn Tene: I maybe could use the notion of hll namespce to fake that up in a sense... 16:09
Tene: Though it kinda means each compilation unit becomes its own HLL
Tene jnthn: Ahh, I thought you were dealing with a specific bootstrapping scenario, not dealing with solving the problem in general. 16:11
jnthn Tene: Well, I suspect the general problem may have to be solved.
The question is mostly about when I choose to solve it.
On the one hand, I don't want the nom branch to drag on for ages as I solve a load of sorta related things. OTOH, I don't just want to store up a long list of refactors that need doing. 16:12
And things are starting to get a bit...inter-related. 16:13
TimToady how easy would it be to write a compiler that never uses GLOBAL directly, but maybe GLOBAL::COMPILER
pmurias not using globals at all should be possible
jnthn TimToady: It'd be really easy if the compiler could just have its own view 16:14
TimToady: But we have to do bits of runtime at compile time.
So any BEGIN block, for example, needs to have the same notion of GLOBAL as the compiler does
TimToady why?
jnthn class Foo { }; BEGIN say Foo; 16:15
TimToady I think you're using GLOBAL to mean two differen things
jnthn Very possibly. :) Can you elaborate?
TimToady that Foo is not in the compiler's GLOBAL, but in the currently comp unit's GLOBAL
jnthn Gah, yes 16:16
That's what I meant to say
TimToady and BEGIN runs in the comp unit's context, not the compiler's
jnthn Yeah
The problem I have today is that there's a single view of GLOBAL
A...global...one. 16:17
Which is shared between the comp unit and the compiler
Which I guess is the real issue here.
16:18 Patterner left
jnthn I can probably deal with that. Apart from doing so probably means stopping using Parrot's namespaces, or massively perverting the way we use them, which is just as bad. 16:18
Which doesn't bother me
But probably bothers everyone who wants to do HLL interop.
TimToady wonders if the real global space is in PROCESS::GLOBAL, and comp unit globals are just in UNIT::GLOBAL 16:19
jnthn And I'd rather not break that case.
Tene jnthn: no, it shouldn't affect HLL interop at all
16:19 Psyche^ joined, Psyche^ is now known as Patterner
jnthn Tene: Because all importing is done through the Compiler object? 16:19
Tene: Hmm...yeah, maybe it's OK then. :) 16:20
Tene jnthn: at least, it wouldn't have when I had it working before. HLL interop is just a method call on the compiler object, and the method returns something hash-like, approximately.
jnthn Tene: Ah, OK. Well, I'll assume that then, and that object disappears. 16:21
TimToady to the first approx, when you're compiling a comp unit, it has no GLOBAL, only a UNIT::GLOBAL
and all GLOBAL refs find UNIT::GLOBAL by lexical search
jnthn OK. When we then use a module, we look in its UNIT::GLOBAL and grab stuff from it, shoving it into our own UNIT::GLOBAL?
16:22 s1n left
jnthn e.g. that's when the "merge" happens? 16:22
TimToady yeah, you do some kind of unification
jnthn OK
TimToady and carp if there are bad collisions
it's "link time"
jnthn *nod*
TimToady so you can get linking errors
jnthn OK.
Tene jnthn: so as long as the compiler has *a* way of getting a class and exported functions by module name, that's all you need.
jnthn Tene: That sounds workable.
Tene HLLs should not be poking around in each other's internals.
jnthn *nod*
TimToady EXPORT also lives in UNIT 16:23
jnthn Yeah...that was a recent-ish change, though?
16:23 jedai joined
TimToady well, recently documented, but that's how STD did it for longer than that 16:23
jnthn aha
OK, seems I've got...quite a lot...to worry about. 16:24
:)
At least if I solve this all in NQP, it's already solved for Rakudo.
And having just read through Parrot's NameSpace PMC, I'm very happy to stop using it. :) 16:25
TimToady thing is, if you declare with 'my class' there is only UNIT; there's no name in a package to work with, so lexical UNIT it has to be
you always have a lexical pad, even if something is anonymous 16:26
and allowing anonymous things is very sane
jnthn I asusme my class Foo { our $x = 42; }; say Foo.WHO.<$x> # 42
?
That is, we always have some kinda "package"-y stash associated with a class/module/whatever? 16:27
TimToady prolly, since class Foo could get exported into a package scope itself
TheMartianGeek Hey, is there a way to skip to a specified line when using the debugger? 16:28
jnthn std: class Foo { our $x; } $Foo::x
p6eval std 4608239: OUTPUT«===SORRY!===␤Strange text after block (missing comma, semicolon, comment marker?) at /tmp/uvO9F1lxL5 line 1:␤------> class Foo { our $x; }⏏ $Foo::x␤ expecting any of:␤ bracketed infix␤ infix or meta-infix␤ statement modifier
..loop␤Parse failed…
jnthn std: class Foo { our $x; }; $Foo::x
p6eval std 4608239: OUTPUT«ok 00:01 119m␤»
jnthn std: my class Foo { our $x; }; $Foo::x
p6eval std 4608239: OUTPUT«ok 00:01 119m␤»
jnthn TimToady: Is std correct in both cases there?
e.g. the only thing that differs is how we locate Foo?
TimToady dunno, not enough caffiene yet
jnthn Or do we even locate Foo the same way because our also installs a lexical alias? 16:29
OK, I can wait :)
TimToady Foo itself is always found lexically
the question is whether Foo can consider $x to be available
jnthn std: { class Foo { our $x; } }; $Foo::x 16:30
p6eval std 4608239: OUTPUT«ok 00:01 119m␤»
jnthn In that case it's not found leixcally, though?
TimToady std: { my class Foo { our $x; } }; $Foo::x
p6eval std 4608239: OUTPUT«ok 00:01 119m␤»
TimToady hmm
jnthn That second one seems wrong.
TimToady that looks bogus
jnthn I guess if the first is going to work, compiling $Foo::x has to say "do I know a lexical Foo", followed by "hm, no. Do I know a UNIT::GLOBAL::Foo?" 16:31
16:31 colomon joined
TimToady well, just "find Foo", followed by asking Foo for $x 16:32
but the search path for a package goes up the lexical scopes and then to (UNIT::)GLOBAL and PROCESS
jnthn Is that a search that we should resolve at compile time? 16:33
Obviously the lexical ones we can.
TimToady the global one is dicier, since packages are mutable
jnthn I'm asking a bit more about the package itself than the things in it. 16:34
TimToady which is why we're trying to rely mostly on lexical scopes for optimization
well, but GLOBAL itself is a package, and the compiler could delete things from it as well
jnthn I guess it boils down to, if the compiler's knowledge of UNIT::GLOBAL shows no Foo, should it just go ahead and hope one'll turn up by runtime?
TimToady probably shouldn't, but coule
*could
Tene jnthn: it's still always found lexically, it's just that in the case of { { class Foo { ... } }; $Foo::x }, Foo is installed in the UNIT::Foo lexical scope, instead of the current lexical scope. 16:35
TimToady std: say $Foo::bar;
p6eval std 4608239: OUTPUT«ok 00:01 119m␤»
TimToady STD seems to assume that
Tene AIUI
TimToady maybe that's why we didn't get a fail above
it didn't actually find the inner Foo 16:36
jnthn Oh.
Tene: I'm not sure that's the case.
Tene: It's more that it's installed in UNIT::GLOBAL::Foo and we go looking in there.
iiuc, anyway
TimToady STD's assumption with package vars is "they know what they're doing, go with it"
Tene jnthn: Hmm. I need to read more spec. 16:37
TimToady not sure the spec covers those bits in sufficient detail
wait, I *am* sure :)
jnthn Me either, that's why I'm asking here. :P
TimToady that it doesn't :P 16:38
sorear++ has been asking similar Qs
jnthn would really like to get this as close to correct as possible sooner rather than having to refactor it all over again at some point
Or at least, not in a huge way.
TimToady wasn't in much condition to think earlier this week, jetlag and all
jnthn *nod*
TimToady I hope it at least looks convergent to you 16:39
jnthn The main covergance I see is kinda like "everything is lexical really" :)
our scope is kind of an illusion maintained by a lexical GLOBAL that we search in and don't worry about much at compile time. 16:40
TimToady this might be something that you and sorear-oids have to kinda negotiate, since I don't see all the wrinkles that the set of implementors sees
jnthn *nod*
Mostly I just want something sanely implementable. 16:41
Tene Looks like disagreement here in S02? 16:42
"The :: before the subscript is required here, because the Foo::Bar{...} syntax is reserved for attaching a "WHENCE" initialization closure to an autovivifiable type object. (see S12)." -- "(Directly subscripting the type with either square brackets or curlies is reserved for various generic type-theoretic operations. In most other matters type names and package names are interchangeable.)"
TimToady the current STD's symbol table processing is kind of a hack job that approximates what I'm thinking, and sorear++ has kindly pointed out it needs refactoring :)
jnthn :)
TimToady Tene: disagreement with what? 16:43
Tene TimToady: I pasted two quotes that seem to me to disagree with each other.
16:43 justatheory joined
TimToady ah, I see what you're saying, yes, the second is a bit of a fossil 16:44
Tene Unless attaching a whence initialization closure is various generic type-theoretic operations?
TimToady since Foo[] is now generic instantiation and Foo{} is a WHENCE
that sentence predated WHENCE 16:45
mostly you just have to consider that Foo is a type object and Foo:: is an associated symbol table 16:46
which kinda argues that we can see $x even if Foo is lexical
(and our $x, that is) 16:47
*an
jnthn TimToady: I'm pondering that Foo::Bar::Baz is kinda sugar for Foo.WHO.<Bar>.WHO.<Baz> or so. 16:48
jnthn wonders if that's sane. :)
Though I guess it's not quite that as there's some auto-viv issues to worry about. 16:49
TimToady arguably Foo:: is really Foo.WHO, I guess 16:51
jnthn Ah, I'd kinda assumed that ;)
Is it actually kosher to say $Foo::Bar::x = 42; if you never declared a Foo::Bar?
TimToady STD just stores a 'Foo' and 'Foo::' entry without a WHO 16:52
it's kosher in p5
jnthn Doesn't mean it should bein p6 ;)
If we disallow it, we don't ahve to worry over package auto-viv. 16:53
Though maybe that's not a huge deal.
Oh, we have to anyway
If somebody declares a class Foo::Bar { } then Foo has to be something .WHO-able.
std: class Foo::Bar { }; class Foo { } 16:54
p6eval std 4608239: OUTPUT«ok 00:01 118m␤»
TimToady or :: able, at least
jnthn :/
Above is awkward in a way.
TimToady well, we mark Foo as a stub package there, so it knows it hasn't really been fully defined
jnthn Because at the time we stash Foo::Bar we have to autovivity Foo but we don't find out what it'll be until we hit Foo
Where "stub package" presumably has some runtime counterpart?
class Foo::Bar { }; say Foo.HOW.WHAT # hm :) 16:55
16:58 dju_ joined
TimToady it's stubbed in at STD:5491, '!stub' => 1 16:58
Tene class Foo::Bar { ... }; class Foo { ... };
TimToady since this is P5, not all data is an object, so things are more passive than in the P6 mindset
jnthn aye 16:59
TimToady hence something interprets 'Foo::' rather than calling .HOW
but hopefully we're at least making the logical distinctions we want, more or less 17:00
jnthn Well, .HOW is macro-y really
I'd really like it if, after class Foo::Bar { } there really is something installed as Foo that we can .WHO, and that when the class Foo { ... } comes along later, it just steals that things .WHO 17:01
17:01 dju left
TimToady .WHAT.Str.trans('()' => '::') :) 17:01
jnthn :)
Gotta go for a bit :)
TimToady ciao
jnthn Thanks for the thoughts... :) Things are slightly less muddy now. :) 17:02
o/
17:02 TheMartianGeek left 17:06 M_o_C left 17:08 M_o_C joined 17:09 M_o_C left 17:10 M_o_C joined 17:17 bacek left 17:18 cjk101010 left 17:33 tyatpi_ joined 17:40 MayDaniel_ joined 17:41 cdarroch joined, cdarroch left, cdarroch joined 17:52 risou_ joined 17:55 risou left, risou_ is now known as risou 18:01 whiteknight left 18:19 betterworld joined 18:36 Axius left 18:37 snearch joined 18:43 kaare_ joined 18:49 jaldhar left, jaldhar joined
sorear good * #perl6 18:53
mberends hi sorear 18:54
18:59 sorje joined 19:02 jaldhar left, jaldhar joined
masak hi sorear 19:09
tadzik hi sorear 19:11
19:11 Sarten-X joined 19:12 sorje left 19:14 tyatpi_ left 19:17 snearch left 19:21 _twitch left 19:33 zby_home left
sorear TimToady: when trying to decide if two subs have the same longname, how are signatures compared? 19:37
mberends: hi!
19:38 kaare_ left 19:41 nymacro left
mberends sorear: I have this plan to wire up niecza/lib/CORE.setting:1188 to the system time 19:41
s/plan/wish/ 19:42
masak using a very scientific method of preparation, we (jnthn and I) have created Traffic Light Juice.
Blood Organge, Orange, Lemon, and Lime.
quite drinkable. :)
TimToady sorear: carefully! :) 19:43
alternately, assume they're different and let the dispatcher figure it out 19:45
eventually it might become obvious how to backpatch that to a compile-time test
otoh, if two subs canonicalize to the same long name, you know immediately that you have problems 19:46
19:46 tyatpi_ joined
TimToady so I assume some kind of canonicalization of sig representation will be in order 19:46
also, we can conceivably check any multi sig against any constraints imposed by the proto, if the proto is not rewriting args before {*} 19:48
mberends masak: mmm. With a straw, you would not be limited to LIFO access
sorear TimToady: but, shadowing? 19:54
multi foo(Int $x) { $x }; { multi foo(Int $x) { $x * 2 }; say foo 12 } 19:55
TimToady in the case of nominal types, we can calculate the shadowing. extra constraints are harder, and can't rely on much except the presence of a constraint 19:56
sorear I figure subs are supposed to hide outer subs with exactly the same long name 19:57
masak mberends: actually, they blended completely.
sorear which brings questions like, "are &foo:(Int) and &foo:(CORE::Int) the same" 19:58
TimToady and the shadowing doesn't really matter until someone says nextsame or some such
well, Foo.WHAT === Bar.WHAT for aliases 19:59
or something like that... 20:00
at one point I think rakudo was doing Foo ~~ Bar and Bar ~~ Foo, but that seems a bit roundabout
I guess we need Sig.WHICH to be an accurate measure of identity 20:01
perhaps .WHICH returns the canonicalized form 20:02
assuming it's possible to canonicalize 20:03
maybe we just have to rely on Sig1 eqv Sig2
20:04 bacek joined
TimToady has an appointment 7 minutes ago, so may disappear at any moment 20:08
20:08 Tedd1^ left 20:10 Tedd1 joined 20:12 Tedd1 left, Intensity joined 20:13 tyatpi_ left 20:14 tyatpi_ joined 20:37 risou_ joined 20:39 risou left 20:40 risou_ is now known as risou 20:41 donri left 20:43 M_o_C left 20:51 Tedd1 joined 21:09 tyatpi_ left 21:14 kaare_ joined
TimToady j 21:15
sorear ENOTVIM 21:16
TimToady it's a shell alias for jobs :) 21:17
21:21 lue joined
lue hello world! o/ 21:21
21:26 donri joined 21:27 TheMartianGeek joined 21:30 kaare_ left 21:32 DarthGandalf left, justatheory left 21:38 DarthGandalf joined 22:02 coldhead joined 22:16 MayDaniel_ left
jnthn back 22:30
sorear yay!
TheMartianGeek scsys.co.uk:8002/92593 <-- Can anyone help me with this code? 22:31
I'm still working on the same problem I was working on a week ago...
I'm trying to find all blocks of 00s that are at least a certain length. 22:33
jnthn TheMartianGeek: Is this Perl 5 or Perl 6? 22:34
TheMartianGeek 5.
jnthn Oh. :)
This probably isn't the best place to ask...
TheMartianGeek Well, yeah, I was trying on #perl as well, but I didn't really get anywhere.
jnthn Ah :( 22:35
22:36 dju__ joined 22:39 dju_ left 22:41 gdey joined 22:44 gdey left
masak TheMartianGeek: #perl might not be the best place to ask either... 22:49
coldhead #python?
those guys are helpful
TheMartianGeek Even with languages that aren't Python?... 22:50
masak TheMartianGeek: I think recommending #python is a running gag among the people on #perl.
not sure it's an excellent community practice.
but then again, that doesn't seem to be a thing optimized for on #perl... :P 22:51
TheMartianGeek Looks like I'm kind of hosed... 22:53
22:54 Rotwang joined
masak no, there are perfectly adequate places on IRC to get Perl 5 help. just not necessarily here or on #perl. 22:54
TheMartianGeek Hm. 22:55
masak #perl-help is one decent place, I'm told.
it's over on irc.perl.org
TheMartianGeek Okay, I'll try that.
masak best of luck. if it doesn't work out, come back here and we'll work something out.
lue So... #perl redirects those who asks help to #python? 22:56
masak or to #metallica.
lue s/asks/ask/
jnthn At least metallica are good... :)_
TheMartianGeek Thanks.
pmurias masak: #perl on freenode is a very helpfull channel 22:57
masak pmurias: oh, interesting. mst once described it as the channel he hadn't "gotten around to cleaning up yet".
pmurias: maybe I have a biased memory of it, having once gone up against #perl-on-freenode single-handedly... :P 22:58
lue
.oO(Then it turns out the real joke is that the guys at #python are waay more helpful)
 23:00
masak lue: no matter how the #python people handle a person arriving waving a Perl problem, it seems less-than-mature to me to make the recommendation, rather than send the person to some place that would readily answer the question. 23:02
then again, one can't enforce these things top-down. channels are what they are.
pmurias masak: you seem to be strongly anti-#perl 23:04
23:07 awj left 23:08 awj joined
lue considers using "Internet Subcultures" as an essay topic in the future. 23:13
sorear lue: sorry, but you're too close.
sociologists need to be outsiders.
lue considers using "Internet Subcultures" as the one tiny kernel of truth for a novel in the future. 23:14
masak pmurias: well, in all fairness, things might have changed, my memory might be tainted, or I'm simply biased. 23:18
but #perl on both servers have definitely helped me see why people consider #perl6 to be an exceptionally nice and patient channel. 23:19
lue I personally find myself semi-frequently wanting to ask questions here and then thinking "Darn it! That has *nothing* to do with Perl 6 (yet)!" 23:20
masak lue: we're always happy to accept help making more people have something to do with Perl 6 ;) 23:25
lue
.oO(One thing that would be very nice is a P6 based input method that'll let me use an ~/.XCompose file and input japanese at the same time)
 23:31
masak sleeps
'night, #perl6.
23:32 Alias_ joined
jnthn o/, masak 23:33
dalek p: 82145f5 | jonathan++ | / (4 files):
Add a simple REPR that just stores values in a flat hash for Tene++.
 23:47
jnthn phenny: tell Tene See 82145f5 in nqp reop, and gist.github.com/867713 23:49
phenny jnthn: I'll pass that on when Tene is around.
jnthn phenny: tell Tene will be able to optimize it a bit more in the future too, but this should serve as a decent start.
phenny jnthn: I'll pass that on when Tene is around.
23:51 jaldhar left, jaldhar joined 23:52 justatheory joined 23:55 fisted_ joined, Mowah left 23:57 benabik left 23:58 fisted left

Powered by Cro and the Raku® Programming Language.

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

Thank you!