Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Parrot Developer Summit: 2200 UTC 29 Jan | Goals: Fix ipv6-related failures | Test imcc_interfaces and annotations-tree branches
Set by moderator on 26 January 2011.
allison lucian: oh, we're both right hugunin.net/story_of_jython.html 00:00
lucian: I guess it doesn't surprise me that people would give more credit to Guido, it kind of boosts the "validity" of Jython as a "true" Python
00:02 bacek_ joined 00:20 bacek_ left 00:26 bacek joined
chromatic pmichaud, I'm comfortable implementing some/much/all of 6model in Parrot. Replacing the existing object model makes sense. 00:27
pmichaud I think that's all that we're looking for at the moment.
I'm also pleased that Parrot has been able to use nqp in the past for some of its internals, and I think it makes sense going forward, but I'm completely understanding if that's not the case. 00:28
sorear chromatic: What is the status of the sixperl minutes backlog?
chromatic You know my reservations there, especially given Pugs. 00:29
pmichaud absolutely.
they are still noted, and if/when I see multi-backendness causing us issues I plan to put a stop to it.
chromatic sorear, I have minimally formatted notes. I could forward them to you for publishing if you volunteer.
pmichaud at least as far as "core goals" goes.
sorear allison: I've spoken to people deeply involved in the IronLanguages project
chromatic It's not just the cost of supporting them (and the question of whether anyone's going to take advantage of that feature).
sorear allison: what I've heard from them is that the main reason people are interested is interop with other libraries, and the main reason people don't follow through is because Iron* starts up way too slow, due to compulsory JIT and bad handling of dynamism 00:30
chromatic The further NQP diverges from Parrot's semantics (and, as I realized five minutes ago, the less it makes demands of Parrot so we can improve Parrot's semantics), the less competitive Parrot *can* be with regard to NQP.
That's always Parrot's advantage for Rakudo, that we *can* change what Parrot does to improve Rakudo. 00:31
pmichaud I think that's a useful insight. It'll take me a bit to digest it.
chromatic That's the source of a lot of my frustration, that it hasn't happened enough.
pmichaud That was the source of my frustration for much of Parrot development :-) 00:32
chromatic I should have said something earlier, but it didn't coalesce in my mind until a few minutes ago.
There are a lot of places in Rakudo where I want to optimize things, but run into spots where it's doing things Parrot should be doing. 00:33
There have been a lot of crashes, bottlenecks, and memory leaks in those places too.
pmichaud I totally understand. I remarked privately to jnthn that I thought you were just having difficulty formulating/discovering what needed to be said.
chromatic Hence the "big wad of code" mentions.
I understand the desire for immediate action, especially considering deprecation policies and other design review. 00:34
pmichaud I'm also the first to admit that I've not been as open or good about publishing plans and descriptions as I need to be... I keep trying to improve
00:34 bacek left
pmichaud so, I'll keep working on it until someone finds a better way (or person) to do it :) 00:34
chromatic But for every place a HLL needs to work around a core API or semantic, we should at least weigh design alternatives. 00:35
pmichaud Yes. Rakudo guts (and NQP guts) are full of places where we've had to work around Parrot semantics. (more)
P6object was the first layer to work around Parrot core semantics, but it ultimately didn't go far enough.
chromatic That's probably the point we should have started to revise the design of the core semantics. 00:36
pmichaud Ultimately the nqp says largely "here are the core PMCs we think we need to begin to get Rakudo to run reasonably well"
*the new nqp
in some sense that's entirely keeping with the way HLLs were originally envisioned to work with Parrot -- that each would provide its own core PMCs to use and be dynamically loaded 00:37
if that's the way that nqp ends up being -- it's just another Parrot HLL used as the foundation for Rakudo -- that's pretty much okay with Rakudo devs for now
chromatic For something as fundamental as an object model though, that's a lot to reimplement.
pmichaud right 00:38
chromatic I really do see the value of NQP and PCT as part of Parrot though.
With two caveats.
1) The deprecation policy may constrain them too much, which is a shame.
pmichaud I agree totally. As jnthn++ can tell you, I gave up the notion of "no extra runtime for NQP" _very_ reluctantly and took a bit of time to come around to that conclusion. 00:39
chromatic 2) Backend portability is not of value to Parrot to support there.
pmichaud I agree with #1 and #2 both.
chromatic (Given complexity, the usage question, et cetera... and believe me, I understand sunk costs.)
pmichaud Indeed, this is why Rakudo is expecting to start targeting NQP_REVISION (where most changes will be taking place) instead of PARROT_REVISION over the near future.) 00:40
chromatic Is it possible for Parrot core to provide a PCT/NQP which other languages can customize as they need more features? Would that be useful to Rakudo and other HLLs?
pmichaud I think it's possible and possibly useful, yes.
Right now we haven't focused much on that.
chromatic That way if Rakudo wants more abstractions to make other backends possible, it can have them, but Parrot doesn't have to pay for that complexity? 00:41
pmichaud NQP is still intended to be extremely lightweight, yes.
we just had to move our notion of "lightweight" a bit.
chromatic NQP and Parrot both benefit from a tight but well-defined coupling. 00:42
pmichaud there's also a part of me that wonders if/when someday NQP will disappear entirely, and we just have Perl 6.
chromatic Within Rakudo?
jnthn Not until we write a *really* good optimizer.
:)
pmichaud right 00:43
chromatic I have to switch hats to think about that.
pmichaud right
at some point NQP might be not lightweight enough to deserve its own implementation separate from Perl 6. But I see that as being far in the future, if ever (more)
allison sorear: I've talked to the Iron* folks too, agreed
chromatic From Parrot's perspective (I haven't managed to remove that hat yet), we still need PCT with some minimal language.
pmichaud I do see the value of NQP as being a fairly minimal language for writing low-level stuff-ish 00:44
allison sorear: but, as much as people *say* they want interop, I know very few real-world projects that really go for multi-language implementation
chromatic How about this plan then.
* Port as much of 6model as makes sense to Parrot as dynpmcs 00:45
jnthn I'm dismayed that having spent a bunch of time carefully working out how to factor things in 6model, there's some automatic assumption that I've done stuff in it that inherently makes it worse than on Parrot than if I was only ever going to implement it on Parrot.
allison sorear: projects even go so far as using really inappropriate languages to solve some piece of their problem, just so they can stick to one language
chromatic * Port NQP to those dynpmcs
allison sorear: for example, java as a command-line language, major suck!
chromatic * Figure out separation points in NQP/PCT where some things make sense as parts of the Parrot core and other parts are extensions
mikehh chromatic: that sounds like an excellent plan 00:46
chromatic * Migrate features of extensions to Parrot where they make the most sense
jnthn, I don't make that assumption and I apologize for giving you that impression.
00:46 bacek joined
allison chromatic: aye, "migrate features" is key, as opposed to "swallow huge wodges of code that might not be a good fit" 00:46
chromatic allison, but also avoiding the "never try new dishes, because they might have a strange taste/texture at first" 00:47
pmichaud chromatic: that plan seems entirely reasonable to me
it's pretty much what I've been hoping for. I'm fine with there being readjustments of the nqp/parrot demarcation -- that's really what all of this has been about anyway
jnthn Especially as the first two steps kinda pretty much already happened. ;) 00:48
allison chromatic: I'm not even sure what that means
chromatic: fear of new features?
chromatic allison, or just never thinking about merging them for whatever reason.
allison chromatic: new features == good, implementations of new features might be good or bad, no prejudice
chromatic jnthn, how's that plan sound to you?
jnthn chromatic: It's mostly the path I've been following. The 6model core is pretty small. Parrot actually has the *best* implementation of it already today. It's exposed as 3 (though may drop to 2 later) dynpmcs and some dynops. Migrating that into Parrot where it makes sense works fine for me. 00:50
pmichaud chromatic: just keep in mind that for the next couple of months jnthn and I will have most of our energies digesting nqp and rakudo migration
as opposed to "how do we get this into core Parrot". I'm sure we'll advise and help where we can. 00:51
dukeleto jnthn: i think there was some miscommunication and I assure you that I am glad you are trying multiple backends to get the spec nice
00:51 bacek left
pmichaud Also, to ease migration I asked jnthn to prefix all of our custom dynops and other items with nqp_, so that there's no big naming issue with migrating to Parrot 00:51
i.e., so Parrot can claim the non-nqp_ prefixed names when they are adopted 00:52
jnthn Yes, will do that.
I think trying to get it into core Parrot until it runs Rakudo would be too early, fwiw. 00:54
Things *will* end up changing here and there.
chromatic Right, but the fewer flag days the better.
jnthn *nod* 00:55
00:55 bacek_ joined
pmichaud I have to head off to dinner; I'm comfortable with where the discussion has led and is heading. 00:57
jnthn should sleep too - need to travel to Stockholm tomorrow.
pmichaud chromatic: thanks for your comments, as always.
(and suggestions)
chromatic Thanks for letting me fumble through vague thoughts. 00:58
pmichaud No problem -- I know I have to do it a lot. Not used to seeing you have to go through the process though. :-)
chromatic My office is usually quieter.
allison heads to the airport 00:59
00:59 allison left
chromatic Also I have bleadperl code on another desktop, so I wasn't in a great mood to start. 00:59
01:01 nwellnhof left
Hackbinary hello 01:07
Tene hi 01:09
01:10 whiteknight joined 01:17 sjn joined
whiteknight sorry I'm so late to the meeting. Other parts of my schedule overflowed 01:24
cotto whiteknight, it happens. Knowing what you think about Parrot, I'm sure you couldn't help it.
whiteknight I do think it's the bee's knees 01:25
01:25 kid51 is now known as kid51_at_dinner 01:28 chromatic left
cotto bacek_, I like Lua's minimalist philosophy. 01:31
whiteknight chromatic: ping 01:39
some of this conversation looks like it got pretty heated. 01:42
cotto I'm still backscrolling too, but I think it ended well. 01:43
01:44 snarkyboojum left
mikehh whiteknight: I think it got resolved amicably at the end here 01:47
whiteknight yeah, I'm slowly getting there
mikehh once chromatic worked out what he wanted to say it was much clearer 01:48
chromatic++
whiteknight basically finished backlogging now. Seems I have a hell of a lot to write about 01:55
does anybody here have any questions about the IMCC work?
cotto brain numb. no think good 01:56
whiteknight okay. I'm always around if questions materialize
02:11 bacek_ left 02:34 lucian left 02:37 bacek joined
dalek TT #462 closed by pmichaud++: [TODO] Refactor handling of 'stages' in PCT::HLLCompiler 02:39
TT #462: trac.parrot.org/parrot/ticket/462
rrot: 0e83c3b | bacek++ | DEPRECATED.yaml:
Remove deprecated item which will not be implemented.
02:46 snarkyboojum joined
bacek cotto, ping 02:48
kid51_at_dinner /nick kid51 02:49
02:49 kid51_at_dinner is now known as kid51
bacek ETOOMANYSPACES 02:49
msg cotto Should M0 be CPS based? Or we are going to implement CPS on top of it?
aloha OK. I'll deliver the message.
cotto bacek, pong 03:05
on top 03:06
why do you ask
bacek cotto, ok than
cotto, thinking about M0 in background
cotto that's a good sign 03:07
bacek cotto, not really nowdays...
sorear CPS is a framework of thinking 03:10
cotto bacek, what makes you suggest lua's vm?
kid51 msg mikehh Your comments on TT #1954 would be welcome
aloha OK. I'll deliver the message.
sorear there's no decision procedure for "does this language use CPS?"
bacek cotto, because it's really small VM
cotto interesting that it has three ops out of 35 related to for loops 03:11
bacek sorear, hmmm. Not all HLLs will target M0 directly.
cotto, it's just for optimization of most commonly used Lua loops
sorear if you want to avoid being laughed at, you need to make function calls possible
cotto I like the size of the op set.
sorear so you need to offer some way for code to record "where was I before I entered this sub?" 03:12
dalek TT #1454 closed by jkeenan++: make failing for parrot when rakudo git repo path in $PATH environment ...
TT #1454: trac.parrot.org/parrot/ticket/1454
TT #1739 closed by jkeenan++: Latest CPAN Module Test::Builder caused test failure
TT #1739: trac.parrot.org/parrot/ticket/1739
TT #1775 closed by jkeenan++: Inline hash key_hash and compare functions
TT #1775: trac.parrot.org/parrot/ticket/1775
cotto bacek, are you suggesting using luavm directly or adoping heavily from its ideas? 03:13
sorear that information is called a "continuation"
bacek cotto, for now - just take a closer look at it.
sorear many languages only allow a single continuation per thread, and have a very specialized variable called a "stack" to hold it
cotto continues doing that
bacek sorear, yes. E.g. "atrodo's lorito" and "LuaVM" 03:14
sorear, and it was my question to cotto: Stack vs CPS
cotto It's times like this that I wish I knew Lua a little btter.
bacek cotto, you don't have to. LuaVM is quite generic. Lua's Table ~~ PMC. 03:15
cotto Whatever else you say, you can't call Lua's object model heavy.
bacek cotto, it's very lightweight, indeed. 03:16
plobsing Lua has some key differences from Parrot in how it interacts with C. Lua embraces C for all its worth (this is why people claim it is "easy to embed"). Parrot, seeing some of the shortcommings of C, tries to avoid it wherever possible (see for example complaints about inferior runloops). 03:17
IMHO, a wholesale shift directly to Lua would take a similar shift in the mindset of many parrot developers regarding the purpose of a VM. 03:18
that's not to say we can't plunder all the good ideas
cotto plobsing, I don't think anyone's suggesting we switch to Lua. 03:19
plobsing the wording was sufficiently ambiguous to me
cotto just explore their VM and plunder the awesome bits
bacek, nice job finding that paper 03:24
Coke What's the name of the book in "docs/book/draft" ? 03:26
kid51 I think it was the PIR book that allison and whiteknight wrote 03:29
Coke you mean allison and dan? 03:32
(and leo)
kid51 tinyurl.com/45d3mv2 03:35
mikehh kid51: just saw your message, was going to work on that a couple of days ago, but somehow missed doing it, will have to look later, need sleep now 03:37
kid51 night, night!
mikehh sleep - cu 03:38
Coke kid51: I think that's the one in book/pir
03:40 whiteknight left
kid51 git blame suggests it was something allison and chromatic were working on in 2009 03:40
bacek cotto, github.com/bacek/YAML--Tiny. Can we use JSON for DEPRECATED?... 03:42
Coke bacek: Ha! I already registered my preference to json >> yaml and was shot down. gluck. 03:45
er, "good luck"
dukeleto ~~
bacek: my plan is to make Lorito CPS-based 03:47
bacek: also, i don't know that any language will target M0. Only parrot internals will target M0 03:48
bacek: HLLs might want to target M1, though, which will have a MOP
bacek dukeleto, question was "Should be M0 be CPS based" :) 03:49
dukeleto bacek: ah. the answer is "yes" 03:50
bacek: at least that is what i am going for
bacek dukeleto, ok
cotto bacek, afk for a while. will look when I get back 03:52
dukeleto bacek: i am reading the Smalltalk-80 blue book as we speak :)
bacek dukeleto, is SmalltalkVM CPS based???
sorear What's the smallest Mx with memory safety?
04:02 kid51 left
dalek TT #910 closed by coke++: macport/ installing on OS X 04:02
TT #910: trac.parrot.org/parrot/ticket/910
TT #932 closed by coke++: Warnings in compiling bignum.pmc
TT #932: trac.parrot.org/parrot/ticket/932
TT #930 closed by coke++: build fails when sandbox path contains whitespace
TT #930: trac.parrot.org/parrot/ticket/930
dukeleto sorear: probably M1 04:04
bacek: as far as I can see, the idea of a "Context" and calling it that comes from Smalltalk
sorear: M0 is bare metal for parrot internals 04:05
bacek dukeleto, hmm. I'll try to squeeze some time to read it.
dukeleto bacek: i have been enjoying it. you can find them very cheap online, used.
bacek: much of the language of parrot internals seems to come from smalltalk 04:07
bacek dukeleto, I know that chromatic was pushing parrot into smalltalk direction. But I didn't realize how similar are two VMs.
dukeleto bacek: from what I see, pretty similar 04:08
04:13 JimmyZ joined
dalek TT #682 closed by coke++: Dynpmcs Don't Depend on Parrot::Pmc2c::* 04:18
TT #682: trac.parrot.org/parrot/ticket/682
TT #414 closed by coke++: [BUG] t/codingstd/c_cppcomments.t reports spurious error at hyperlinks
TT #414: trac.parrot.org/parrot/ticket/414
Coke msg pmichaud can you respond to TT#1198? Danke. 04:50
aloha OK. I'll deliver the message.
Coke msg cotto didn't you reject TT#1175?
aloha OK. I'll deliver the message.
dukeleto bacek: turns out smalltalk-80 is stack based, but also continuation-based. But it doesn't do CPS 05:12
bacek: it stores interp contexts in a stack
05:13
JimmyZ seems that cotto want CPS is on top of M0 and dukeleto wants M0 is CPS based. 05:14
bacek dukeleto, yeah... 05:17
dukeleto, speaking of yaml. Can we change current format slightly? 05:19
nopaste "bacek" at 192.168.1.3 pasted "Proposed change to DEPRECATED.yaml" (11 lines) at nopaste.snit.ch/29487 05:20
bacek dukeleto, see nopaste
dukeleto bacek: can you make that change in my branch? 05:23
bacek: you will see that i cleaned up the YAML considerably
bacek: leto/deprecations_as_data
bacek dukeleto, ok. 05:24
dalek rrot/leto/deprecations_as_data: 56c3abc | bacek++ | docs/changes/api.yaml:
Change format of api.yaml to be list of hashes
 05:29
bacek dukeleto, done
nopaste "bacek" at 192.168.1.3 pasted "Eat own dog food with nqp-based port of YAML::Tiny :)" (23 lines) at nopaste.snit.ch/29488 05:30
bacek dukeleto, see nopaste.snit.ch/29488 "good enough" for me :) 05:31
dukeleto, we can switch off from Perl5 for "api.yaml-handling-tools" 05:32
dukeleto good lord 05:34
dukeleto looks
bacek hate YAML even more now. 05:35
dukeleto, github.com/bacek/YAML--Tiny 05:37
dukeleto bacek: you are hilarious :) 05:38
bacek dukeleto, it was kind of funny, actually. 05:39
To port YAML::Tiny to nqp.
dukeleto bacek: why so?
bacek But my point about YAML still stand. YAML suck big time.
dukeleto, I didn't write any "high level code" in about last 6 month :) 05:40
cotto gets back and looks 05:44
dukeleto bacek: looks like you still can :) 05:46
cotto bacek, what format wouldn't you hate? 05:47
dukeleto bacek: not ok 1 - Parse failed 'Could not find sub split'
bacek: most of the test suite fails for me. Does this require a very new NQP? 05:48
bacek dukeleto, on your branch?
dukeleto bacek: no, in the YAML--Tiny repo
bacek dukeleto, yes, I fixed nqp-setting slightly. Better to use master parrot :)
or update your branch to master.
dukeleto bacek: hokey dokey 05:53
sorear Why -- ?
plobsing github converts punct to - by default 05:54
05:54 rurban_ joined
cotto bacek, thanks for working on that 05:55
plobsing also non-ascii. Ωη;)XD had this issue in spades. came out as ----XD
bacek dukeleto, ?
dukeleto bacek: yes?
cotto How long does it take to parse DEP.yaml?
bacek cotto, it's already parsable in leto/deprecations_as_data :) 05:56
dukeleto, "<dukeleto> bacek: hokey dokey"
dukeleto, success?
dukeleto bacek: that means "ok i will do that"
05:57 rurban left, rurban_ is now known as rurban
cotto I somehow haven't installed Parrot since 2.11.something 06:00
time to fix that
wheee 06:02
/usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.20.51-system.20100908 internal error, aborting at ../../bfd/merge.c line 872 in _bfd_merged_section_offset
/usr/bin/ld: Please report this bug.
I love parallel builds 06:03
dukeleto bacek: you need a 'clean' target in YAML::Tiny's makefile 06:11
bacek dukeleto, can you create repo in /parrot? I'll just push it in and everyone can cleanup/finish it 06:12
dukeleto bacek: yep, one sec
cotto and insall too 06:14
dukeleto bacek: github.com/parrot/yaml-tiny 06:15
06:15 theory left
cotto why not just put it in parrot.git? 06:16
dukeleto cotto: we can do that too, and will need to at some point
bacek dukeleto, pushed
cotto, I want to polish it little bit more before including into parrot.
cotto sure 06:17
bacek afk #
dukeleto cotto: also, we can try using it as a git submodule 06:19
cotto dukeleto, why not
dukeleto cotto: quite a PDS, today 06:25
cotto dukeleto, yeah really
dukeleto cotto: what is your take?
cotto I need some time to digest it, but it seemed to be more positive than negative 06:26
I was unprepared for how active it'd be. 06:27
sorear YAML::Tiny seems almost ... simple 06:28
I'd love to see something like it replace yaml.org as the de facto spec
06:50 allison joined 07:05 allison left 07:07 allison joined
dalek ml-tiny: e5358e7 | dukeleto++ | Makefile:
Add a clean Makefile target
 07:38
ml-tiny: ab874e1 | dukeleto++ | .gitignore:
Add a .gitignore
 07:39
ml-tiny: 911eeaa | cotto++ | Makefile:
make clean less picky, add an install target
 08:12
cotto 5.4 seconds to parse api.yaml 08:23
usable, but I'm looking forward to when it's .54 seconds 08:24
JimmyZ cotto, I'd like see your comment on trac.parrot.org/parrot/ticket/1992 08:28
dalek TT #1992 created by jimmy++: [NCI] callback sub parameter definition isn't unified with callback ... 08:32
TT #1992: trac.parrot.org/parrot/ticket/1992
08:32 Psyche^ joined 08:35 Patterner left, Psyche^ is now known as Patterner
JimmyZ msg plobsing I'd like see your comment on trac.parrot.org/parrot/ticket/1992 08:35
aloha OK. I'll deliver the message.
cotto JimmyZ, ok. I need to plow through the backlog of tickets. I'll make sure to address that one. 08:54
cotto sleeps
JimmyZ thanks , night
09:04 allison_ joined, allison left
dalek ml-tiny: 3ce229f | bacek++ | / (2 files):
Fix handling of 'inline nested hashes'
 09:05
09:05 JimmyZ left 09:48 contingencyplan left 10:28 fperrad joined
dalek ml-tiny: 487589a | bacek++ | t/11_meta_yaml.t:
Copy test from Perl5 YAML::Tiny
 10:37
ml-tiny: ef664df | bacek++ | t/02_basic.t:
Untodo test
p-cl-parser: 0e62a62 | moritz++ | do.pl:
fix attribute name, masak++
 10:39
moritz oops, that should have gone to #perl6
10:45 sheant joined
dalek ml-tiny: 5a55e2b | bacek++ | / (4 files):
Generate Undef instead of Nulls. Reclaim few more tests
 11:13
ml-tiny: 4d712bc | bacek++ | / (2 files):
Fix parsing YAML header
 11:21
11:47 whiteknight joined
dalek p-rx/nom: 29337fb | moritz++ | src/metamodel/reprs/P6opaque.c:
distinguish "P6opaque attributes" error messages (no additional value for the user)
 11:59
nopaste "mikehh" at 192.168.1.3 pasted "problems with tt1954_eliminate_make_docs branch" (40 lines) at nopaste.snit.ch/29545 12:08
12:27 Eclesia joined
Eclesia hi 12:27
12:38 Eclesia left 12:43 sheant left
whiteknight good morning, #parrot 12:46
13:35 kid51 joined 13:52 sheant joined 13:54 rurban_ joined 13:56 whiteknight left 13:57 rurban left, rurban_ is now known as rurban 14:01 kid51 left 14:04 ambs joined
szabgab anyone coming to FOSDEM ? fosdem.org/2011/interview/david-fetter-2011 14:05
sjn wishes he could :-( 14:31
I _really_ wanted, but alas, I can't afford it
14:40 Kristaba joined
Coke someone on the board should point OSUOSL at TT #1838 15:53
(git submodule--) 16:05
msg cotto someone on the board should point OSUOSL at TT #1838 - not much we can do about it. 16:06
aloha OK. I'll deliver the message.
cotto ~~ 16:43
17:00 ambs left 17:25 kid51 joined 17:34 NotFound left 17:42 tadzik left 17:43 tadzik joined 17:54 theory joined
Hackbinary hello 18:17
is there a library that I have to include in an actions.pm file to able to use say() to print messages to the console, or is there another print funciton that I should .. just for debugging. 18:18
cotto It's nice to see tickets going away. 18:19
Hackbinary, nqp-setting.pm or something similar
arnsholt There's also pir::say() 18:20
cotto pir::load_bytecode("nqp-setting.pbc");
arnsholt Which does pretty much the same thing IIRC
cotto but you have to type "pir::", which is less lazy than necessary 18:21
;)
arnsholt True. But pir::load_bytecode is kinda long as well ;)
Depends on how much say()ing is required I guess =)
cotto your call 18:22
there's some other functions that it also provides that make life a little nicer
Hackbinary cool :)
18:45 contingencyplan joined
dukeleto ~~ 19:03
cotto hi dukeleto 19:04
dukeleto cotto: how do you feel about the leto/deprecations_as_data_branch?
cotto: also, hello :)
bacek: you changed the format of the api.yaml in my branch, which I like, but you didn't change the scripts that use it => -1 19:06
dukeleto goes outside for a change 19:07
cotto dukeleto, reviewing now 19:08
thanks for cleaning up the file 19:09
19:19 fperrad left 19:20 kid51 left 19:21 jan left
cotto I'm still not a fan of the name "api.yaml" and the location in docs. 19:31
I don't like having something we expect to change frequently in docs/ 19:32
dukeleto had to take out the recycling 19:37
cotto: where do you want it to live?
cotto: what do you want it called?
cotto: API.yaml in the root directory ? 19:38
cotto: i really don't care
cotto dukeleto, I'm trying to figure that out.
bacek's change looks like a good idea. Indexing an array by deprecation name struck me as an unusual choice. 19:39
dukeleto cotto: i have updated the scripts to use that format 19:41
cotto beat me to it
dukeleto incoming 19:43
dalek rrot/leto/deprecations_as_data: 52cf771 | dukeleto++ | / (5 files):
Make api.yaml scripts use the new format that makes bacek++ and cotto++ happy
dukeleto cotto: the name isn't that important. I hear that you want it in /, is that correct ? 19:44
cotto: i think API.yaml works for now, we can always change it
cotto: our scripts provide the layer of abstraction between the name and end-users
cotto: so our end-users just go ahead and use the scripts, which know where to look. Only parrot devs manually edit that file
Hackbinary hello
dukeleto Hackbinary: howdy
cotto dukeleto, I'd prefer / and I agree about the details 19:45
dukeleto cotto: what about API.yaml in / ? Shall I do that?
Hackbinary where is the best place to lookup information on PAST structure information
?
cotto "API.yaml" isn't a perfect fit, but I don't care to bikehsed it any further.
Hackbinary :D
cotto dukeleto, +1
dukeleto cotto: do you want it to be a SHOUTING file? or api.yaml ?
cotto EBIKESHED
dukeleto cotto: ok, i will make it happen
cotto dukeleto++ 19:46
dukeleto Hackbinary: parrot/tree-optimization is probably a good place
Hackbinary: look at it's test suite
Hackbinary: github.com/parrot/tree-optimization
Hackbinary: that library will also help you optimize your PAST
cotto: one other issue 19:47
cotto ok
dukeleto cotto: i want something like api.yaml and old_api.yaml, where, instead of deleting stuff from api.yaml, we put it into a historical file
cotto: instead of that, we could give stuff in api.yaml the tag of "historical" or something 19:48
cotto dukeleto, why not just mark it as "old" and stick it at the bottom of the file?
dukeleto cotto: what thinks you?
cotto: sure, we will have a tag called "old", that is reasonable
cotto a single file appeals to my laziness
dukeleto cotto: i like that too
cotto: where should i put docs relating to api.yaml ?
cotto dukeleto, if they're short they could go inline as comments at the beginning of the file 19:49
dukeleto cotto: was thinking that as well. is there something like a YAML comment ?
cotto if not, maybe README.api.yaml or something suitaly obvious
*suitably 19:50
wfm
dalek rrot/leto/deprecations_as_data: b7c3ab4 | dukeleto++ | / (10 files):
docs/changes/api.yaml is now api.yaml
 19:54
rrot/leto/deprecations_as_data: b67a954 | dukeleto++ | t (4 files):
Tell scripts that api.yaml has moved
dukeleto cotto: ok, i gonna merge this
cotto: we are not using yaml-tiny yet, still using my perl 5 tools 19:55
cotto: others can bikeshed that
cotto: i just want this data in a usuable format
cotto: i am sure we will have many tools to interface with it, in various languages
cotto dukeleto, go for it!
I'd like to revert a3f6638ef39 and mark the changes it removes as "completed", but there's no rush. 19:57
dukeleto cotto: i think i will deal with that in my merge 19:58
cotto great 19:59
dukeleto lots of dumb conflicts
cotto yeah 20:00
looks like a couple others got removed too
dukeleto cotto: can you look at docs/stability.pod ? 20:02
cotto: it is severely out of touch with reality
cotto: it has terms we never use
cotto dukeleto, sure 20:04
I remember when particle introduced that idea.
There's nothing wrong with it but it never really caught on.
dalek rrot: 56c3abc | bacek++ | docs/changes/api.yaml:
Change format of api.yaml to be list of hashes
 20:05
rrot: 52cf771 | dukeleto++ | / (5 files):
Make api.yaml scripts use the new format that makes bacek++ and cotto++ happy
rrot: b7c3ab4 | dukeleto++ | / (10 files):
docs/changes/api.yaml is now api.yaml
rrot: b67a954 | dukeleto++ | t (4 files):
Tell scripts that api.yaml has moved
rrot: f4fcd0e | dukeleto++ | / (11 files):
Merge branch 'leto/deprecations_as_data'

Conflicts:
  \tMANIFEST
  \tdocs/project/cage_cleaners_guide.pod
  \tdocs/project/release_manager_guide.pod
  \tdocs/project/support_policy.pod
  \tdocs/stability.pod
  \tsrc/pmc/object.pmc
dukeleto cotto: it has terms like "Private" and "Evolving" that we never use
cotto The TODO item is telling. 20:07
dukeleto, did you add a tag to the completed items? 20:09
looks like not 20:10
the nice thing about having this be data is that can (semi) automatically check to see if the relevant tickets have been closed. 20:11
It's times like this that I wish trac had an api. 20:13
I guess we can resort to screen scraping. 20:16
dalek rrot: 3f45e06 | dukeleto++ | api.yaml:
Mark recently removed deprecations as 'done' in api.yaml
 20:17
rrot: 947fb07 | dukeleto++ | DEPRECATED.yaml:
Remove DEPRECATED.yaml, which is now called api.yaml
rrot: e23d5c7 | dukeleto++ | tools/dev/show_ (2 files):
Make show_(deprecated|experimental).pl skip things tagged as 'old'
dukeleto cotto: there ya go
cotto: we are now in the era of deprecations as data 20:18
cotto looking good 20:20
20:24 zby_home left
dalek TT #1888 closed by dukeleto++: Deprecations as data 20:25
TT #1888: trac.parrot.org/parrot/ticket/1888
dukeleto goes afk 20:26
cotto: we have completed 1/3 goals for 3.3
cotto: time to focus on Lorito, for me
cotto dukeleto, did you see bacek's link to the Lua VM intro? 20:31
I've got a printed copy sitting by me and am planning on going through it as soon as I can concentrate.
dukeleto cotto: i bookmarked it, but haven't read it yet 20:32
moritz through the -w switch i learned that rakudo relies on Undef stringification, which is deprecated. Now... what I can about that?
dukeleto cotto: it looks good
moritz: we should have a TT and wiki entry for it
moritz: and if we don't, we will make them
cotto what dukeleto said 20:33
dukeleto moritz: also, take a look at tools/dev/show_deprecated.pl and api.yaml in the parrot repo
moritz: if you have any suggestions for making it easer for Rakudo devs to learn about experimental/deprecated features, i would love to hear them 20:34
moritz: there is also a tools/dev/show_experimental.pl
moritz $ perl tools/dev/show_deprecated.pl|grep Undef
Use of uninitialized value $eligible in concatenation (.) or string at tools/dev/show_deprecated.pl line 39.
dukeleto moritz: yep, that is a bug in our data which needs to be fixed
moritz: some items are missing tickets and/or eligible versions 20:35
moritz neither of them mentions Undef
so... does this mean the Undef stringification deprecation is gone?
or do I just misremember?
dukeleto moritz: perhaps that deprecation is not in our data, or it was removed before we switched to our new system
cotto moritz, if it's not implemented and it's not mentioned, you're clear
dukeleto moritz: not sure, the code that -w uses and api.yaml could very well be out of sync
jnthn moritz: What does Undef stringify to, ooc?
dukeleto moritz: can you gist the errors warnings that you get? 20:36
moritz rakudo: say ~pir::new('Undef')
p6eval rakudo 549d2a: OUTPUT«␤»
moritz jnthn: empty string
cotto github.com/parrot/parrot/commit/3be8a9cee is all I can find
jnthn moritz: If pmichaud++ agrees, we could s/Undef/NQPMu/
moritz $ ./parrot_install/bin/parrot -w perl6.pbc -e ''
Stringifying an Undef PMC
current instr.: 'perl6;PAST;Compiler;as_post' pc 4510 (compilers/pct/src/PAST/Compiler.pir:1084)
that's with RELEASE_3_0_0-289-gbb69595 20:37
jnthn moritz: Undef really doesn't exist in Perl 6, so I'm not sure NQP using the notion of Undef is so wise.
moritz jnthn: seems to be from the PAST/POST compilers 20:38
jnthn Oh.
OK, guess that's harder to deal with in a hurry.
20:49 zby_home joined 20:51 tadzik left, tadzik joined 20:52 zby_home left
moritz jnthn: no hurry, since it's not in api.yaml as a deprecation :-) 20:56
jnthn :)
nopaste "bacek" at 192.168.1.3 pasted "show_expetimental.nqp for cotto and dukeleto :)" (46 lines) at nopaste.snit.ch/29613 21:02
bacek cotto, it works :) 21:03
tadzik nqp is quite nice 21:05
21:05 nwellnhof joined
tadzik (to read, to look at) 21:05
bacek tadzik, it's subset of Perl6 :) 21:06
nwellnhof bacek: how did you get the impression that atrodo's lorito is stack-based or has single byte opcodes?
bacek nwellnhof, rtfs and docs
nwellnhof yes, i did. it definitely hasn't single byte opcodes and the stack is only used for argument passing. 21:07
bacek "stack used for argument passing" is description of "stack-based VM" 21:08
nwellnhof well, it isn't really a stack. the opcodes are called push and pop, that's all.
lua vm is much more stack based. 21:09
21:10 Eclesia joined
Eclesia hi 21:11
bacek nwellnhof, yes, Lua's calling convention even more awful :)
nwellnhof but very efficient
bacek nwellnhof, yes, single memcpy to pass args. Little bit more work for RETURN. 21:13
and with smart register allocator allows interesting optimizations 21:14
cotto bacek, nice nqp script 21:15
bacek cotto, direct port of dukeleto++ show_experimental.pl :)
cotto bacek, do you know if Lua is used for any large project or if it's just for embedding? 21:16
bacek cotto, it's quite popular in gamedev as scripting language. I embedded it into some webframework few years ago. 21:17
cotto, not sure about "standalone big lua app"
nwellnhof en.wikipedia.org/wiki/Lua_%28progra...plications
cotto Yeah. The tool-assisted speedrun people do cool things embedding it into emulators.
bacek cotto, if someone (including you) can finish multiline scalars parsing in yaml-tiny it's ready. 21:19
either as ext/yaml-tiny or runtime/parrot/library/YAML/TIny 21:20
I'm not going to implement serialization in it anyway
afk # $dayjob
cotto looks like Prosody is ~20kloc of Lua 21:21
Hackbinary cotto, bacek I've seen lua used on linksys, dlink and netgear routers
cotto Yeah. I'm looking for applications where it's not used as an embedding language. 21:22
I'm wondering if its high suitability for embedding means it's lta for larger apps.
though the counterargument to any mention of language suitability is PHP 21:23
bacek cotto, Lua language - probably no. Lua VM - is kind of good enough :)
21:26 cognominal left 21:29 cognominal joined
atrodo has a lot of backscrolling to do 21:34
cotto atrodo, indeed. 21:35
21:55 rurban_ joined 21:59 rurban left, rurban_ is now known as rurban
atrodo I hope someone has a chance to write a tl;dr version 21:59
22:10 PacoLinux left 22:13 Eclesia left 22:46 whiteknight joined
pmichaud draft of nqp plan for comment/improvement before I publish it to parrot-dev 22:47
pmichaud.com/sandbox/nqp.txt
22:50 Kristaba left
dalek rrot: e731419 | bacek++ | src/nci/libffi.c:
Pacify compiler about absense on default case in switch.
 22:52
rrot: a00d590 | bacek++ | src/nci/libffi.c:
Avoid (useless) cast INTVAL to size_t
rrot: 01fabfb | bacek++ | config/auto/warnings.pm:
Remove -Wbad-function-cast.

According to gcc info it's kust helps to catch undeclared functions error. We do have special -Wimplicit to catch it.
rrot: e19f32b | bacek++ | src/runcore/main.c:
Use explicit const_cast to pacify compiler.
rrot: 2709a45 | bacek++ | MANIFEST:
mk_manifest_and_skip
cotto pmichaud, reading now 23:03
and for the next several minutes, apparently
glad to see that "nqp" is being defined as separate from the current nqp-rx 23:05
23:08 sheant left
cotto pmichaud, thank you for spelling that out. 23:09
mikehh cotto: what are your thouhts on this? 23:11
cotto It's a natural move for the Rakudo hackers to make. Parrot's use of nqp-rx in core does seem less than optimal now, though. 23:12
mikehh I think we should use whatever tools are available (maybe modified) but I don't see a major problem with "nqp" 23:14
cotto It's been useful as a higher-level abstraction over Parrot guts, and nqp explicitly will be less guts-oriented. 23:15
23:15 hudnix left
cotto (from a Parrot core dev pov) 23:15
23:16 AzureSto_ joined
mikehh as I see it we can use it to develop other interfaces as necessary 23:16
23:17 hudnix joined 23:18 AzureStone left
mikehh bacek: g++ don't like the cast in src/runcore/main.c 23:21
cotto I wondered about that. 23:22
mikehh src/runcore/main.c: In function ‘void parrot_hash_oplib(parrot_interp_t*, op_lib_t*)’: 23:24
src/runcore/main.c:347:50: error: invalid const_cast from type ‘const char*’ to type ‘void*’
src/runcore/main.c:350:58: error: invalid const_cast from type ‘const char*’ to type ‘void*’
src/runcore/main.c:351:54: error: invalid const_cast from type ‘const char*’ to type ‘void*’
23:30 hudnix left 23:48 kid51 joined
kid51 "And yes, the new NQP is explicitly designed to enable and other languages ..." -- the 'and' is superfluous. 23:58
"... we may increase of efforts in this area." s/of/our/ 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!