pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, elf: etc.) (or perl6: for all) | irclog: irc.pugscode.org/
Set by Tene on 29 July 2008.
pugs_svn r22331 | putter++ | [elf] elf_h forked from elf_g. 01:29
r22331 | putter++ | elf_g remains the recommended stable version of elf. 2 months old today.
r22331 | putter++ | elf_h is the unstable development head.
r22331 | putter++ | Dusted TODO. elf_g now uses its own copy of STD_red.
pugs_svn r22332 | putter++ | [STD_red] First rough draft of a dump format for Common Lisp. 01:56
s1n moritz_: ping 02:15
Ontolog moritz_: what was that bug number affecting returning a list of Match objects? 03:54
s1n moritz_++ good work on the test suite lately 04:39
Tene moritz++ I agree 04:43
s1n we're over 5000 passing with over 8000 planned in t/spec! 04:44
Ontolog I'm going through the PCT tutorial. I have an error: PAST::Compiler can't compile node of type Monkey::Grammar 06:46
Is there any way to tell parrot to be more verbose? I would like to know *why* can't it compile the node
and no, options w and v don't help 06:47
oops i'm on the wrong channel :p
moritz_ re 07:34
s1n: pong
pmurias moritz_: hi 07:36
moritz_ pmurias: good morning ;)
pmurias good morning 07:37
Ontolog i don't understand why I am getting <integer_constant> => PMC 'Monkey::Grammar' => "Hash[0x83a4298]" @ 2
when I should be getting <integer_constant> => PMC 'Monkey::Grammar' => 1 @ 2 07:38
moritz_ you have a capture more than you think?
Ontolog can't be 07:40
input is a=1
moritz_ what does your rule integer_constant look like 07:41
pugs_svn r22333 | pmurias++ | [smop] changed smop back to a static library so pugs linked with it doesn't need LD_LIBRARY_PATH 07:42
Ontolog rule integer_constant { \d+ {*} } 07:43
pmurias does making pugs accept both perl6 and m0ld seem sane? 07:44
moritz_ pmurias: if the m0ld is somhow delimited... why not? 07:53
pmurias moritz_: i could make m0ld delimited or use a -F option, what i' worried about if it's not making pugs too smopish 08:12
moritz_ that's not a worry I can address 08:14
pmurias nobody else is (visibly) working on pugs so that's propably not a big worry 08:16
masak moritz_: aye. I generally backlog. :) 08:28
too much interesting going on here.
moritz_ masak: so did you backlog parrotsketch? ;-) 08:29
pugs_svn r22334 | pmurias++ | [pugs] Pugs.Embed.M0ld imports a modulized M0ld.hs which now lives in src/ 08:30
masak moritz_: no, doing that now
moritz_ masak: in short, green light for your commit bit
masak \o/
moritz_ either pmichaud or I will be mentoring you 08:31
masak I look forward to that
wow, this feels much better than I thought it would :)
moritz_ hehe ;) 08:32
masak perl6: 1 ?? 2 : 3 # this makes Rakudo's parser freak out 08:41
p6eval rakudo 31377: OUTPUT[ResizablePMCArray: Can't pop from an empty array!␤current instr.: 'parrot;PGE::OPTable;parse' pc 1754 (compilers/pge/PGE/OPTable.pir:495)␤]
..pugs: OUTPUT[*** ␤ Unexpected ": 3"␤ expecting operator or "!!"␤ at /tmp/4OqfHgrmYE line 1, column 8␤]
..elf 22334: OUTPUT[Parse error in: /tmp/4kmbr4ZrzD␤panic at line 1 column 0 (pos 0): Can't understand next input--giving up␤WHERE: 1 ?? 2 : 3 # this makes Rakudo␤WHERE:/\<-- HERE␤ STD_red/prelude.rb:99:in `panic'␤ STD_red/std.rb:76:in `scan_unitstopper'␤ STD_red/std.rb:224:in `comp_unit'␤
..STD_r...
masak did we create an RT ticket for that? I don't remember 08:41
moritz_ masak: yes, you did 08:43
perl6: 1 ?? 2 !! 3
p6eval pugs, rakudo 31377: RESULT[2]
..elf 22334: OUTPUT[Unknown rule: infix:conditional␤It needs to be added to ast_handlers.␤ at ./elf_f line 1918␤]
masak elf++ # awareness of its own limits
masak rakudo: say +("1" ~ "0" x $_) for 308, 309 09:03
p6eval rakudo 31378: OUTPUT["load_bytecode" couldn't find file 'PGE.pbc'␤current instr.: 'parrot;PCT::Grammar;onload' pc 0 (src/PCT/Grammar.pir:41)␤]
masak recompiling again? :) 09:04
rakudo: say +("1" ~ "0" x $_) for 308, 309 09:07
p6eval rakudo 31378: OUTPUT[1e+308␤inf␤]
pmurias moritz_: pugs -Bm0ld will work soon how should it be added to the evalbot? or do you have time to add it yourself? 09:46
pugs_svn r22335 | pmurias++ | [pugs] pugs -Bm0ld creates a simple mold frame 11:50
pmurias @tell ruoso it turned out rootnamespace was an undead objects (it got DESTROYALLED) just after creation and "lived" on with a counter near 999 11:52
lambdabot Consider it noted.
pugs_svn r22336 | pmurias++ | [pugs] [smop] the haskell gc does the refcounting for the SMOP__Objects passed around in haskell code 12:39
rakudo_svn r31379 | pmichaud++ | [rakudo]: spectest-progress.csv update: 177 files, 3779 passing tests 13:17
masak progress++ 13:48
ahmadz hi 13:51
masak ahmadz: hello. 13:52
pmurias_ ahmadz: hi
ahmadz masak: raduko is part of parrot svn right?
pmurias_: hello
masak ahmadz: yes, it is.
but the rakudo part of svn commits is reported here too 13:53
ahmadz i noticed
so raduko passes t/spec in pugs or parrot svn? 13:55
masak t/spec resides in Pugs svn
when you run 'make spectest', it's imported/updated locally
qwr wonders whether you consistent mispelling or is raduko some weird thing I don't know... 13:56
s/you/you are/
ahmadz qwr: sorry for that 13:57
masak qwr: I didn't see it until now. :)
qwr heh, ok ;)
masak we could name a Perl 6 project raduko and see what happens. and perhaps rukado, rokadu, rodaku and radoku, too. 13:58
we clearly haven't filled the space of names yet. 13:59
pmurias_ naming a Python project raduko and seeing what happens would be even more fun 14:03
masak yes, that's even better
ahmadz interesting 14:04
masak the name 'Radoku' sounds like it could involve numbers in a 9x9 grid somehow
ahmadz radoku ~ sudoku 14:06
pmurias_ sudoku--
masak pmurias_: I think I've gotten over my distaste for Sudoku. it doesn't mean I'm any more interested, I just don't care much either way any more. the masses will always need some kind of opium, even if it consists of filling in numbers in predefined ways. 14:09
who knows, such activities might even stave off dementia for some folks 14:10
moritz_ pmurias_: is the interface simply 'pugs -Bm0ld filename'? 14:12
masak moritz_: I'd make 'mold' and 'm0ld' synonyms if I were you, to avoid awkward questions :) 14:13
moritz_ masak: not my choice, tell pmurias_ ;) 14:13
masak pmurias_: I'd make 'mold' and 'm0ld' synonyms if I were you, to avoid awkward questions :)
pmurias_ moritz_: yes 14:14
moritz_: pugs needs compiling with ./Setup configure --user --flags=SMOP;./Setup build and smop needs to be build with make 14:15
pmurias hates the _ suffix ;) 14:16
masak: maybe a smop synonym? 14:17
moritz_ pmurias: I'll probably get to it later 14:18
pmurias moritz_: i'm still fighting strange bugs 14:19
masak pmurias: aye
pmurias maybe symbolic references in C with dlopen(NULL,RTLD_LAZY) are a bit too magical... 14:26
moritz_ if you ask yourself where yesterday night's leap in rakudo's passed test count came from... 14:51
I wrote a new tool that helps to better identify which tests mostly pass
Tene How many passing tests are there now? 14:52
moritz_ 3779
Tene Nice.
moritz++
moritz_ as opposed to 3434 the day before
PerlJam for some reason I am reminded of The Princess Bride and the hero being "mostly" dead. 14:57
moritz_ anyway, I'll test that thing a bit more, and then commit as a replacement for tools/update_passing_test_data.pl 14:58
pasteling "spinclad" at 209.6.140.232 pasted "masak: proper credit for 'every day christmas'" (25 lines, 2.2K) at sial.org/pbot/32323 15:16
moritz_ spinclad++ # "(i asked purl if i could quote her, she had no objection)" 15:18
pmichaud I think that the "every day christmas" quote actually comes from audreyt 15:55
[particle] yes, may need to search logs for "xmas" 15:56
pmichaud I think I first heard about it at yapc 2005 15:57
might've been yapc 2006
[particle] toronto? sounds familiar 15:58
pmurias mncharity: hi 16:19
moritz_ pmurias: smop/m0ld seems to depend on autobox, but not probing for it 16:23
or autobox::Core 16:24
pmurias sm0p more likely m0ld is in haskell
moritz_ ok, smop then ;)
what a colourful build process ;) 16:25
pasteling "moritz_" at 89.13.226.127 pasted "smop build failure (for pmurias/ruoso)" (13 lines, 781B) at sial.org/pbot/32324 16:26
pmurias moritz_: doesn't happen here everything is svn up'd and unmodified? 16:29
moritz_ pmurias: "yes" to both 16:30
when I started the build pugs wasn't built with m0ld support 16:31
is that a problem?
pmurias shouldn't be
could you nopaste the build/test/33_pugs_simple.m0ld 16:32
pasteling "moritz_" at 89.13.226.127 pasted "build/test/33_pugs_simple.m0ld (for pmurias)" (1 line, 2.6K) at sial.org/pbot/32325
pmurias moritz_: looks like you have an old pugs 16:33
moritz_ pmurias: I did an 'svn up', and then the ./Setup incantation you gave me earlier 16:34
should I try a 'make clean' first?
pmurias cp dist/build/pugs/pugs pugs 16:35
sorry, my fault
moritz_ ok, arrived at 100% 16:36
pugs_svn r22337 | moritz++ | [evalbot] add m0ld support, remove yap6 16:39
moritz_ evalbot control restart
moritz_ pugs: say "sanity check" 16:39
p6eval pugs: OUTPUT[sanity check␤]
moritz_ m0ld: say "hi"
p6eval m0ld: OUTPUT[pugs: user error (Cannot evaluate in M0ld)␤␤]
moritz_ pmurias: should that work right now? 16:41
pmurias in a minute or too
[particle] m0ld: 1.say 16:42
p6eval m0ld: OUTPUT[pugs: user error (Cannot evaluate in M0ld)␤␤]
[particle] m0ld: 1 16:43
p6eval m0ld: OUTPUT[pugs: user error (Cannot evaluate in M0ld)␤␤]
[particle] explores the limits of m0ld :(
pugs_svn r22338 | pmurias++ | [pugs] evaling code in the embedded smop works 16:50
pmurias moritz_: could you rebuild pugs with ./Setup configure --user --flags=SMOP;./Setup build;cp dist/build/pugs/pugs pugs
moritz_ pmurias: that's pretty much what my build script does... testing it now, and if it works, I'll make a cron job out of it 16:52
m0ld: say "hi"
p6eval m0ld: OUTPUT[pugs: user error (Cannot evaluate in M0ld)␤␤]
pmurias that error indicates smop support is not build in
moritz_ tries a 'make clean' 16:53
pmurias and m0ld: should be propably be called smop: as rakudo: is not called pir: 16:56
moritz_ now that's easy to do ;) 16:57
pugs_svn r22339 | moritz++ | [evalbot] s/m0ld/smop/
moritz_ evalbot control restart
pugs_svn r22340 | pmurias++ | [pugs] a better error message if smop embedding is not configured 16:58
pmurias smop: $*OUT.print("Hello\n")
p6eval smop: OUTPUT[pugs: user error (Cannot evaluate in M0ld)␤␤]
pmurias evalbot control restart
moritz_ pmurias: rebuild is not yet completed
pmurias smop: $*OUT.print("Hello\n") 16:58
p6eval smop: OUTPUT[pugs: user error (Cannot evaluate in M0ld)␤␤]
moritz_ and evalbot doesn't need to be restarted when the implementations change 16:59
pmurias good
moritz_ smop: $*OUT.print("Hello\n") 17:00
p6eval smop: OUTPUT[pugs: user error (Cannot evaluate in M0ld)␤␤]
pmurias you don't run perl Makefile.pl;make right? 17:01
pmurias smop: $*OUT.print("Hello\n") 17:01
p6eval smop: OUTPUT[pugs: user error (Cannot evaluate in M0ld)␤␤]
moritz_ no, I run ./Setup --user --flags=SMOP
and then ./Setup build
pmurias it's ./Setup configure --user --flags=SMOP
moritz_ erm, yes 17:02
sorry, didn't copy and paste
pasteling "moritz_" at 89.13.226.127 pasted "pugs build script" (12 lines, 188B) at sial.org/pbot/32326 17:02
pmurias you should make smop first 17:04
smop: $*OUT.print("Hello\n")
p6eval smop: OUTPUT[pugs: user error (Cannot evaluate in M0ld)␤␤]
moritz_ ok, trying again 17:05
pmurias it shouldn't matter, the pugs in the evalbot isn't HEAD btw
moritz_ pugs: say $?PUGS_VERSION 17:06
p6eval pugs: OUTPUT[Perl6 User's Golfing System, version 6.2.13.11, July 31, 2008 (r20996)␤]
moritz_ uhm.
that explaiins a lot
it executes the wrong pugs
sorry for the mess
moritz_ but why? 17:08
dist/build/pugs/pugs -e 'say $?PUGS_VERSION' also says r20996 17:09
moritz_ doesn't understand what's going on
pmurias & 17:11
moritz_ computers-- 17:12
[particle] humans++ 17:13
moritz_ don't DWIM
humans-- # don't teach the computers how to DWIM, at least not good enough
[particle] computers++ # do exactly what you tell them to
moritz_ ..except when they don't ;-) 17:14
masak I don't believe that more DWIM is always better. and IRC bots have convinced me that narrow AI rocks. 17:15
except for purl, a very obnoxious bot
moritz_ ;)
[particle] <purl>i know you are, but what am i?</purl> 17:17
mncharity howdy pmurias, how goes? 17:20
pmurias fine, i'm putting the pugs smop backend into the evalbot 17:21
moritz_ I just tried on a different machine 17:22
pugs_svn r22341 | putter++ | [elf] Finished elf_h fork. Tweaked IR. Updated test results. 17:23
moritz_ the revision number didn't get updated on rebuild
mncharity pmurias: neat.
pmurias smop: $*OUT.print("hello\n") 17:24
p6eval smop: OUTPUT[smop embedding is disabled use ./Setup configure --user --flags=SMOP␤]
moritz_ that's what I get on a different machine as well 17:25
does smop need to be in $PATH?
pmurias no, smop is staticly linked in
mncharity re neat, pity it isn't elf. ;) any feedback? went with the more working parser? 17:26
pmurias mncharity: went with the more working ast 17:26
mncharity more working in what way? the infix:<,> you mentioned? anything else? 17:27
pmurias ruoso: hi
ruoso hi pmurias
lambdabot ruoso: You have 2 new messages. '/msg lambdabot @messages' to read them.
pmurias mncharity: looking...
mncharity no hurry. but would definitely like to know at some point.
just to make absolutely sure you know, you realize you are not going to be getting oo declarations out of the old pugs parse, right? 17:29
pmurias pugs: class Foo {has $.foo;};my $foo = Foo.new(foo=>1);say $foo.foo; 17:30
p6eval pugs: OUTPUT[1␤]
pmurias mncharity: pugs seems to parse oo declarations 17:31
mncharity yes, but that's not what you are using pugs for (unless I've badly misunderstood). take a look at your pil output. 17:32
ruoso smop: $*OUT.print("Hello World!\n") 17:33
p6eval smop: OUTPUT[smop embedding is disabled use ./Setup configure --user --flags=SMOP␤]
mncharity there's a reason we've been stuck on exactly this for a couple of years. not just "no one got around to doing a backend". :)
ruoso ahhh
pmurias mncharity: pil didn't have my declarations which is much more serious, but i hacked them in 17:34
ruoso . o O ( if pmurias has a declaration I want one on my own ;) ;) ;) )
mncharity lol 17:35
pmurias ruoso: you can have our declarations
ruoso heh...
mncharity hacked them in?!? do please elaborate.
oh, "my" decarations. ok. nm. but have you seen the pil for class declarations? 17:36
pmurias the typical pugs run is "source code" -> AST 17:37
when you add a custom backend it's "source code" -> AST -> PIL1 -> "something else"
everything pugs can run it has in the AST 17:38
mncharity (I have to go. sorry. back laterish)
pmurias and there's nothing special about PIL1 17:39
mncharity: i'll propably switch to elf if audreyt doesn't go back to hacking on pugs 17:40
ruoso pmurias++ # pugs -BM0ld works here :) 17:41
moritz_, for some reason it only started working after I rebuild SMOP after building pugs for the first time... (or something like that) 17:42
masak will we steal qualified imports from Haskell into Perl 6? :)
ruoso but it does work now :)
moritz_ masak: I think we did already
masak moritz_: oh, good.
moritz_ S11 or S10, I alway forget which one covers what 17:43
masak oki
moritz_ ruoso: it feels like rebuilt both pugs and smop 10 times already :(
ruoso did you saw " Compiling M0ld.AST " at any of those times? 17:44
moritz_ dunno
ruoso moritz_, change the build script to build SMOP before pugs 17:46
moritz_ there seemss to be no 'make clean' for smop - what do you use iinstead?
ruoso rm -rf build
ruoso :) it's nice because it's already sanely looking for variables in the lexical scope, just as expected... Pugs+SMOP seems to be a very interesting pair... 17:51
moritz_ tries to remove ~/.cabal and ~/.ghc and then tries a last time 17:52
ruoso moritz_, are you building smop before trying to build pugs?
moritz_ ruoso: yes 17:53
ruoso pmurias, the reason for using static linking is just to avoid LD_LIBRARY_PATH needing to be set? 17:56
moritz_ no luck again 18:02
./pugs -V |grep -i smop
no output
ruoso smop: hell0o 18:04
p6eval smop: OUTPUT[smop embedding is disabled use ./Setup configure --user --flags=SMOP␤]
ruoso :( 18:05
moritz_, do you have the buildlog?
moritz_ ruoso: no, but I can try again... 18:06
ruoso: do you need pugs build log, or both?
ruoso are you using that script you pasted above? 18:06
moritz_ yes 18:07
moritz_ but I changed it to build smop first 18:07
ruoso right... so the log is for that script...
which involves both pugs build and smop build
right?
moritz_ right
pmurias_ ruoso: re static linking yes, it's a one word change
ruoso pmurias_, right... I think it'll probably be easier later to have it as dynamic... to avoid having to rebuild pugs every time 18:08
moritz_ ruoso: moritz.faui2k3.org/tmp/pugs-build-log 18:09
pmurias_ moritz_: cp Pugs.cabal.in Pugs.cabal 18:10
moritz_ pmurias_: and then?
pmurias_ ./Setup configure --user --flags=SMOP and then ./Setup build 18:11
moritz_ [14 of 93] Compiling M0ld.AST
pmurias_: do I have to do that copy step on each build? 18:12
moritz_ smop: $*OUT.print: "foo" 18:13
p6eval smop: OUTPUT[foo]
ruoso :) :) :): ): ): ):)
moritz_ indeed
smop: say "foo"
p6eval smop: OUTPUT[no variable &say in the current scope␤] 18:14
pmurias_ :(
moritz_: you don't have to but you propably should
ruoso "no variable &say" is the expected error :) 18:15
pmurias_ as we don't use perl Makefile.PL;make we have to do what they do
moritz_ or tweak Makefile.PL to enable smop embedding ;) 18:16
pugs_svn r22342 | pmurias++ | [pugs] -Bm0ld supports integers
pmurias_ moritz_: yes 18:17
ruoso that's probably better... since I can't make it work on my machine anymore... :) 18:18
pmurias_ ruoso: what's the error?
ruoso pmurias_, it simply doesn't get smop 18:19
it throws me the "no embedded smop" error
but when I change Makefile.PL it works.. 18:20
pugs_svn r22343 | azawawi++ | [pugs] Added a solution to "Cannot install zlib: 256" after 'perl Makefile.PL'
r22343 | azawawi++ | [pugs] Separated problems with line separators
ruoso pmurias_, we probably need to take the tests out of the default compile target
since pugs depends on smop, and the smop tests depend on pugs
and the cool thing is that pugs and smop are getting together really nice... 18:22
producing the expected errors where expected...
like...
smop: $*OUT("no postcircumfix:( ) at this variable") 18:23
p6eval smop: OUTPUT[unknown method "postcircumfix:( )" at message line 55 file /home/evalenv/pugs/v6/smop/build/src/smop_s1p_io.c␤]
ruoso smop: $*FOO = 1; $*OUT.print($*FOO); 18:24
p6eval smop: OUTPUT[no variable $*FOO in the current scope␤]
ruoso hmm... that was not expected...
pmurias_ that's actually wrong
moritz_ why?
ruoso because $*FOO is global, not a lexical
moritz_ are global variables not subject to strict?
pmurias_ no
ruoso that's what makes them global ;)
and undesirable ;)
it shouldn't even be looking in the lexical scope... 18:25
pmurias_ globals are a low priority
could you commit your change to Makefile.PL (propably conditional with $ENV{PUGS_EMBED} =~ /\bsmop\b/) 18:26
pmurias smop: $*OUT.print(1,"\n") 18:27
p6eval smop: OUTPUT[1␤]
pugs_svn r22344 | pmurias++ | [pugs/smop] changed $*OUT to $OUT as $*OUT is a global not a lexical 18:30
r22345 | pmurias++ | [smop] removed test 33 from the default test target 18:39
pugs_svn r22346 | ruoso++ | [pugs] add --flags=SMOP if $ENV{PUGS_EMBED} =~ /\bsmop\b/i 18:46
ruoso pmurias, for some reason, pugs is trying to lookup itself for global variables 18:52
smop: $FOO 18:53
p6eval smop: OUTPUT[*** ␤ Unexpected end of input␤ expecting "::"␤ Variable "$FOO" requires predeclaration or explicit package name␤ at /tmp/wBNnIL4j9u line 1, column 5␤]
ruoso smop: $*OUT.print("Hello")
p6eval smop: OUTPUT[no variable $*OUT in the current scope␤]
ruoso smop: $OUT.print("Hello")
p6eval smop: OUTPUT[no variable $*OUT in the current scope␤]
ruoso it seems that pugs is trying to be too smart 18:55
pmurias smtms: $OUT.print("hello") 18:56
sorry
smop: $OUT.print("Hello here\n") 18:57
p6eval smop: OUTPUT[no variable $*OUT in the current scope␤]
pmurias ruoso: pugs is running no strict
ruoso pmurias, but it shouldn't be doing that anyway... 18:58
should it?
pmurias no strict is the default for one liners 18:59
ruoso sure... but does "no strict" means translating $OUT to $*OUT?
pmurias why not? 19:00
ruoso I'd expect $OUT to create a new variable...
specially because you don't start in package *
you start in package Main
so at most it would create Main::$Out
but I don't see how it would get to $*OUT 19:01
pmurias maybe no strict falls back to globals not to package variables
ruoso hmm... that would be strange... 19:02
pmurias no strict doesn't make much sense
ruoso the specs only talk about when strict *is* in effect... 19:03
I can't find a reference to 'no strict'
pmurias falling back to a global is the least strict option 19:04
ruoso pmurias, being global and being in the package * are two different things 19:05
pmurias don't think so
ruoso global is about visibility, not about where it is
pmurias S10:58 19:06
ruoso but packages are, by default, our 19:07
which means that they're global
even if they are not *
pmurias no they aren't you can have versioned packages
ruoso pmurias, when the parser starts, it's in the package *, so package Foo at the beggining of a file, means *Foo 19:08
the same way, if there's no package declaration, the runtime puts you into *Main
the most logical thing would be for $FOO to be *Main::$FOO 19:09
not $*FOO
pugs_svn r22347 | masak++ | [ord_and_chr.t] added tests for multi-arg variants of ord and chr
pmurias ruoso: imagine having version 0.1 and 0.2 of a versioned *global* package at once 19:11
ruoso pmurias, being loaded at the same time? 19:11
you have two alternatives... 19:12
the first would be that this is not possible...
the second would imply that each versioned package registers itself globally with fully-versioned-name *Foo::0.1 and *Foo::0.2
and Foo is bound to each place that "use Foo" 19:13
but that means $*Foo::bar is undetermined
although $Foo::bar in a place that use'd Foo will point to the correct version... 19:14
pmurias the third option is that the spec is inconsitent
* inconsistent
ruoso pmurias, the spec tries very hard to make globals unpleasant :) 19:15
but the fact is... 19:16
package Foo; at the start of a file means creating a global package that is stored as *Foo 19:17
and unless you 'use Foo' or 'require Foo', you can only access it as *Foo... 19:18
'use Foo' or 'require Foo' will create a local bind of that package as "Foo" in the current lexical scope
which will allow you to use Foo.new()
perl -MFoo will probably add Foo to the prelude scope... 19:19
so that it becomes omnipresent...
pmurias ruoso: i don't think it's the intention to make the globals more unpleasant then they already are by they very nature
pmurias TimToady: does package Foo at the top create a global *Foo package? if so why? wouldn't that screw up versioning? 19:20
ruoso pmurias, I'm not sure current versioning schema provides loading two different versions of a library at the same time... 19:21
pmurias ruoso: if they are purly lexical you can have as many as you want provided they are used from seperate lexical scopes 19:22
pmurias and i think that's more important then builting support for monkey patching 19:23
ruoso "A bare package declarator declares an our package within the current package"
All files start out being parsed in the * package, but switch to some other package scope depending on the first declaration 19:24
pmurias ruoso: i am aware what the spec says i just thinks it's a bug
ruoso pmurias, if you take a look at S11, you'll see that package Foo; is an incomplete name 19:25
the actual name of the package should include the version
pmurias it's not just that 19:26
ruoso so it looks like *Foo:ver<0.1>:auth<DRUOSO>
and 'use Foo' creates a local bind of "Foo" pointing to that package
pmurias it's wrong to be able to access Foo::bar just because something somewhere loaded the Foo package
ruoso not Foo::bar... 19:27
but *Foo:ver<0.1>:auth<DRUOSO>::bar
and if two pieces of code "use Foo", they will point to the same package 19:28
and Foo::bar in both codes will point to the same var
pmurias still wrong 19:29
ruoso well.. the package needs to be shared in the interpreter...
it's just a matter of having a explicit way or a hackish way of accessing the shared package
a package is "our" by default... 19:30
pmurias if we want to design premature optimalisation in we can have a native ptr type
ruoso hm? what does it have to do with that?
pmurias what's the point of a use Foo in 2 places using the same Foo? 19:31
ruoso perhaps Foo points to a package variable that should be shared? 19:32
like... subroutines?
pmurias so it would be an explicit *Foo
subroutines shouldn't be shared
we are not the monkey patching people
ruoso well... 'use Foo' creates a local bind to "*Foo" as "Foo"
actually... "use Foo" creates a local bind to "wherever_the_package_is_stored" as "Foo" 19:33
pmurias according to the spec which i belive to be severily wrong here 19:34
* severly
masak pmurias: 'severely', but who cares? :) 19:35
ruoso pmurias, for "class Foo is also {...}" to work at a distance (as expected) it needs to be that way 19:36
pmurias ruoso: it add stuff to the lexical Foo 19:37
ruoso pmurias, as well as adding a subroutine to an existing package...
pmurias, and the lexical Foo points to the shared Foo
pmurias that's monkey patching
use should use use Monkey::Patching to do that 19:38
ruoso pmurias, that's something Perl has always supported, and Perl 6 doesn't mention not supporting it anymore...
pmurias searches for chromatics "why monkey patching is stupid: post 19:39
PerlJam just because something is stupid doesn't mean that perl 6 is going to prohibit it.
ruoso mostly because monkey patching is the most effective way of patching modules you don't maintain... 19:40
PerlJam "goto considered harmful", but we still have it anyway 19:40
moritz_ not prohibiting is not the same as using it as an essential language feature
ruoso it's not an essential language features...
ruoso if you use it without doing monkey patching... it won't be monkey patching... 19:41
but the Packages do need to be shared...
pmurias PerlJam: my point it that the monkey patching package sharing shouldn't be the default 19:42
PerlJam pmurias: you mean the ability to do so?
ruoso pmurias, you mean cloning the Package at every 'use'?
pmurias ruoso: yes
ruoso ouch...
that hurts...
moritz_ doesn't sound too efficient 19:43
pmurias we are not C++
ruoso pmurias, you know that makes package variables to behave in a very unexpected way, don't you?
like... 19:44
consider a file with: module Foo { our $bar = 0; sub baz { return $bar++ } }; 19:45
now consider that you have a script... that use Bla; and use Ble;
both Bla and Ble use Foo
and they will then point to different packages...
and point to different values of $bar... 19:46
that's very unexpected...
PerlJam ruoso: Hmm. I think pmurias' way could work if on clone the original package were the "proto-package" for all of the clones and it held the singleton instances of the package variables, but subroutines were all their own. (if you get my meaning) 19:47
moritz_ how is that different from aliasing then? 19:48
PerlJam It's more like the anoymous class you get when you compose traits into an object at runtime
pmurias ruoso: imagine what happends when Bla uses Foo >= 0.1 and Ble uses Foo 0.1
PerlJam s/anoy/anony/
pmurias * happens 19:49
ruoso PerlJam, that's also unexpected... since subroutines are just variables...
pmurias ruoso: you can always use module Foo { sub baz { return $*Foo::bar++ } }
moritz_ pmurias: that's not very DWIMmy 19:50
ruoso pmurias, not DWIMmy at all...
pmurias things should be correct not DWIMy 19:51
moritz_ things should be both corret and DWIMy
ruoso I mean... we could abolish globals entirely...
but I don't think that's the idea 19:52
pmurias globals should only be used when you explicitly use them
and if take efficiency in mind the way i'm proposing is faster 19:55
s/if/you/
ruoso well... it's up to TimToady now 20:05
ruoso pmurias, btw... "our $bar" is kinda explicit use of globals... 20:11
TimToady but the current package is lexically scoped 20:15
and I suspect a Foo::bar without an explicit "use Foo" would pick the same Foo that a bare "use Foo" would do 20:16
ruoso TimToady, but the package is our by default... 20:17
which ends up being the same...
TimToady the meaning of package names is lexically scoped
ruoso right... we agreed to this point...
the question is whether they point to the same thing on different places.. 20:18
i.e. the Bla and Ble example I gave above
TimToady they point to different places. if two packages want to share a global variable, they need a third package that doesn't change version so often 20:19
same for an exclusive resource
such as a database handle
pmurias TimToady: what i'm proposing is that packages aren't global unless prefixed with a * 20:20
TimToady "Foo" is ever only a local alias to the long name
pmurias TimToady: so does package Foo {...} create a GLOBAL::Foo? 20:22
ruoso right... but what does get shared?
TimToady on phone...
ruoso . o O ( GLOBAL::Foo on phone... hmmm... ;) ) 20:23
pmurias ;
)
ruoso more importantly... package Foo {...} as the first declaration on a file creates GLOBAL::Foo? 20:25
TimToady package Foo is short for "our package Foo" which creates it in the current package 20:26
ruoso which, as the first declaration, is *
TimToady which might actually be Main at the start of the file
so it's possible we only have *Main
and that contains the others 20:27
ruoso er...
the spec tells about both * and *Main
pmurias er...
TimToady well, the spec could always be wrong :)
pmurias hopes it is
ruoso pmurias, that only change where it's stored...
pmurias, not the fact that they are stored as global and shared... 20:28
pmurias TimToady: why doesn't the file start in a lexical package?
ruoso have run :(
TimToady there are no lexical packages
pmurias ?
ruoso have *to* run, actually... 20:29
TimToady or they all are, in another sense
anyway, I have to go too...
ruoso later &
pmurias S10:05
pmurias TimToady: S10:55 20:30
pugs_svn r22348 | azawawi++ | [pugs] Fixed Use of uninitialized value $ENV{"PUGS_EMBED"} in pattern match (m//) 20:39
pmurias moritz_: do you think "module *Foo { our $bar = 0; sub baz { return $bar++ } };" is not DWIMmy enough 20:50
moritz_ pmurias: can you explain in two sentences to the average perl programmer why you need that * before the Foo? 20:55
pmurias so all of you package variables are shared by everything that uses your module 21:00
i don't consider the average programmer to understand less than i do 21:01
moritz_ he does
pmurias he shouldn't be changing the variables in the modules i'm using then ;) 21:06
pugs_svn r22349 | azawawi++ | [pugs] Removed warning: defaultUserHooks in Setup script is deprecated. 21:23
rakudo_svn r31390 | moritz++ | [rakudo] complete rewrite of tools/update_passing_test_data.pl, now the 22:01
r31390 | moritz++ | output is much more informative (but less copy&paste frindly)
moritz_ std: {:a<1>, :b(2)} <a b c> 22:08
p6eval std 22349: OUTPUT[parse failure␤]
moritz_ std: (1 | 3)<3 22:09
p6eval std 22349: OUTPUT[parse failure␤]
moritz_ std: print < 3 22:11
p6eval std 22349: OUTPUT[parsed␤]
moritz_ std: reverse<1 2 3> 22:12
p6eval std 22349: OUTPUT[parsed␤] 22:12
pugs_svn r22350 | moritz++ | [t] moved listquote.t to spec/, deleted bogus tests, and rewrote many others 22:16
r22350 | moritz++ | to use eval_dies_ok.
r22350 | moritz++ | Also updated TASKS.
r22351 | azawawi++ | [pugs] Reverted Setup.lhs from previous fix to clear warning 22:17
ahmadz_ moritz: Cabal really complicates things 22:18
pugs_svn r22352 | azawawi++ | [pugs] svn ignore on *.hi, Setup, config for third-party 22:30
moritz_ azawawi++ # pugs build system
pugs_svn r22353 | azawawi++ | set svn ignore on remaining ext/* temp files 22:35
r22354 | azawawi++ | [pugs] Last of the svn ignores 22:39
r22355 | moritz++ | [t/spec] fixed syntax errors in listquote.t, moritz-- 22:42
r22356 | moritz++ | [t/spec] fudged listquote.t for rakudo, and remark on testing 22:45
rakudo_svn r31391 | moritz++ | [rakudo] added listquote.t to spectest_regression, and brought back into 22:52
r31391 | moritz++ | alphabetical order
pugs_svn r22357 | moritz++ | [t/spec] fudged undef.t for rakudo 23:07
r22358 | moritz++ | [t/TASKS] undef.t is now fudged, remove from the list 23:08
rakudo_svn r31392 | moritz++ | [rakudo] added undef.t to spectest_regression.data 23:13
r31392 | moritz++ | (funnily it has less undef warnings than int.t)
ruoso @tell pmurias, 'package *Foo' doesn't seem to make much sense, since 'package Foo' is already 'our package Foo' which means that it creates a lexical alias "Foo" for the package with the same name which is stored as a member of the package we're at. Considering the file starts to parse in package *, the package is seen as just 'Foo' inside this lexical scope and by anyone who "use" or "require" Foo... 23:52
lambdabot Consider it noted.
ruoso @tell pmurias, but is globally registered as *Foo. What you seem to be talking about is another type of scope visibility... something like... "my package Foo is export {...}" 23:54
lambdabot Consider it noted.
ruoso @tell pmurias, but still, this only refers on which names are bound to the package, the package instance is still the same in all cases, the only difference is the way to access it. 23:56
lambdabot Consider it noted.

Powered by Cro and the Raku® Programming Language.

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

Thank you!