Camelia, the Perl 6 bug

IRC log for #parrot, 2009-11-02

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:05 ash_ joined #parrot
00:07 brooksbp_ joined #parrot
00:08 NotFound clear winxed style, revision 2: winxed -e "print((new 'FileHandle').open('tput clear', 'rp').readall())"
00:09 NotFound Try that with python X-)
00:13 payload joined #parrot
00:29 theory joined #parrot
00:48 brooksbp joined #parrot
00:53 abqar joined #parrot
01:18 Whiteknight joined #parrot
01:26 b0nk joined #parrot
01:26 b0nk lo
01:28 JimmyZ joined #parrot
01:33 Whiteknight hello
01:33 ash_ joined #parrot
01:35 mokurai1 joined #parrot
01:36 b0nk joined #parrot
01:41 JimmyZ Whiteknight: hello, good localtime.
01:43 Whiteknight hello JimmyZ
01:44 kiwichris joined #parrot
01:55 kid51 joined #parrot
02:04 mokurai joined #parrot
02:06 cognominal joined #parrot
02:18 JimmyZ joined #parrot
02:21 dalek TT #1174 created by kjs++: Disallow .local declarations in long-style call statement
02:25 ash_ so, Whiteknight, i had some questions about L1 if your not busy
02:27 Whiteknight ash_: sure thing
02:29 ash_ I guess, first off, i have been reading your posts on L1, and chromatics, and looking through the things on the wiki on L1, hows that going? I am curious about how thats going to work
02:29 ash_ I guess, some of the things that confuse me are if L1 is going to emit C code, can it only statically compile stuff?
02:30 ash_ i am confused how all of that works together really
02:30 ash_ if your going to have a compiler for L1 code, or just runtime support for it
02:31 dalek tracwiki: v6 | coke++ | StringsTasklist
02:31 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Str​ingsTasklist?version=6&action=diff
02:37 dalek tracwiki: v7 | coke++ | StringsTasklist
02:37 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Str​ingsTasklist?version=7&action=diff
02:39 chromatic What we'll eventually execute is only Lorito ops.
02:42 Whiteknight ash_: L1 is just another programming language that has a very simple translation into machine language
02:42 Whiteknight so instead of writing things in C, we write it in Lorito, which can be compiled down to machine language just like C
02:42 Whiteknight except simpler then C
02:43 Whiteknight the easy mapping between Lorito and machine code means that anything written in Lorito can be compiled ahead of time, or JIT'd at runtime without much effort
02:43 Whiteknight once we have a Lorito "compiler", we can rewrite all our ops definitions in Lorito instead of C
02:44 Coke RT: 126
02:45 Whiteknight now, consider the case where Lorito is LLVM code, or a thin superset of that. LLVM does the conversion Lorito->machine code natively
02:45 dalek parrot-linear-algebra: 8b58ae2 | Whiteknight++ |  (2 files):
02:45 dalek parrot-linear-algebra: add an is_equal vtable and tests. Add tests for the clone vtable using the new is_equal functionality
02:45 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/8b58ae299bde4c858a2fc3480dfc2ab388322632
02:45 dalek parrot-linear-algebra: 1bcaec7 | Whiteknight++ | t/10-nummatrix.t:
02:45 dalek parrot-linear-algebra: add tests for the resize method
02:45 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/1bcaec7f5582df5bdb8c7d290d02de3601430400
02:46 dalek parrot-linear-algebra: b844ab6 | Whiteknight++ |  (2 files):
02:46 dalek parrot-linear-algebra: upgrade the is_equal vtable to handle lazily tranposed matrices. This isn't good for performance, but we can optimize later. Add tests for transpose and mem_transpose methods
02:46 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/b844ab6c1108c4443fbd93bc4b15597a3f4b8cd9
02:46 dalek parrot-linear-algebra: 66f7571 | Whiteknight++ | t/10-nummatrix.t:
02:46 dalek parrot-linear-algebra: add tests for fill method
02:46 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/66f75714ae5ce4c1fd14333cb54d39e33fde0b2d
02:46 Whiteknight so now, for things like the fast core or switch core, LLVM can compile them down to machine code ahead of time. But for the JIT core we can assemble ops definitions together into large methods, and compile that as a group
02:46 Whiteknight ...and optimize as a group
02:47 Whiteknight in short, Lorito will serve the same purpose as C is currently serving (low-level implementation language) except it has the property that it's very very simple and amenable to JIT
02:50 dalek tracwiki: v8 | coke++ | StringsTasklist
02:50 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Str​ingsTasklist?version=8&action=diff
02:52 dukeleto what does the underscore function do in this line of code? : Parrot_ex_throw_from_c_args(INTERP, NULL, EXCEPTION_OUT_OF_BOUNDS, _("Array: Unknown slice type"));
02:52 dukeleto that is from line 647-648 in src/pmc/fixedpmcarray.pmc
02:53 dukeleto currently that call to _ is blocking porting to RTEMS, it shows up as undefined at link time with the cross-compiling setup
02:53 dukeleto any body know what is up with it?
02:55 dukeleto include/parrot/parrot.h
02:55 dukeleto 236:#  define _(s)                 gettext(s)
02:55 dukeleto 242:#  define _(s)                 (s)
02:55 dukeleto what the junk is up with that?
02:56 Zak joined #parrot
02:56 chromatic l10n and i18n
02:57 dukeleto chromatic: i see, says the blind man
02:57 dukeleto the calls to _() are blocking porting to RTEMS right now
02:57 chromatic Somehow you have to get the #define on line 242 then.
02:58 nopaste "dukeleto" at 69.64.235.54 pasted "Current link failure on RTEMS port" (23 lines) at http://nopaste.snit.ch/18527
02:58 dukeleto this was given to me, run against parrot 1.6.0
02:59 chromatic Somehow they're defining PARROT_HAS_GETTEXT then.
03:00 dukeleto chromatic: and they shouldn't?
03:00 dukeleto chromatic: what kind of gettext's do we support?
03:07 kiwichris joined #parrot
03:07 dalek TT #1175 created by particle++: Get external Perl5 modules out of the parrot repo
03:11 Coke I would dig up particle, as I recall he's behind any attempts at gettext.
03:12 Coke ... unless this is just a x-compilation issue.
03:13 dukeleto 'ello
03:13 theory joined #parrot
03:13 dukeleto msg particle are you the gettext() man?
03:13 purl Message for particle stored.
03:14 dukeleto msg particle fix this: http://nopaste.snit.ch/18527 and you get a pony
03:14 purl Message for particle stored.
03:16 chromatic They should only define that symbol if they support libintl.h and if it's installed somewhere Parrot can find it during compilation.
03:17 brooksbp joined #parrot
03:18 mokurai1 joined #parrot
03:20 brooksbp joined #parrot
03:21 dukeleto chromatic: ok, i think i have worked passed that issue with them
03:21 dukeleto chromatic: now we are dealing with powl() being an optional posix extension
03:26 dukeleto we should have a Configure-time check for wether powl exists
03:29 dukeleto pct?
03:29 purl it has been said that pct is the Parrot Compiler Toolkit
03:30 Coke kid51++ # forcing me to change my email as I was composing by closing a ticket.
03:31 Coke dukeleto: yes. instead of that define hackery, there should be a config check for it.
03:31 Coke (and then you can override it for that platform.)
03:33 dalek TT #1176 created by dukeleto++: Configure-time check for whether to use powl() or pow(), since powl() is ...
03:35 dukeleto powl isn't even needed either. pretty hilarious. just youthful indescretion
03:36 janus joined #parrot
03:36 RobertLJ joined #parrot
03:37 Coke if it's not needed, kill it?
03:38 dukeleto Coke: let me see if the test suite passes if I change it to pow()
03:39 kiwichris Ah ok.
03:39 dukeleto kiwichris: hell!
03:39 dukeleto hello, even
03:39 * dukeleto is too excited
03:40 dukeleto #if NUMVAL_SIZE == DOUBLE_SIZE
03:40 dukeleto #  define POW pow
03:40 dukeleto #else
03:40 dukeleto #  define POW powl
03:40 dukeleto #endif
03:40 dukeleto lulz
03:40 dukeleto that is wronger than wrong
03:40 dukeleto /* local macro to call proper pow version depending on FLOATVAL */
03:42 dukeleto kiwichris: you are using the released version of parrot 1.6.0, correct?
03:43 dukeleto kiwichris: does rtems fiddle with NUMVAL_SIZE ?
03:43 kiwichris dukeleto, I downloaded 1.6.0 from the Parrot web site and no I do not know. I need to build on Linux (FC9) then change for RTEMS.
03:43 kiwichris dukeleto, there could all sorts of things I have missed. The FC9 box is 64bits. Does that help ?
03:45 dukeleto kiwichris: it is another part of the puzzle :)
03:45 kiwichris dukeleto, I am looking for the define now. I suspect it is the wrong size. Have had this before.
03:46 dukeleto kiwichris: what I can infer is that NUMVAL_SIZE != DOUBLE_SIZE on whatever you are compiling/linking. I am just wondering if that is correct.
03:47 kiwichris dukeleto, #define NUMVAL_SIZE 4, and #define DOUBLE_SIZE 8
03:48 kiwichris dukeleto, I am building for a 32bit i386
03:48 dukeleto kiwichris: i guess it comes down to powl() being optional. we should check for it, but we don't
03:51 dukeleto we assume that if NUMVAL_SIZE != DOUBLE_SIZE , powl() should be used. i guess that is just not always true.
03:51 dukeleto powl() should only be used if it exists
03:51 kiwichris kiwichris, agreed
03:53 chromatic powl() is C99 and POSIX 2001.  powl() returning only a double, not long double, is C89.
03:59 Andy joined #parrot
04:01 kiwichris dukeleto, Any idea what Parrot_set_config_hash is ?
04:02 dukeleto kiwichris: hmmm
04:03 dukeleto kiwichris: what trouble is it causing you?
04:03 kiwichris dukeleto, unresolved external
04:03 kiwichris dukeleto, called in main.c
04:05 dukeleto kiwichris: src/parrot_config.c
04:05 dukeleto src/parrot_config.c
04:05 dukeleto 15:void Parrot_set_config_hash(void);
04:06 dukeleto 'make coretest' passes on darwin/x86 when I change POW to be pow()
04:10 Coke dukeleto: as a stopgap, you could change the define to also respect something you coudl pass in with -DNOREALLYUSEPOW
04:10 dukeleto Coke: if 'make fulltest' passes with just using POW=pow, can I commit that?
04:12 Coke dukeleto: I abstain.
04:12 Coke but if you close 10 RTs, I'll vote yes. =-)
04:14 Coke msg pmichaud will nqp-rx make it easier to implement the tcl RE syntax?
04:14 purl Message for pmichaud stored.
04:29 Coke is there a way to change the output of Parrot_sprintf_format so that there are no leading 0s on an exponent?
04:30 Coke (or do I have to post-process it myself?)
04:31 dukeleto Coke: i don't know about sprintf
04:31 dukeleto Coke: the new nqp-rx runs faster and has variable interpolation and implements the perl 6 regex spec more correctly
04:32 dukeleto Coke: i would guess that interpolation is the biggest win for you
04:32 dukeleto Coke: 'make fulltest' passes when I change POW=powl to POW=pow
04:34 Coke dukeleto: my offer of a yes vote for closing out 10 RTs still stands. =-)
04:35 dukeleto Coke: ok. I am verifying that fulltest also passes on linux. I will look at some RTs :)
04:37 kiwichris dukeleto, fixed the last external and all links. Many thanks. Will try and run in qemu.
04:38 dukeleto kiwichris: awesome!
04:38 purl awesome is a window manager or at http://awesome.naquadah.org or awesome!
04:38 dukeleto purl, go play in traffic and die in a fire
04:38 purl dukeleto: excuse me?
04:38 dukeleto purl, go play in traffic and die in a fire is on the double!
04:38 purl OK, dukeleto.
04:39 dukeleto purl, go play in traffic
04:39 * purl wanders off to dent some cars.
04:40 dukeleto kiwichris: let me know how to replicate the qemu+grub+rtems+parrot setup. I am excited to try it myself
04:40 kiwichris dukeleto, will do. I will clean up a little and try and get a patch then upload so you can try.
04:40 dukeleto kiwichris: also, if you need to make a public package of something, it would be great if you could use parrot 1.7.0
04:41 dukeleto kiwichris: but a patch against 1.6.0 is very useful to us as well
04:41 kiwichris dukeleto, does that mean using svn ?
04:41 dukeleto kiwichris: nope. just downloading the 1.7.0 tarball
04:41 dukeleto kiwichris: ftp://ftp.parrot.org/pub/pa​rrot/releases/devel/1.7.0/
04:42 kiwichris dukeleto, thanks
04:42 dukeleto kiwichris: it looks like our latest dev release link never got updated. that is my fault
04:42 dukeleto http://www.parrot.org/release/developer points to 1.6.0 still. that is wrong
04:42 kiwichris dukeleto, ah ok now I understand
04:46 dukeleto kiwichris: you can work off of 1.6.0 or 1.7.0, but if it is not too much trouble, 1.7.0 is the latest release
04:46 kiwichris dukeleto, I will work off 1.7.0. Will see if what I have can run. Battling grub again.
04:47 dukeleto kiwichris: it hopefully has less bugs and more features :)
04:47 dukeleto kiwichris: grub is a formidable devil
04:47 kiwichris dukeleto, it is nice when it is working ... just getting to that point .....
04:50 dukeleto kiwichris: indeed.
04:50 dalek partcl: ae412db | coke++ | t/cmd_expr.t:
04:50 dalek partcl: Add a test for this issue.
04:50 dalek partcl: review: http://github.com/partcl/partcl/commit/a​e412db3481158e1047b03b3194d633f1d4cd541
04:50 * dukeleto is running fulltest on linux with POW=pow
04:53 szabgab joined #parrot
04:53 kiwichris dukeleto, runs until the following error PackFile_set_header: Unsupported floattype NUMVAL_SIZE=4, PARROT_BIGENDIAN=little-endian
04:54 kiwichris dukeleto, must still have some problems in may hacking of the config
04:54 nopaste "dukeleto" at 69.64.235.54 pasted "nqp-rx depends on a non-release version of parrot" (11 lines) at http://nopaste.snit.ch/18528
04:54 dukeleto kiwichris: can you post the full error on http://nopaste.snit.ch ?
04:54 kiwichris dukeleto, That is it.
04:55 dukeleto kiwichris: there is an option there to post the link to the channel
04:56 ash__ joined #parrot
04:56 dukeleto Coke: fulltest passes on linux with POW=pow
04:57 nopaste "kiwichris" at 58.172.128.7 pasted "RTEMS parrot on i386 qemu fails" (2 lines) at http://nopaste.snit.ch/18529
05:01 dukeleto kiwichris: src/packfile.c
05:01 dukeleto 1305:    exit_fatal(1, "PackFile_set_header: Unsupported floattype NUMVAL_SIZE=%d,"
05:02 dukeleto kiwichris: are you playing around with PARROT_BIGENDIAN ?
05:02 dukeleto kiwichris: what is NUMVAL_SIZE ?
05:02 dukeleto kiwichris: oh, it is 4. duh
05:03 kiwichris dukeleto, Not BE but yes NUMVAL_SIZE
05:03 dukeleto kiwichris: we don't seems to have a branch for NUMVAL_SIZE=4
05:03 dukeleto s/seems/seem/
05:03 kiwichris dukeleto, what us NUMVAL_SIZE ?
05:03 kiwichris s/us/is/
05:05 dukeleto kiwichris: it is defined in include/parrot/config.h
05:05 dukeleto /* We don't have a portable config for 64-bit * registers yet. */
05:05 dukeleto that comment does not sit well with me
05:05 kiwichris dukeleto, but I am only 32bits. We do not support 64bit targets yet. It is happening but on the PC.
05:05 dukeleto are you defining NUMVAL_SIZE=4 somewhere? we set it to 8 and then it gets changed from under us, it looks like.
05:06 kiwichris dukeleto, The linux that did the configure is 64bits
05:06 dukeleto kiwichris: that could be an issue
05:06 dukeleto kiwichris: but I am not sure
05:07 kiwichris dukeleto, yeap I suspect so. I will dig around later for a 32bit Linux host and see what it reports.
05:07 kiwichris dukeleto, have to run and again many thanks for the help. It is close now
05:08 dukeleto kiwichris: awesome, thanks for the great work!
05:15 dalek parrot: r42217 | dukeleto++ | trunk/src/string/api.c:
05:15 dalek parrot: [cage] Use the math function pow() for now, until we get a configure-time check for powl(), which is an optional POSIX extension
05:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42217/
05:23 dalek TT #1177 created by dukeleto++: test buffer_size in t/pmc/parrotio.t
05:26 dukeleto does NCI currently support the 'long long' datatype?
05:26 dalek TT #1178 created by dukeleto++: Test get_fd in t/pmc/parrotio.t
05:29 dalek TT #1179 created by dukeleto++: Test open file, close file, delete file, reopen previously opened stream
05:30 dukeleto Ticket 46827: Permission Denied
05:30 dukeleto i can't seem to close some RT's
05:36 pmichaud Coke:  Yes, nqp-rx will make it much easier to implement the tcl re syntax
05:39 pmichaud msg Coke yes, nqp-rx will make it much easier to implement the tcl re syntax
05:39 purl Message for coke stored.
05:44 dukeleto pmichaud: ping!
05:44 Coke danke.
05:44 pmichaud dukeleto: pong
05:45 pmichaud Coke: writing a p5 syntax parser for nqp-rx is on my todo list
05:45 Coke dukeleto++
05:45 dukeleto pmichaud: so in general, you will attempt to make released versions of nqp-rx that are pegged to released versions of parrot?
05:45 pmichaud explicitly so that we can then create a real tcl-rx
05:45 pmichaud dukeleto: can't say for sure
05:45 Coke pmichaud: spif. danke.
05:45 dukeleto pmichaud: i am trying to work out how parrot should utilize nqp-rx
05:46 Coke dukeleto: those tickets are still open, btw.
05:46 pmichaud because nqp tends to target the _next_ parrot release (as opposed to the previous one), tying to the previous parrot release doesn't make a lot of sense
05:46 dukeleto pmichaud: also, how do you feel about HLL's that require nqp-rx as well as parrot?
05:47 dukeleto pmichaud: what if you released the week after the parrot release?
05:47 pmichaud dukeleto: I think that's going to be the norm.
05:47 dukeleto pmichaud: yep, because I am hacking on http://github.com/leto/kea and I am going to start with nqp-rx, no matter what :)
05:47 Coke dukeleto: do you have permission to reject tickets at RT?
05:48 dukeleto Coke: i just wanted to resolve it
05:48 dukeleto Coke: i guess not?
05:48 pmichaud so, either parrot bundles a version of nqp-rx, or all of the hll implementors end up requiring it on their own
05:48 Coke http://rt.perl.org/rt3/Tic​ket/Display.html?id=46827, e.g., is still open.
05:48 dukeleto pmichaud: yeah. which is the better solution?
05:48 Coke if you can't reject them, I can.
05:48 dukeleto Coke: i don't think I can reject them, please do if you can.
05:49 pmichaud personally I think it's better if parrot provides nqp-rx directly, rather than requiring everyone else to get it separately.
05:49 dukeleto Coke: there are about 20 RT tickets about creating tests in t/pmc/parrotio.t . perhaps they all need to be part of a "increase the coverage of parrotio.t to X %" ?
05:49 pmichaud but this is an important question for libraries in general
05:50 dukeleto pmichaud: the actual question that arises is "how often does parrot core pull in the latest nqp-rx?"
05:50 pmichaud do we expect parrot-with-batteries libraries to target the previously released version of parrot, or the version of parrot in which the libraries are about to be bundled?
05:50 pmichaud for example, let's suppose that I have a SQL library that parrot wants to bundle
05:50 dukeleto pmichaud: there is no doubt that nqp-rx will get in Parrot core. But how often will it be updated?
05:51 pmichaud does the Jun release of Parrot want to be bundling the SQL library that targets the May release?
05:51 pmichaud or, if we go with "supported releases"
05:51 dukeleto pmichaud: let us assume that there is a one-time dump of nqp-rx into Parrot core. What kind of update schedule should be after that?
05:51 chromatic That seems like a leading question.
05:52 pmichaud does the July release of Parrot want to be bundling the SQL library that is targeting the previous January's release of Parrot?
05:52 dukeleto pmichaud: I don't understand the motivation of the question.
05:52 pmichaud dukeleto: on #perl6 you said you were concerned that nqp-rx was not targeting a released version of Parrot
05:52 pmichaud er, that it depends on a non-released version of parrot
05:53 pmichaud the only alternative for NQP then would be to depend on the most recent version of Parrot
05:53 Coke dukeleto: they could probably all go to IOTaskList or something (wiki page instead of individual tickets)
05:53 pmichaud which isn't sufficient enough to support nqp's latest features
05:53 dukeleto Coke: yeah, managing all those tickets is kind of annoying. they are all about the same test file
05:54 pmichaud so, if nqp "held back" by only implementing those features that were possible with the Parrot october release
05:54 Coke dukeleto: there is prior art. feel free to put them into a wiki page.
05:54 dukeleto pmichaud: i think that in the short term, nqp-rx should depend on whatever it wants
05:54 Coke dukeleto++
05:54 pmichaud then in november, when Parrot creates a bundle, it would end up using the nqp that is limited to the prior Parrot release
05:54 Coke I'll make you a  bugmonger on RT. moment.
05:54 dukeleto pmichaud: i am just trying to understand how parrot should update nqp-rx
05:55 pmichaud anyway, to answer that question, I would expect parrot to draw from the nqp-rx repository shortly before a parrot release
05:55 dukeleto pmichaud: if there is going to be an nqp-rx "in the wild", parrot has to not conflict with other versions of nqp-rx that are installed that HLL's may be using/expecting
05:55 Coke dukeleto: or, I would have,if somone didn't delete the rt docs from docs/project...
05:55 dukeleto pmichaud: so you would be happy with parrot pulling from the nqp-rx repo each month?
05:55 Coke ah well. feel free to assign tickets that need to be deleted to me, I can close em out.
05:56 Coke (or bug someone here.)
05:56 pmichaud dukeleto: sure, why not?
05:56 dukeleto Coke: dealing with RT right now is an enigma wrapped in a word problem
05:56 dukeleto pmichaud: just verifying
05:56 pmichaud if it doesn't work out, we can go to a different policy
05:56 dukeleto pmichaud: this makes git submodules very attractive
05:56 pmichaud we just need to make sure that we're comfortable with the way it works by the January release
05:57 dukeleto pmichaud: i think a lot of testing of nqp-rx is about to start
05:57 pmichaud we can try including nqp-rx in the november and/or december releases, then remove it in january if it's not working out.  Or even just list it as "experimental" in the january release so that parrot isn't required to support it until July
05:57 pmichaud dukeleto: there's already been quite a bit of testing of nqp-rx in rakudo :)
05:57 dukeleto pmichaud: do you have any things that you need tests written for in the nqp-rx test suite?
05:57 pmichaud we've made amazing accomplishments in the past 72 hours
05:57 pmichaud we can always use more tests :)
05:57 dukeleto pmichaud: that is good. I want to make sure plumage still works, too :)
05:59 dukeleto so nqp-rx will be an external dependency that we sync up with monthly, so as to not give the end user another dependency nor the HLL developer the need to use a "newer" version of nqp-rx
05:59 dukeleto i think that could work
06:00 dukeleto i am all for putting nqp-rx into parrot 1.8.0, who is up for it? bernhard is release manager. where is he?
06:00 dukeleto msg bernhard hello!
06:00 purl Message for bernhard stored.
06:01 dukeleto seen bernhard
06:01 purl bernhard was last seen on #moose 18 days, 15 hours, 49 minutes and 19 seconds ago, saying:  I will probably also sign up for nanowrimo this year  [Oct 14 14:11:34 2009]
06:01 dukeleto hmm
06:01 pmichaud if it were me I wouldn't use git submodules.  not everyone has (or wants) git on their machine
06:02 pmichaud so if pulling the parrot repo requires git, that's probably a non-starter.
06:04 dukeleto pmichaud: are we talking about developer or end-users?
06:05 pmichaud either. both.
06:05 dukeleto pmichaud: because end-users would be using a tarball
06:05 pmichaud I'm primarily thinking developers.
06:05 dukeleto pmichaud: so what I am talking about, it when parrot switches to git. we would use nqp-rx as a git submodule
06:05 dukeleto s/it when/is when/
06:06 pmichaud "when parrot switches to git" isn't expected for quite some time, iiuc
06:06 pmichaud as in, not before 2.6
06:06 dukeleto pmichaud: i heard not before 2.0, where did you hear 2.6?
06:06 pmichaud in one of the discussions somewhere on irc or parrotsketch
06:06 chromatic There's no particular date on it, as I understand.
06:07 dukeleto pmichaud: the most that I got out of allison, is not before our production release, which is 2.0
06:07 pmichaud nor even a decision that "parrot is switching to git", iiuc
06:07 dukeleto pmichaud: parrot will switch to git. the only question is, when?
06:08 Coke relying on git submodules probably makes as much sense as external svn modules, neh?
06:08 Coke if we have an external dependency, just make it external.
06:08 Coke like our perl modules. or the HLL's reliance on parrot.
06:08 dukeleto pmichaud: i keep a mirror of parrot updated every 2 hours on github: http://github.com/leto/parrot . Parrot exists in git, we just need to choose a time to switch the canonical repo over
06:08 dukeleto Coke: yes.
06:09 pmichaud dukeleto: I've not heard anything that leads me to believe that a git switchover will occur anytime soon.
06:09 dukeleto pmichaud: I am pushing to switch to git at the earliest possible prudent moment.
06:09 dukeleto pmichaud: I am telling you about it. Right now. It will happen. I promise.
06:10 Coke dukeleto: ... ok. great. how does this help with nqp-rx?
06:11 dukeleto Coke: nqp-rx is in git. we want to use it as an svn-external, but wait. we can't. because it is in git.
06:12 Coke no, we /don't/ want to use it as an svn-external.
06:12 dukeleto Coke: we want to use it as an external that we can choose with revision/commit to peg to
06:12 Coke not especially, no.
06:12 dukeleto s/with/which/
06:13 dukeleto Coke: perhaps we are talking past each other. What are you trying to convey to me?
06:13 Coke there are ways to do this that don't require sync'ing up our version control systems.
06:13 Coke dukeleto: I thought I was pretty clear. Let's just make it a dependency in our toolchain. Or, we could bundle it with.
06:13 dukeleto Coke: what are these ways? I am talking about a process that is repeated on a time interval. Not a one time thing.
06:13 Coke we don't need to do any VCS magic to do either of those things.
06:13 pmichaud we're only talking about *four files*.  We don't need an external linkage to make it happen.
06:14 Coke (it's not like when we bundled icu. =-)
06:15 dukeleto Coke: what do you propose instead of VCS magic?
06:15 Coke dukeleto: ... copying the files in.
06:15 dukeleto Coke: someone manually copying 4 files every month?
06:15 Coke or, making an /external/ dependency.
06:15 Coke dukeleto: not every month.
06:15 dukeleto Coke: this wants to be synced every month
06:15 Coke why do you think we want to do it every month? it'd be "whenever something interesting happened in nqp"
06:15 Coke dukeleto: not necessarily, no.\
06:16 Coke it COULD be yes, not HAS to.
06:16 dukeleto Coke: or then HLL devs will start requires other versions of nqp-rx that are ahead of the ones in parrot
06:16 Coke depends on what goes in to nqp-rx.
06:16 Coke dukeleto: they're welcome to do that, of course.
06:16 dukeleto s/requires/requiring/
06:16 dukeleto Coke: yes, they are. but why not give them what they want in parrot core?
06:16 dukeleto Coke: do we really want to make it harder to use parrot?
06:16 Coke dukeleto: strawman. how do you know what they want?
06:16 Coke dukeleto: who the hell is suggesting that?
06:17 dukeleto Coke: because I am writing a HLL right now, and I want to use nqp-rx master
06:17 Coke I know you think I am, of course, it was a leading quesiton. =-)
06:17 Coke dukeleto: really? 'Cause I'd rather use "stable".
06:18 dukeleto Coke: what is "stable"? It depends on a non-released version of parrot!
06:18 pmichaud ...thus my comment earlier about libraries and bundling.
06:18 Coke dukeleto: as I understand it, a release of nqp-rx will not rely on any particular version.
06:18 Coke to build it, sure.
06:18 Coke to run it? that's not the impression I got.
06:18 pmichaud to run, yes, also.
06:19 pmichaud nqp-rx needs to have certain features from the PAST libraries in Parrot
06:19 pmichaud those weren't present in 1.7.0
06:19 dukeleto Coke: we then invoke dependency hell, having to deal with parrot-with-nqp-rx and nqp-rx-in-the-wild
06:21 Coke dukeleto: ok. so having it as an external dependency is problematic. Then we can keep it in core. that does not imply we need svn:externals or git submodules.
06:21 Coke s/it/a copy of it/
06:23 dukeleto Coke: so you are proposing manually copying 4 files every month, again?
06:23 Coke dukeleto: not every month!
06:23 Coke /when necessary/
06:23 Coke yes.
06:23 dukeleto Coke: at which frequency?
06:23 Coke dukeleto: as I said before, that depends on what is happening in nqp-rx.
06:23 pmichaud dukeleto: why does it need a set frequency?
06:23 dukeleto Coke: 'when necessary' doesn't compute for me. who would decide 'when necessary'?
06:24 Coke dukeleto: ... the developers of parrot?
06:24 Coke "oh, look, shiny. new thing."
06:24 dukeleto pmichaud: why do rakudo and parrot release monthly?
06:24 pmichaud dukeleto: why not "whenever a new version of nqp-rx is available that doesn't break too many things for parrot users" ?
06:24 Coke the same people who would decide when to update the revision pointed to in a submodule.
06:24 dukeleto pmichaud: that is not acceptable re: our deprecation policy
06:25 Coke dukeleto: ... and updating every month regardless of what's going on is? =-)
06:25 pmichaud dukeleto: rakudo and parrot release monthly because we like time-based releases.  That _doesn't_ mean that we only grab things from subprojects at monthly intervals
06:25 dukeleto Coke: but your plan has no definite time to take action. just "wait around" until it is "necessary" which is ambiguous
06:26 Coke dukeleto: ... kind of like our HLL developers already do with parrot?
06:26 pmichaud ambiguity is no problem
06:26 dukeleto pmichaud: we like time-based releases because they saved both projects from oblivion
06:26 Coke (except we'd be hiding this particular decision from them, so they didn't have to worry about it.)
06:26 pmichaud dukeleto: look, ubuntu does time-based releases, but they don't require their upstream modules to do the same
06:26 dukeleto pmichaud: rakudo and parrot are a bit different than ubuntu, but I appreciate your point.
06:27 Coke dukeleto: (time based) ... and parrot will still be doing time based releases; that's not changing.
06:27 pmichaud just because ubuntu includes a copy of perl 5 doesn't mean that they always include the latest copy of perl 5, or whatever version of perl 5 happens to be available at the time of the release
06:27 pmichaud the people who package the ubuntu release decide what versions of what components to include in that release
06:27 pmichaud the same would be true for parrot
06:27 dukeleto pmichaud: I agree with you that we don't need to grab updates for *all* subprojects monthly, but nqp-rx is a really really important subproject
06:28 pmichaud dukeleto: if nqp-rx is really really important, then there's little chance that it'll get forgotten or ignored or that someone will forget to update the files :)
06:28 dukeleto pmichaud: yes, I would like to believe that, what I want to create processes that withstand changes of guard, etc...
06:28 dukeleto pmichaud: everyone is excited to merge nqp-rx now. what about in a few years?
06:29 dukeleto s/what I want/but I want/
06:29 Coke dukeleto: what if nqp-rx breaks master and we're on time based includes?
06:29 pmichaud if people aren't merging nqprx in a few years, it'll be because one of (1) it's really stable, (2) nobody needs it any more
06:29 Coke you need someone to /decide/.
06:29 dukeleto Coke: I AM THE DECIDER
06:29 Coke we can make it trivial to copy in the new files.
06:30 Coke we can automate it more if we move to git, sure.
06:30 pmichaud nah, The Decider lives a few miles from here.  :)
06:30 Coke dukeleto: then I presume you will keep on top of merging nqp-rx for some time.
06:30 chromatic If it's external, people who want a newer version can use a newer version on their own.
06:30 pmichaud since Rakudo will be heavily dependent on nqp-rx, I'm certain that *I'll* be on top of it for some time.  :)
06:30 dukeleto How do we tell users of parrot which version of nqp-rx we are bundled with?
06:31 pmichaud nqp-rx is likely to have version numbers one way or another
06:31 dukeleto say it in parrot_nqp --version ?
06:31 dukeleto Coke: Ahem.
06:31 Coke dukeleto: ?
06:31 pmichaud right now I'm thinking of   "release.commit"
06:31 pmichaud so that  1.234  would be 234 commits after release 1
06:32 dukeleto chromatic: yes.
06:32 pmichaud (since git doesn't have sequential revision numbers like svn)
06:32 dukeleto pmichaud: directed acyclic graphs aren't linear :)
06:33 pmichaud they're linear in master
06:33 particle1 use tags
06:33 dukeleto particle: welcome to the party
06:33 Zak joined #parrot
06:33 Coke particle: you have RT tickets assigned to you. =-)
06:33 pmichaud I don't need a unique number for the whole repo... I just need a number for the master branch
06:33 particle hello, and goodnight
06:33 pmichaud particle: I could use a small bit of time to chat about S19 with you
06:34 pmichaud (not tonight, but sometime soon-ish)
06:34 dukeleto particle: you are always one to ruin the party ;)
06:34 particle ok, can do tomorrow
06:34 pmichaud great
06:34 pmichaud that would be perfect
06:34 particle ah, the enemy of the good...
06:34 particle bedward &
06:34 dukeleto pmichaud: a linear graph is an example of a DAG, but the entire history of a repo is not a linear graph
06:35 pmichaud dukeleto: I don't have to keep track of the entire history
06:35 dukeleto pmichaud: touche. git does it for you :)
06:35 pmichaud all I have to do is say "how many commits in the master branch since tag 'xyz'?"
06:35 Coke -> zzz
06:36 dukeleto pmichaud: that ain't a bad scheme.
06:36 pmichaud since that number will then be hardcoded in the four files that are produced upon making a release, it's unique-enough
06:37 pmichaud and it's consistently increasing
06:37 pmichaud perljam also suggested a date-based scheme, which I'm also considering.  Just record an ISO date and use that.
06:38 dukeleto pmichaud: the date-based version is longer, but gives more information. your call.
06:38 pmichaud well, I'm also waiting to see if there's a good concensus around including nqp-rx in parrot.  Because if that happens, one can identify nqp-rx by its parrot revision number :)
06:40 * dukeleto needs a drink
06:41 pmichaud on migration to git, last I heard was from the 09-29 parrotsketch meeting:
06:41 pmichaud 19:17
06:41 pmichaud
06:41 pmichaud Second q: On git, chromatic and I propose to table the migration discussion for now.
06:41 pmichaud
06:41 pmichaud 19:18
06:41 pmichaud Util
06:41 pmichaud +1
06:41 purl 1
06:41 pmichaud
06:41 pmichaud 19:18
06:41 pmichaud allison
06:41 pmichaud We can't migrate until after 2.0 or maybe even 3.0 for stability of development process anyway.
06:41 pmichaud oops, sorry for copy-paste spamo
06:42 dukeleto pmichaud: yes, I remember that. "2.0 or maybe 3.0"
06:42 dukeleto pmichaud: I shall get a definitive answer about which.
06:43 dukeleto pmichaud: I don't see any reason for waiting to 3.0 unless our aim is to actively reject new parrot developers
06:43 pmichaud dukeleto: I'm already on record as being very in favor of moving parrot to git.
06:43 * dukeleto goes in search of $food
06:44 dukeleto pmichaud: yes! duly noted ;)
06:50 dalek nqp-rx: 81afeca | pmichaud++ | src/Regex/P6Regex/Grammar.pm:
06:50 dalek nqp-rx: [p6regex]:  Argument value computed incorrectly -- fixed.
06:50 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/8​1afeca9af0069400e7106aae221194114c25c11
06:50 dalek nqp-rx: c65b0dd | pmichaud++ | src/Regex/P6Regex/ (2 files):
06:50 dalek nqp-rx: Refactor p6regex's handling of argument lists.
06:50 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/c​65b0ddda896e580b9bfb2115dff8e5118eb275f
06:50 dalek nqp-rx: 218e91c | pmichaud++ | src/stage0/ (3 files):
06:50 dalek nqp-rx: Stage 0 files update.
06:50 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/2​18e91cd180e82437f997c08e6c8203a3a4e05f4
06:50 dalek nqp-rx: 195e47c | pmichaud++ | src/NQP/Grammar.pm:
06:50 dalek nqp-rx: Allow <assertion(args)> to use NQP expressions as arguments.
06:50 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/1​95e47ce912c3b93783e8bff8e33134d4d90c402
06:50 dalek nqp-rx: a10d983 | pmichaud++ | src/stage0/ (3 files):
06:50 dalek nqp-rx: Update stage-0 files.
06:50 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/a​10d983b76cb6173d2dbf05b3663b98d92f65761
07:00 nopaste "kiwichris" at 58.172.128.7 pasted "RTEMS parrot runs, now what ?" (3 lines) at http://nopaste.snit.ch/18530
07:10 uniejo joined #parrot
07:12 Coke kiwichris: getting a make test run?
07:12 Coke must zzz.
07:20 kiwichris Coke, RTEMS does not have a make. It is all cross-compiled.
07:33 fperrad joined #parrot
07:56 baest joined #parrot
07:57 iblechbot joined #parrot
08:09 dalek TT #1180 created by moritz++: examples/nci/ls.pir prints only lines with one character each
08:37 gaz joined #parrot
08:48 Zak joined #parrot
09:03 cosimo joined #parrot
09:50 Austin_away joined #parrot
10:29 ask joined #parrot
10:46 mikehh joined #parrot
11:01 mikehh joined #parrot
11:15 mokurai1 left #parrot
11:18 mikehh joined #parrot
11:18 kj joined #parrot
11:21 rob joined #parrot
11:29 Andy joined #parrot
11:34 mikehh joined #parrot
11:47 mikehh joined #parrot
11:47 krunen joined #parrot
11:51 KatrinaTheLamia joined #parrot
11:57 mikehh joined #parrot
12:21 mikehh joined #parrot
12:47 whiteknight joined #parrot
12:48 kid51 joined #parrot
12:50 whiteknight good morning #parrot
12:50 kid51 good morning whiteknight
12:50 whiteknight hello kid51, how are you today?
12:51 kid51 good; soon to go to $job
12:51 payload joined #parrot
12:51 kid51 whiteknight:  At a high level, where do we stand with respect to areas like JIT?  GC?  Lorito?
12:52 whiteknight Lorito is basically the implementation path for JIT, so they are one and the same at the high level view
12:52 kid51 Is it plausible to expect this to be in by 2.0 (Jan 2010)?
12:53 whiteknight for both GC and JIT, we're still in planning/design stages, though we are building significant interest
12:53 masak joined #parrot
12:53 whiteknight I suspect we will have at least one in place for 2.0, yes
12:53 whiteknight depends how things go
12:54 Coke msg kiwichris (no make) - well, you could use the perl tool "prove", or just "perl t/harness" to get a first approximation.
12:54 purl Message for kiwichris stored.
12:54 kid51 Now a different question.  Background first.
12:54 Coke JIT for 2.0 ? I wouldn't say that's feasible at all.
12:55 kid51 I've been able to whip the configure and build tools into good shape by writing tests -- where which tests I write are guided by coverage analysis.
12:55 kid51 Since I've been working my way thru the PIR book, I'm starting to get a little facility for writing tests in PIR.
12:55 Coke cover?
12:55 purl cover is not at link?
12:55 kid51 Assuming I get time to become fluent in PIR, how would I use the coverage analysis on Parrot to guide which tests I write.
12:56 Coke coverage?
12:56 purl well, coverage is http://cv.perl6.cz
12:57 Coke e.g. http://tapir2.ro.vutbr.cz/cover/cover-re​sults/42216/c_cover/src-ops-bit-ops.html
12:57 Coke (which has 0 coverage which is questionable)
12:58 Coke perhaps addressing why that has 0 first, but I think that's the best avenue.
12:58 kid51 But what I'm getting at is the "mapping" between test files and source code files.
12:58 kid51 To clarify:
12:58 Coke kid51: there isn't a direct mapping.
12:59 kid51 If I write more tests for t/steps/auto/arch-01.t, I know to expect improvements in coverage for config/auto/arch.pm.
12:59 kid51 And those coverage results guide the next tests I write.
13:00 kid51 Is it possible to establish such a feedback loop for the C, PIR, ops components?
13:00 plobsing joined #parrot
13:00 whiteknight kid51: I'm not sure of any good way, no
13:01 whiteknight what I do, on the few occasions I write these kinds of tests, is to try to trace uncovered functions back to the opcodes that call them
13:01 whiteknight not always an easy task
13:02 payload joined #parrot
13:05 Coke part of the problem with that mapping is that you don't really use the opcodes in isolation.
13:06 Coke but, as far as feedback loops: get the coverage of .ops files in that URL to reflect reality, then drive them up.
13:06 Coke even if it's not a 1:N correspondence between file/opcode, that's still moving things in the right direction.
13:06 Coke (also PMCS, since you can see those from PIR and invoke them.)
13:07 Coke e.g.:
13:07 Coke http://tapir2.ro.vutbr.cz/cover/cover-resul​ts/42216/c_cover/src-pmc-coroutine-pmc.html - line 223
13:08 Coke that references a trac ticket, but is never invoked. perhaps the trac ticket has some sample PIR that caused the original segfault that we could include as a regression test.
13:09 Coke http://tapir2.ro.vutbr.cz/cover/cover-resul​ts/42216/c_cover/src-pmc-multisub-pmc.html is a slightly easier example; there are overrides to certain vtables which should throw exceptions that are never tested. that's a pretty straightforward test.
13:11 rob left #parrot
13:11 Coke mdiep++ # deleting old parrot version
13:11 Coke ( from cpan)
13:23 Andy joined #parrot
13:35 payload joined #parrot
13:53 riffraff joined #parrot
13:57 Andy joined #parrot
14:00 dalek parrot: r42218 | coke++ | trunk/t/pmc/parrotio.t:
14:00 dalek parrot: remove reference to rejected ticket.
14:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42218/
14:03 Andy joined #parrot
14:04 Coke RT: 120
14:04 Coke surely someone could copy over 5 tickets. =-)
14:22 ash_ joined #parrot
14:25 Coke coverage?
14:25 purl coverage is http://cv.perl6.cz
14:31 dalek TT #1181 created by coke++: make cover doesn't show coverage of *.ops files.
14:44 bubaflub joined #parrot
14:58 iblechbot joined #parrot
15:05 Coke RT?
15:05 purl rumour has it RT is just RT (http://bestpractical.com/rt) or (:rt3) or (: rt bugs) or Obra's trouble ticketing system or the first IBM RISC workstation (http://www.contrib.andrew.c​mu.edu/~shadow/ibmrt.html) or the bombsquad or the Right Thing or very very capable and open-source or an application framework that bundles a ticketing system or obra's baby or SOOOO slow :-S or email mailto:perlbug-owner@perl.org for access
15:05 Coke parrot RT?
15:05 purl parrot RT is probably http://rt.perl.org or http://rt.perl.org/rt3/Public​/Bug/Display.html?id=$bugnum
15:06 Andy joined #parrot
15:25 masak re https://trac.parrot.org/parrot/ticket/1134 -- I cannot reproduce the problem anymore. maybe somebody++'s work on some Parrot guts solved or hid the problem.
15:27 masak do I close the ticket?
15:28 Coke if the OP cannot duplicate the segfault, that seems reasonable.
15:30 Psyche^ joined #parrot
15:30 masak oki.
15:31 masak hm. I don't seem to have the privs to close it.
15:32 Coke just comment on it, the magic ticket fairy will close it.
15:32 masak :)
15:33 ash_ left #parrot
15:35 dalek TT #1134 closed by coke++: Extremely weird stack trace produced my Parrot when allocating things in a ...
15:44 whiteknight good 'ol magic ticket fairy
15:51 Coke if only he'd clean up RT for me.
15:51 Coke dukeleto++
15:51 Coke kid51++
15:52 Essobi heh
15:52 Essobi left #parrot
15:56 dalek parrot: r42219 | coke++ | trunk/runtime/parrot/library/Getopt/Obj.pir:
15:56 dalek parrot: remove comment referencing rejected ticket.
15:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42219/
16:03 dalek parrot: r42220 | coke++ | trunk/src/oo.c:
16:03 dalek parrot: remove comment for rejected ticket.
16:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42220/
16:06 dalek parrot: r42221 | coke++ | trunk/compilers/imcc/cfg.c:
16:06 dalek parrot: remove comment for rejected ticket.
16:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42221/
16:13 * Coke does the equivalent of tr/// to find out how many /'s there are in CFMX.
16:13 * Coke feels a little wrong.
16:25 dalek lua: a8170ec | fperrad++ |  (2 files):
16:25 dalek lua: start to implement debug.getinfo()
16:25 dalek lua: review: http://github.com/fperrad/lua/commit/a8​170eca437d95d483d86c8fc96d1d3d78ae48d8
16:33 dalek parrot: r42222 | pmichaud++ | trunk (2 files):
16:33 dalek parrot: Fix MultiSub PMCs so that they stringify to the name
16:33 dalek parrot: of their first candidate instead of the number of candidates.
16:33 dalek parrot: Also change the "No applicable methods" exception to be
16:33 dalek parrot: much more informative, by reporting "No applicable candidates
16:33 dalek parrot: found to dispatch to for '$subname'."
16:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42222/
16:34 bubaflub hey ya'll, can parrot be a target language for SWIG bindings?
16:34 bubaflub maybe that's a bad question
16:34 cotto_work good morning
16:35 brooksbp joined #parrot
16:38 whiteknight good morning
16:38 whiteknight bubaflub: I don't know a lot about SWIG bindings. what are the requirements?
16:39 bubaflub the idea is that i could write some SWIG interfaces to a C module
16:39 bubaflub and it'll output code in a bunch of different languages for native interface
16:39 Coke swig?
16:39 purl hmmm... swig is a competitor to XS. or simplified wrapper and interface generator/bifrost.lanl.gov/~dmb/SWI​G/Doc1.1/Perl5.html///www.swig.org/ or at http://bifrost.lanl.gov/~d​mb/SWIG/Doc1.1/Perl5.html or simplified wrapper and interface generator or at http://www.swig.org/
16:39 Coke swig tutorial is http://www.swig.org/tutorial.html
16:39 bubaflub java, python, perl 5 modules, etc.
16:40 bubaflub wow, that said it better than i could have
16:40 Coke so, it should be possible to generate the appropriate parrot code there.
16:41 moritz it would "just" be another NCI compiler, no?
16:41 Coke it wouldn't be the preferred method of getting to C, that'd be NCI. "what moritz said"
16:41 Coke but it should be possible to add us as a swig target, if someone has already written the swig template.
16:43 frodwith joined #parrot
16:43 * Coke wonders if a swig on parrot POC would be helpful.
16:43 bubaflub ah, cool.  just wondering.
16:43 bubaflub i thought it may be helpful getting some modules available to parrot
16:43 bubaflub as there may be some stuff already out there
16:57 PerlJam joined #parrot
16:59 japhb fperrad, ping
17:00 theory joined #parrot
17:01 Coke japhb: if you could close|migrate RT# 56628, that'd be awesome.
17:02 japhb Coke, I may have lost my access info to RT, lemme see
17:02 * japhb is WAY backlogged today
17:04 dukeleto 'ello
17:05 dukeleto bubaflub: i was talking to a SWIG guy about just that at the gsoc conf
17:05 bubaflub dukeleto: no way.
17:05 bubaflub i saw you had some work on Math::GMP::SWIG
17:06 dukeleto bubaflub: since swig already talks XS, if it also spoke PIR/PASM, we would have a bridge between them
17:06 japhb Coke:  OK, I think I'm going to just doc that ticket out of existence.
17:07 dukeleto bubaflub: we need the docs for how to add a new target langauge (PIR/PASM) to swig
17:07 bubaflub hmmmm
17:07 japhb Woah, couple few Parrot updates since Saturday
17:07 bubaflub i'll root around
17:07 dukeleto bubaflub: your mission, should you choose to accept it ...
17:07 Coke japhb: that would be awesome.
17:07 bubaflub haha.  i haven't bisect'd to see where make -j fails yet, but finding docs should be easy
17:07 dukeleto bubaflub: you should really add dies_ok() and those other tests that use lives_ok() and dies_ok(), first. That is a lot less work :)
17:08 dukeleto bubaflub: i am pretty sure the pcc_reapply merge broke make -j, don't worry about bisecting that
17:08 bubaflub ok
17:10 Coke I think make -j is working fine now.
17:10 dukeleto Coke: you are dead sure of this? it was broke for a while
17:10 dukeleto Coke: and it was broke for me about 2 days ago, still
17:11 Coke I've been having no trouble with it. YMMV.
17:11 * Coke investigates.
17:12 * Coke tries a -j 20
17:13 bubaflub i think the problem may be after a make realclean
17:13 bubaflub i just ran -j 4 no problem, but only a few files needed to be re-made
17:15 Coke dukeleto: works fine here.
17:15 Coke if you find a problem, open a ticket with the build log, easy enough to fix.
17:16 dukeleto Coke: are you doing make realclean; perl Configure.pl; make -j 4 ?
17:16 dukeleto Coke: it only fails after a realclean
17:17 nopaste "coke" at 72.228.52.192 pasted "how I build parrot all the time." (7 lines) at http://nopaste.snit.ch/18533
17:17 * moritz now tries on 4 cores with -j (no limit)
17:17 dukeleto Coke: that is similar to what I have. And -j was broke for a while. Perhaps someone fixed it in the last few days
17:18 Coke Some deps were added in the past week. More I cannot say.
17:18 Coke I squawk loudly if I get bit by that, as I had to spend time fixing it the first time.
17:18 moritz wow, that works
17:18 dalek rakudo: 74f561e | moritz++ | src/setting/Complex.pm:
17:18 dalek rakudo: call .perl on $.re and $.im in Complex.perl
17:18 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​4f561eb77cfe4d7384c1a82ab484d7b63ba8073
17:18 Coke moritz: what works?
17:18 moritz Coke: building with -j after realclean
17:18 Coke moritz: why wouldn't it?
17:18 Coke oh, because of aforementioned bug?
17:18 moritz eys
17:19 moritz *yes
17:19 moritz or because of resource limits :-)
17:19 Coke I remember the dark times, when Configure.pl said, "dont' use -j"
17:19 Coke stupid dark times.
17:19 dukeleto Coke: you must not have noticed, because it was broke since the pcc_reapply merge until recently
17:19 moritz dukeleto: no
17:19 moritz it was fixed pretty soon after the merge
17:19 moritz maybe it broke again, and was fixed again
17:20 dukeleto bubaflub: wasn't it broke for you, just a few days ago?
17:20 moritz iirc
17:20 dukeleto moritz: sinusoidal bugs!
17:20 Coke in any case, if it's failing, open a ticket.
17:20 moritz real    0m1.255s for make -j
17:20 dukeleto Coke: tickets welcome! check.
17:20 moritz and user    0m3.544s
17:21 Coke moritz: is that after a realclean? what is that, a 64-core machine?
17:21 bubaflub dukeleto: it was.  i can run it again on my machine from trunk
17:22 moritz Coke: after a realclean and Configure.pl, 4 cores
17:22 dukeleto bubaflub: sure, make sure it works for you, and if it doesn't, open a ticket and assign it to coke++ ;)
17:22 Coke aha. found a bug. -j20 worked, -j failed. checking...
17:22 dalek parrot: r42223 | japhb++ | trunk/config/auto/opengl.pm:
17:22 dalek parrot: [OpenGL] Document Cygwin native v. X conflicts to resolve RT 56628
17:22 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42223/
17:22 bubaflub bahaha.  roger wilco
17:22 dukeleto Coke: THE HORRORS
17:22 Coke (finding bugs is a crapshoot with -j)
17:23 Coke "make clean;make src/oo.o"
17:24 whiteknight Coke: that causes a problem?
17:26 japhb Coke, RT #56628 now resolved.  Is that the only RT that was assigned to me?
17:27 Coke whiteknight: yes. it depends on .h files that don't exist.
17:27 whiteknight oh, hotness
17:27 Coke not to mention the .str file.
17:27 Coke fixed.
17:27 Coke dukeleto: let me know if you can find another failure.
17:28 Coke (if folks are bored, trying to do a 'make clean; make <object file>' is a boring but effective way to find these issues.
17:28 Coke (did I mention boring?)
17:28 bubaflub ooooh i'm bored!
17:29 bubaflub actually, i'm at work, working on parrot
17:29 bubaflub which is a great way to get paid to work on parrot
17:29 bubaflub also a great way to get fired
17:29 dalek parrot: r42224 | coke++ | trunk/config/gen/makefiles/root.in:
17:29 Coke I think ideally we'd want a 'make depend' target that detected these things and made sure they were in the makefile.
17:29 dalek parrot: Fix dependencies for src/oo.c
17:29 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42224/
17:29 Coke japhb: if you close the ticket, be sure to cc the list.
17:29 dukeleto Coke: we could write a test for that
17:30 dukeleto Coke: the "make-sure-nobody-broke-make-j" test.
17:30 Coke dukeleto: i started to. the payoff for the work involved wasn't enough for me.
17:30 dukeleto Coke: the test that gets you tarred and feathered if you break it on trunk
17:30 Coke some things are just easier to fix after the fact.
17:30 Coke (but yes, if it magically appeared, that'd be nice. =-)
17:32 Patterner joined #parrot
17:33 Coke japhb++ # closing tickets.
17:34 Coke (note, that's plural! do another to earn that karma!)
17:35 japhb Coke, I'm actively trying to right now.  :-)
17:35 japhb Coke, did you do the CC, or should I go back and do so?
17:36 dalek tracwiki: v114 | jkeenan++ | WikiStart
17:36 dalek tracwiki: https://trac.parrot.org/parrot/wiki/W​ikiStart?version=114&amp;action=diff
17:36 Coke I didn't. I've been checking at the end of the day for closed tickets to do that; if you do it now, +1.
17:36 japhb Coke, is there some link or button that does that, or do I now need to copy & paste?
17:39 Coke Just reply to your comment.
17:40 Coke with a note "cc'ing final response to list" or some such.
17:42 japhb Coke, done
17:42 Coke japhb++
17:45 whiteknight kid51: ping
17:46 Coke whiteknight: he's at work all day.
17:47 solarion joined #parrot
17:47 whiteknight purl msg kid51 could you take a look at RT #37934 (again)? My initial inclination is to reject it for now, but if you think it's reasonable to do I won't just close it
17:47 purl Message for kid51 stored.
17:48 Coke whiteknight: I wouldn't reject that.
17:48 Coke having a config.log to post for tickets would be nice.
17:49 whiteknight it would be nice, but if nobody's going to actually implement it, and if it's just some "would be nice" pipedream, then it's just taking up space
17:50 whiteknight that's why I'm asking kid51: If anybody is actually interested in implementing it, good.
17:50 Coke just like JIT?
17:50 Coke nice to have, but...
17:51 Coke (yes, that's not exactly a 1:1 mapping)
17:51 Coke but "no one is interested in writing it now" is not a valid reason to delete a ticket.
17:53 brooksbp joined #parrot
17:54 whiteknight Coke: RT #40438, you're doing this right now in partcl, right?
17:54 whiteknight (adding PIR methods to a dynpmc)
17:57 dalek parrot-plumage: 07852ee | japhb++ | :
17:57 dalek parrot-plumage: [CORE] Util.nqp: Apply modified patch from fperrad++ implementing PATHEX...
17:57 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/07852ee4a40a30fdbdf7ab9eb4ab7f4e04c9d93e
17:58 japhb What's the current status of NCI thunk building?
17:59 japhb I've got a new ticket and an old one that both want 'long long' or 'unsigned long long' support.
18:01 whiteknight japhb: no support just yet
18:02 Coke whiteknight: yes, I'm doing that now.
18:02 chromatic joined #parrot
18:02 Coke having a test in core would be spif.
18:02 Coke (but that can go on some sort of "testing tasks" page.)
18:02 japhb whiteknight, darn.
18:03 dalek parrot: r42225 | whiteknight++ | trunk/src/pmc/default.pmc:
18:03 dalek parrot: [pmc] remove some unneeded code that's been commented out for a while. Resolves RT 46659
18:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42225/
18:04 japhb Coke, RT 53406 can be moved to Trac.  I'm not sure what your process there is.
18:13 dalek parrot: r42226 | japhb++ | trunk/config/gen/opengl.pm:
18:13 dalek parrot: [OpenGL] Applied patch from fperrad++ to fix TT #1167
18:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42226/
18:14 Coke japhb: http://lists.parrot.org/pipermail/p​arrot-dev/2009-November/003154.html
18:15 dalek TT #1167 closed by japhb++: some new types not handled by gen::opengl step
18:20 japhb What is the proper TT 'Component' for NCI stuff?
18:20 dalek parrot: r42227 | pmichaud++ | trunk (2 files):
18:20 dalek parrot: [p6object]:  Add .WHO and .WHERE methods, with tests.
18:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42227/
18:20 Coke japhb: when in doubt, other.
18:21 japhb There's no 'other' in the list
18:21 Coke checking...
18:22 Coke none is the new other.
18:22 japhb Coke: OK, thanks
18:24 japhb OK, RT #53406 -> TT#1182
18:25 dalek TT #1182 created by japhb++: [TODO] Add 'long long' to types supported by NCI
18:26 brooksbp joined #parrot
18:27 Coke japhb++
18:27 darbelo joined #parrot
18:31 darbelo Ohhh. Eventful weekend.
18:33 darbelo Leave you guys alone for a bit, and I get a broken make -j and test failures.
18:33 dalek nqp-rx: e478a58 | pmichaud++ | build/PARROT_REVISION:
18:33 dalek nqp-rx: Bump PARROT_REVISION so we get P6object .WHO and .WHERE.
18:33 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/e​478a58b330c2f75a9d35d2a209eb58a3376256e
18:34 Coke darbelo: is it broken for you now? you have a build failure log for me?
18:34 darbelo Coke: Better! I have a fix. I think.
18:34 Coke darbelo: ok. (I just fixed one of these moments ago.)
18:36 darbelo I just added pmc/pmc_context.h to the deps for scheduler.$(O) and it's building fine.
18:36 Coke darbelo++
18:37 darbelo I'll try with higher -j values before committing
18:37 Coke is scheduler a src file?
18:38 Coke (or a pmc?)
18:38 Coke (just do make clean; make path/to/scheduler.o) to test.
18:40 Coke (I suppose make -j path/to/scheduler.o is better.)
18:45 dalek parrot-linear-algebra: 1a03b3b | Whiteknight++ | src/pmc/nummatrix2d.pmc:
18:45 dalek parrot-linear-algebra: add a method to initialize a 2D matrix from a linear array. Will be very useful for HLLs that need to instantiate array constants
18:45 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/1a03b3b750afe17d2f71b47b9b0198f711a4d856
18:47 darbelo Coke: That doesn't find problems in other files :)
18:49 chromatic A short Perl program could look at the #include files in our .c files and compare them to the Makefile dependencies.
18:49 allison joined #parrot
18:51 darbelo Okay, it survived a -dp run, commit is on the way.
18:54 dalek parrot: r42228 | darbelo++ | trunk/config/gen/makefiles/root.in:
18:54 dalek parrot: Adjust the dependencies of $(SRC_DIR)/scheduler$(O) in order to fix BSD make parallel builds.
18:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42228/
18:55 * Coke is bit by a svn bug from 1.x
18:55 Coke (non parrot repo)
18:55 brooksbp joined #parrot
18:56 mikehh joined #parrot
19:03 dalek TT #1183 created by bubaflub++: dies_ok() for Test::More
19:07 cotto_work chromatic, Andy was working on something like that at some point.
19:09 chromatic I thought he was using a special make flag.
19:10 dalek TT #1184 created by bubaflub++: [PATCH] fix trailing white space on src/pmc/multisub.pmc
19:11 cotto_work iirc he started out playing with makedep but decided to roll his own after running into some limits that wouldn't work well with parrot.
19:11 cotto_work I would like to see that class of errors eliminated.
19:13 darbelo And, while we're asking for poinies, we should eliminate the sub-makefiles.
19:14 mikehh joined #parrot
19:15 Coke darbelo: you can have #1184. =-)
19:15 darbelo Trac?
19:15 purl rumour has it Trac is a web-based software project management and bug/issue tracking system emphasizing ease of use and low ceremony. It provides an interface to the Subversion revision control systems, integrated Wiki and convenient report facilities.  http://projects.edgewall.com/trac/ or Python, SQLite and ClearSilver or killing killtrac or a bug-tracking tool or at https://trac.parrot.org/parrot/ or slow or REALLY slow
19:15 cotto_work Andy, whatever happened with that project?
19:15 cotto_work seen andy
19:15 purl andy was last seen on #parrot 3 days, 5 hours, 13 minutes and 46 seconds ago, saying: howdy  [Oct 30 14:01:39 2009]
19:15 Andy which
19:15 cotto_work the makedep replacement for parrot
19:15 Coke darbelo: yes
19:15 Andy oh, heck
19:15 Andy I don't even remember
19:16 darbelo fix trailing white space on src/pmc/multisub.pmc?
19:16 cotto_work darbelo, do you think you're up for it?
19:17 darbelo I son't know, cotto_work, it sounds like it needs skills I don't have.
19:18 cotto_work There's deep magic in that whitespace.
19:18 Coke cotto_work: you own RT #36407 and RT#48439, btw.
19:18 * cotto_work looks
19:18 Coke please to be the transferance.
19:19 cotto_work please to the English yes?
19:19 dukeleto darbelo: wanna apply https://trac.parrot.org/parrot/ticket/1184 ?
19:19 Coke dukeleto: welcome to 4 minutes ago. =-)
19:19 darbelo dukeleto: doin' it now.
19:19 Coke cotto_work: translationparty says "Please forward full ticket."
19:20 dukeleto yay, fulltest rejoices
19:20 dukeleto that will be two accepted patches for bubaflub++, so he can ask for a commit bit then, right?
19:21 dalek parrot-linear-algebra: a33c53a | Whiteknight++ | README:
19:21 dalek parrot-linear-algebra: Updated README with current status and information that I now know
19:21 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/a33c53a33d767e36de6a578673cf3ba2f03c07c1
19:21 darbelo dukeleto: I have no idea. I was forced to get a bit ;)
19:24 darbelo dalek, you up?
19:24 Coke msg jonathan http://rt.perl.org/rt3/Tic​ket/Display.html?id=46687 seems to be yours. If you could move it over to trac or reject it, that would be spif.
19:24 purl Message for jonathan stored.
19:24 dukeleto darbelo: dalek hates me
19:24 Coke msg jonathan (or resolve it, even!)
19:24 purl Message for jonathan stored.
19:24 Coke darbelo: he takes his time. no worries.
19:24 dalek parrot: r42229 | darbelo++ | trunk/src/pmc/multisub.pmc:
19:24 dalek parrot: Fix trailing white space on src/pmc/multisub.pmc
19:24 dalek parrot: Patch by bubaflub++
19:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42229/
19:27 dalek TT #1184 closed by darbelo++: [PATCH] fix trailing white space on src/pmc/multisub.pmc
19:27 darbelo dukeleto: did your make -j problems clear up after r42228 ?
19:29 * Coke finds pmichaud's "live demo" kitten. :(
19:29 dukeleto darbelo: not sure. i think the bug has come and gone. i will check in a few on the latest trunk
19:30 pmichaud Coke: =-)
19:30 dukeleto darbelo: i meant to say, the bug has been fixed and reappeared, a few times, even
19:30 pmichaud that always gets a huuuuuge laugh when I pull it up.   It also eats up valuable lightning talk time.
19:37 mikehh joined #parrot
19:42 pmichaud okay, I've decided I really want the 'vivify' opcode -- not so much for PAST immediately, but just because it will simplify my other code a great deal
19:42 pmichaud (my hand-written PIR, that is)
19:43 chromatic Show me an example and you'll get it.
19:44 joeri joined #parrot
19:50 Coke pmichaud: http://www.wall.org/~lewis/ huh.
19:50 Coke (mentions rakudo)
19:51 dalek TT #1185 created by bubaflub++: [PATCH] attempted to rewrite t/op/00ff-dos.t in PIR
19:52 pmichaud chromatic: I'll write it very quickly based on what you have for fetch.  I'm also going to refactor fetch.  I'll send you a patch for review
19:52 darbelo dukeleto: The problem is that when we shuffle code arround the repo, we should shuffle deps acordingly.
19:52 mikehh joined #parrot
19:53 dukeleto darbelo: yes. Can we make sure to shuffle deps properly from now on?
19:54 darbelo That step is easy to miss if it works for the guy shufflig the code.
19:54 chromatic That means paying more attention to #include lines and such in commit mails.
19:54 Coke chromatic: I try to key off those.
19:54 Coke (hard on big mergebacks)
19:55 dukeleto darbelo: people who shuffle deps should make sure that "make realclean; perl Configure.pl && make -j 2" works
19:55 darbelo They should also keep the codingstd test passing.
19:55 dukeleto also, every branch should allow "make -j" before being merged
19:55 dukeleto darbelo: all commits to trunk should pass "make fulltest"
19:57 darbelo dukeleto: Don't hold your beath.
19:57 dalek parrot-linear-algebra: c42f643 | Whiteknight++ | src/pmc/nummatrix2d.pmc:
19:57 dalek parrot-linear-algebra: add comments to NumMatrix2D METHODs, and add a quick sanity check to the initialization method
19:57 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/c42f6432ab4c0339ca20186f828cf76a3a491a60
19:57 dalek parrot-linear-algebra: bbb9d00 | Whiteknight++ | src/pmc/nummatrix2d.pmc:
19:57 dalek parrot-linear-algebra: add methods to get and set blocks. This will help in partitioning algorithms and, eventually, autothreading
19:57 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/bbb9d0094762e386bd5019443a822d7c9ad93b6e
19:58 dalek TT #1186 created by bubaflub++: [PATCH] convert t/op/00ff-unix.t to PIR
19:58 whiteknight bubaflub++
19:59 darbelo Hmm. What *is* the policy to get a commit bit?
19:59 dukeleto darbelo: submit 2 patches, then get recommended by 2 parrot devs
19:59 whiteknight you get nominated, at #ps we vot
20:00 dukeleto then you submit the CLA and then you get a bit
20:00 whiteknight right, CLA
20:00 chromatic Two contributions is for PaFo *membership*.
20:00 chromatic Commit bit policy is submit enough good patches that someone is sick of committing them for you.
20:00 darbelo Hmm. I wonder if giving plobsing one would speed up the libjit work.
20:01 dukeleto darbelo: the JIT work or the libjit work?
20:01 moritz it would simplify things
20:01 dukeleto are we still planning on supporting libjit and llvm? Because I need to tell you all, that is a really bad idea.
20:02 whiteknight dukeleto: I'm not convinced of the doom and gloom
20:02 whiteknight I certainly see no problem supporting two frame builders
20:02 darbelo dukeleto: Really? Sounds like what a llvm dev would say :)
20:02 Coke whiteknight: split resource allocation.
20:02 dukeleto whiteknight: what is the difference between 2 frame builders and supporting 2 JIT backends?
20:02 chromatic Writing a *good* JIT backend is a lot of work.
20:03 Coke increases complexity and support costs.
20:03 chromatic Writing a decent framebuilder is not.
20:03 whiteknight Coke: I don't think so, split resource allocation means there are people who would work on both
20:03 Coke whiteknight: if someone hands us one of each, sure.
20:03 Coke if we are trying to come up with a plan for limited resources, that's where my concern comes in.
20:03 whiteknight I, for instance, will probably only work on the LLVM version
20:03 dukeleto We are going to throw away this JIT rewrite. And the next one. Let's iterate towards a good JIT, instead of spreading ourselves too thin.
20:03 whiteknight but if there's another developer who is only interested in working on libjit, that's their prerogative
20:04 Coke whiteknight: sure. but we shouldn't be advocating that.
20:04 dukeleto Every open source project that I talked to said that you start JIT from the ground up a few times. Which means supporting multiple backends in the beginning is just added drag.
20:04 whiteknight you guys with the worrying! We already have a concrete plan spelled out
20:04 whiteknight we're doing LLVM first
20:04 whiteknight that's the plan
20:04 whiteknight we do LLVM first
20:04 dukeleto whiteknight: I like that plan!
20:04 whiteknight then memorize it!
20:05 whiteknight and don't worry about other things!
20:05 dukeleto jit?
20:05 purl jit is a Just In Time compiler.  Or just more Java hype. or new Parrot hype! or a less than ideal example of clean code X-)
20:05 Coke dukeleto: now we just need to make sure we stop after that point. =-)
20:05 darbelo dukeleto: llvm only leaves platforms out.
20:05 dukeleto darbelo: which platforms?
20:05 purl which platforms are 8.3 an issue on, anyway?
20:05 darbelo OpenBSD, all arches.
20:05 whiteknight there are motivations for LLVM to expand to more platforms
20:06 whiteknight we can help push that
20:06 dukeleto whiteknight: does https://trac.parrot.org/parrot/wiki/JITRewrite say that we are doing LLVM first? I don't see that spelled out.
20:06 dukeleto darbelo: so llvm does not support OpenBSD. Good to know. Anything else?
20:06 whiteknight dukeleto: allison made the announcement on the list
20:06 whiteknight (I should spell it out on the wiki though, that's true)
20:06 dukeleto whiteknight: you expect me to read my email? ;)
20:07 whiteknight I read email, and I don't read the wiki
20:07 whiteknight :)
20:09 dukeleto I hate email.
20:09 whiteknight you and me both. But I get far too much of it to just ignore it all
20:10 mikehh joined #parrot
20:10 darbelo dukeleto: I know FreeBSD and Dragonfly are working to make LLVM the system compiler, which covers a good percentage fo the BSD landscape. I have no idea about NetBSD, and last I heard the llvm jit wasn't working on solaris.
20:10 dukeleto darbelo: what is this? http://openports.se/devel/llvm
20:11 dukeleto darbelo: the current supported platforms for parrot are linux,windows,os x and solaris, correct? so we need jit to work on those.
20:11 darbelo dukeleto: Not entirely functional ;)
20:12 nopaste "pmichaud" at 72.181.176.220 pasted "vivify opcode patch (for review by chromatic)" (87 lines) at http://nopaste.snit.ch/18535
20:12 chromatic How is that different from existing, pmichaud?
20:13 pmichaud +        VTABLE_set_pmc_keyed(interp, $2, $3, $1);
20:13 pmichaud on each case
20:13 whiteknight pmichaud: what does the :base_core flag do?
20:13 dukeleto whiteknight: all your base core are belong to parrot
20:13 chromatic Oh, I thought that was fetch, for some reason.
20:14 pmichaud whiteknight: I think it indicates it's statically linked and not a dynop, but I don't know.  I just copied whatever chromatic++ had for the basic opcode structure
20:14 whiteknight gotcha
20:14 pmichaud vivify looks a lot like fetch, it just has the extra bind at the end
20:14 whiteknight do we need fetch and vivify?
20:14 pmichaud I do
20:14 whiteknight okay
20:14 whiteknight (just making sure)
20:14 pmichaud I have a case where I'm writing code and it turns 14 lines of PIR into 2
20:15 chromatic I really want to extract out all of that same code, but I'm not sure of the best way to do so.
20:15 pmichaud yeah, I was working on that also, but couldn't find a way to do it.  The exception is the kicker.
20:15 darbelo dukeleto: If supported platforms are measured by active developers you can take windows off that list.
20:16 moritz hey, don't forget jonathan ;-)
20:16 dukeleto darbelo: yeah, I learned that when our tests were broke in trunk on windows for a few days leading up until 1.7.0 :)
20:17 darbelo OpenBSD, a non supported platform, spends less time broken that windows.
20:17 dukeleto darbelo: we should blame particle for more stuff, maybe then he would do more ;)
20:17 dukeleto darbelo: that is interesting
20:18 darbelo I suspect my presence is a factor in that. If we had a hp-ux user around, I would expect that to work better than windows too.
20:21 allison pmichaud: vivify looks very language-specific in its behavior
20:22 pmichaud allison: it's not
20:22 pmichaud there are a lot of times when we need to do "look up this key in this aggregate, if it doesn't exist, vivify it"
20:22 allison pmichaud: how would other languages know to call it? and if not, would they be getting entirely the wrong semantics on the data structure?
20:23 pmichaud almost every parrot library I've written ends up doing something like that
20:23 allison pmichaud: isn't that all lookups in Perl?
20:23 pmichaud allison: sure, but to do it in PIR is a sequence of about 5 opcodes
20:23 pmichaud actually, 6
20:24 pmichaud and I end up writing it *a lot*
20:24 pmichaud (by hand, not just generated code)
20:24 darbelo The name is rather perlish, but I think it is a generally useful feature.
20:24 allison pmichaud: the part that looks interesting is specifying the type of the autovivify
20:24 pmichaud allison: right
20:24 pmichaud that's the most useful part
20:24 allison pmichaud: (as opposed to always PMCNULL or Undef)
20:25 allison pmichaud: but, I'd rather see that integrated into the normal flow of things than as a separate opcode
20:25 chromatic How would that integration work?
20:25 pmichaud but no, I don't see it as being very perl specific.  In fact, Rakudo won't be using this opcode at all.
20:25 allison get_pmc_keyed_typed, or something like that, with an extra argument
20:25 pmichaud that's "fetch"
20:25 pmichaud we have two opcode
20:25 pmichaud fetch is "get a pmc, if it doesn't exist, give me one of this type"
20:26 pmichaud vivify is "get a pmc, if it doesn't exist, create one of this type and put it in the aggregate I just tried to fetch from"
20:26 pmichaud basically fetch is rvalue lookup
20:26 allison is there a single datatype that needs to be able to do both?
20:26 pmichaud vivify is lvalue lookup
20:27 pmichaud ...single datatype?
20:27 allison a PMC
20:27 pmichaud I'll be using this all over the place, quite honestly
20:27 pmichaud namespaces, hashes, arrays, lexpads, etc.
20:27 pmichaud it's not specific to a type
20:28 allison no, I'm saying, is there any reason the PMC itself can't decide whether to store the created filler or just return it without modifying the aggregate
20:28 pmichaud yes, because it depends on context
20:28 pmichaud the PMC can't know the conetxt unless we tell it
20:28 allison what factors does it depend on?
20:28 chromatic the lvalue/rvalueness of the expression
20:29 pmichaud whether or not I'm just looking up a value (rvalue context) or whether I'm planning to store to it
20:29 allison that's set and get
20:29 pmichaud except that set and get don't vivify
20:29 pmichaud right now I have to go through a sequence of
20:29 allison not for the PMCs we have now, but they could
20:29 pmichaud $P0 = get agg[key]
20:29 pmichaud unless null $P0 goto done
20:30 pmichaud $P0 = new ['XYZ']
20:30 pmichaud agg[key] = $P0
20:30 pmichaud done
20:30 pmichaud s/get//
20:30 allison right, the only part of that we don't have now is the ability to specify what 'XYZ' is
20:30 pmichaud set doesn't vivify, it binds
20:31 pmichaud set doesn't create a new PMC, it causes a key to refer to an existing one
20:31 allison not clear what you're objecting to?
20:32 pmichaud just writing those long sets of instructions over and over
20:32 pmichaud I'm saying that 'set' is not really 'lvalue context'
20:32 allison so, I'm suggesting $P0 = get agg[key], ['XYZ']
20:32 pmichaud why is that any different than   $P0 = fetch agg, key, ['XYZ']    # which is what we have now
20:32 allison where the second arg is "type to fetch/vivify"
20:33 pmichaud is it just the opcode name you're objecting to?
20:33 allison I'm objecting to adding new opcodes, yes
20:33 mikehh joined #parrot
20:33 pmichaud you're adding a new opcode with 'get'
20:33 allison oh, sorry, cut and paste error
20:33 allison $P0 = agg[key], ['XYZ']
20:33 pmichaud okay, that binds the new object, or doesn't?
20:34 pmichaud and whether it does, how do I get to the other form?
20:34 allison PMC chooses
20:34 pmichaud how can the PMC know?
20:34 Coke
20:34 allison you said it was lvalue/rvalue that determines, yes?
20:34 chromatic Isn't that adding a new opcode?
20:34 pmichaud yes but lvalue and rvalue are determined by context of the operation, not by the PMC
20:34 pmichaud not by the aggregate PMC
20:35 pmichaud if I'm writing
20:35 allison chromatic: it's adding an option to an existing opcode
20:35 pmichaud $a = @xyz[3]
20:35 pmichaud that's rvalue context
20:35 pmichaud if I'm writing
20:35 pmichaud @xyz[3] = $a
20:35 pmichaud that's lvalue context
20:35 pmichaud the aggregate is the same in both cases (@a)
20:35 dukeleto If a PMC's VTABLE is called in the woods, and no one is there, does it make a sound?
20:35 pmichaud thus the aggregate cannot know which operation to perform
20:36 pmichaud (sorry, @xyz in example above)
20:36 allison pmichaud: well, a = xyz[3] and xyz[3] = a are different operations in PIR too
20:36 pmichaud no no no
20:36 allison pmichaud: are you saying that you're using some other combination of operations to represent the high-level assignment?
20:36 pmichaud well, yes yes yes, if you mean that we need two opcode for this
20:36 allison I'm saying we have two operations for this already
20:36 pmichaud allison:  please note that   $P0[key] = $P1   is *not* assignment
20:37 pmichaud it's not not not
20:37 allison remember, = isn't an operator in PIR
20:37 pmichaud fine
20:37 pmichaud set $P0[key], $P1   is *not* an assignment
20:37 allison it's just syntactic sugar for completely different opcodes
20:37 pmichaud chromatic, coke, can someone help me out here, please?
20:37 allison I'm definitely not getting what you're driving at
20:38 Coke pmichaud: suggestion: post the sequence you'd like to replace with the one or two liner to show what you're doing.
20:38 chromatic I'm still trying to figure out what allison wants.
20:38 pmichaud I've been saying this for almost two years now and I still can't seem to explain it in a way that allison understands
20:38 Coke and then allison can (perhaps) show you how you can simplify that without changing PIR.
20:38 chromatic I don't understand how to do this *without* adding an opcode.
20:38 allison chromatic: I'm trying to figure out what patrick wants
20:38 Coke there was a post to the mailing list. digging.
20:38 pmichaud I want a way to represent lvalue semantics in PIR
20:38 chromatic It's two high-level operations.
20:38 pmichaud set $P0[key], $P1   is not lvalue semantics
20:39 pmichaud you keep claiming it is, but it's not
20:39 chromatic "Fetch a value from this aggregate.  If there's no value there, give me back a PMC of this type."
20:39 chromatic "Fetch a value from this aggregate.  If there's no value there, create a new PMC of this type, store it in the aggregate, and return it to me."
20:39 allison set is PMC-determined semantics, it's variable
20:39 pmichaud (writing example sequence that Coke suggested0
20:39 Coke (list) perhaps not.
20:39 Coke pmichaud++
20:39 pmichaud allison: I want to do this on our existing PMCs
20:40 pmichaud Hash.  ResizablePMCArray.  NameSpace.
20:40 chromatic I don't want to modify every existing aggregate and every possible existing aggregate.
20:40 allison but those explicitly don't use those semantics
20:40 chromatic The PMCs don't have to use those semantics.  Their existing set/fetch semantics are fine.
20:41 allison forcing a PMC that doesn't autovivify to use autovivification is just wrong
20:41 chromatic These two opcodes exist to allow PIR authors to answer the question "What if the aggregate doesn't contain what I looked up?"
20:41 pmichaud just a sec, the example should make it clear
20:41 Coke allison: it doesn't force the pmc to autovivify.
20:42 Coke that's what we'd get if we changed the what get/set did in a core PMC. this isn't htat.
20:42 allison chromatic: and the answer is "The PMC decides what to return"
20:42 allison chromatic: (and whether to store that return)
20:42 whiteknight allison: autovivification seems to me like it's the particular assignment operation, and not something that the PMC should or should not support
20:42 chromatic And that doesn't always work for PIR programs.
20:43 whiteknight so we can assign-with-vivification or assign-without-vivification, depending on the op, not depending on the PMC's behavior
20:43 chromatic As evidence, I present to you PIR programs that manually perform fetch/vivify because the PMC doesn't know how PIR programs will use them.
20:43 allison whiteknight: it's the semantics of the data type, part of the defined API of the PMC
20:44 allison to be clear, I don't have any objections to PMCs that do autovivify, or to adding some support if the existing vtable functions aren't sufficient to allow them to do it
20:44 chromatic allison, consider this example.
20:44 nopaste "pmichaud" at 72.181.176.220 pasted "example use of vivify opcode" (24 lines) at http://nopaste.snit.ch/18536
20:44 davidfetter joined #parrot
20:44 chromatic Suppose I want a Ruby-style hash which supports a default value.
20:45 allison but, putting that behavior in an external opcode means we dictate autovivification semantics for all languages and all PMC types
20:45 allison we've been bitten by that enough times to learn not to repeat it
20:45 chromatic That is, when you look up a value in the hash, if there's no value for the key, you get back a new value of the default.
20:45 pmichaud I'm not asking to replace our existing set opcode.
20:45 jonathan allison: Huh? We're supplying an additional opcode that a language can use to say who something from an aggregate autovivifies.
20:46 Coke allison: if you don't want to give the choice to the person invoking the PIR code, then perhaps we need more vtables.
20:46 jonathan s/who/how/
20:46 allison ResizablePMCArray was intentionally created not to autovifify like that
20:46 Coke (which we'd need to implement with more opcodes)
20:46 whiteknight more vtables does sound to me like the solution here, although I generally advocate having fewer of them
20:46 chromatic Why would we need more vtables?
20:46 jonathan allison: Which is good - because then we can actually use it with langauges that have different auto-vivification semantics/interests.
20:47 allison jonathan: aye, but it's an opcode, which means the semantics are predetermined for all users
20:47 whiteknight one for a "set without autovivifying" and one for "set with autovivifying"
20:47 chromatic Okay.
20:47 allison whiteknight: yes, that's more what I'm leaning toward
20:47 chromatic I'm declaring a moratorium on discussion from everyone who hasn't read the patches.
20:47 jonathan allison: But the op has an argument saying what to auto-vivify to.
20:47 solarion QUESTION: could there be some sort of reward system for ubuntu devs and MoTUs to encrouage bug-fixing?
20:47 solarion sorry; w/c
20:47 allison chromatic: I read the vivify experimental op patch, are there others?
20:48 chromatic There's a fetch opcode in experimental.ops.
20:48 solarion allison: thanks for the book, btw
20:49 solarion (_Parrot_Developer's_Guide_)
20:49 allison solarion: glad you found it useful
20:51 allison chromatic: yup, fetch should be get_pmc_keyed_typed
20:51 pmichaud and the opcode to access the vtable...?
20:53 jonathan allison: Heh. And then we multiply it out for get_pmc_keyed_int_typed and so forth, and then have to go implement this in multiple PMCs?
20:53 allison pmichaud: set
20:53 pmichaud allison: what variant of set, please?
20:53 allison pmichaud: set_p_p_p_p
20:54 pmichaud please give full example
20:54 allison get_p_p_p_p
20:54 pmichaud there needs to be a key there
20:54 allison (was looking at vivify by that point)
20:54 pmichaud please give me a full set opcode involving  $P0 (result), agg, key, and type
20:54 pmichaud e.g.   set $P0, agg[key], type
20:54 pmichaud or
20:54 pmichaud set $P0, agg, key, type
20:55 allison do you get my basic point about overridable vivification semantics?
20:55 pmichaud you want the PMC to be able to override the type. sure
20:56 * allison comparing to existing get opcodes
20:56 pmichaud there are no "get" opcodes
20:56 pmichaud it's all "set"
20:57 pmichaud fwiw, it would probably live with just having an rvalue form of   set $P0, agg[key], type
20:57 pmichaud s/it/I/
20:58 pmichaud because then I would end up writing
20:58 pmichaud set $P0, agg[key], type
20:58 pmichaud set agg[key], $P0
20:58 pmichaud whenever I need my lvalue semantics
20:58 pmichaud (which seems a bit wasteful... but what can you do?)
20:59 brooksbp joined #parrot
20:59 allison when would you call set $P0, agg[key], type and want it not to store the value back in agg?
20:59 Coke on a related note: there's only so much you can push inside the PMC before anyone interacting with it needs to have a lot of scaffolding code to safely deal with an arbitrary PMC.
21:00 pmichaud when I'm doing an rvalue lookup
21:00 pmichaud in high level code
21:00 allison Coke: which is why the core types are simple, so they're friendly everywhere
21:00 Coke allison: they're not simple.
21:00 pmichaud my $a = @xyz{'foo'}[5][7]
21:00 Coke see also the array issue. =-)
21:00 allison Coke: well, they avoid things like autovivification intentionally
21:01 pmichaud I want to be able to have that give me back an undef even if one or more of the intermediate elements doesn't exist
21:01 pmichaud but it shouldn't vivify them in the process
21:01 pmichaud in the sense of putting them into the aggregate
21:01 Coke (e.g. calling 'push' on something that does 'array' is not safe.)
21:01 Coke (but that's another argument.)
21:02 pmichaud so if set $P0, agg[key], type  automatically creates an element in agg[key], then I can't use that for lookups
21:02 allison pmichaud: (clarifying) do you use set $P0, agg[key], type for both $a = @xyz{'foo'}[5][7] and @xyz{'foo'}[5][7] = $a
21:02 pmichaud no, which is why I've been wanting two different opcode
21:02 purl okay, pmichaud.
21:02 pmichaud *opcodes
21:02 pmichaud one for lvalue context, one for rvalue context
21:02 pmichaud but if I can't have that, then please give me the rvalue one
21:03 allison wouldn't you use set agg[key], $P0, type for the second instead?
21:03 allison (those are two different opcodes)
21:03 jonathan That'd be binding rather than assignment though, no?
21:04 pmichaud afaic, that's really just "fetch" and "vivify" hiding under the "set" opcode name
21:04 allison jonathan: that's determined by the PMC
21:04 pmichaud if there's also a set agg[key], $P0, type form, that's fine
21:04 pmichaud but the problem with that is that it's $P0 that gets modified
21:04 allison pmichaud: my point is, adding typing is a nice feature, but adding new opcode (names) is unnecessary complexity
21:05 pmichaud in other words, in all other forms of set, the first argument is the thing that is being modified
21:05 japhb allison, sorry if I missed this while reading the backlog, but why do you want the PMC to be able to override the default specified in the PIR?
21:05 pmichaud japhb: I don't have much time, please don't tangent yet
21:05 Coke allison: adding another variant called 'set' is ok?
21:05 japhb pmichaud, roger that
21:05 Coke I don't think pmichaud cares what the opcode is named.
21:05 allison japhb: (briefly) different languages have very different semantics for autovivification
21:06 japhb pmichaud, you owe me one for resisting the tangent urges.  ;-)
21:06 allison pmichaud why is $a being modified in @xyz{'foo'}[5][7] = $a?
21:06 pmichaud allison: anyway, syntactically    "set agg[key], $P0, type"  doesn't work well for me and the compiler tools, because it's the only real opcode where the result ($P0) isn't the first operand
21:07 pmichaud allison: because when I'm done, I want the aggregate and the rvalue to be pointing to different PMCs
21:07 pmichaud @xyz{'foo'}[5][7] = $a;   $a = 6;   # should not change the @xyz... value
21:07 pmichaud in other words, with
21:07 allison to be clear, the aggregate is @xyz and the rvalue is $a?
21:07 pmichaud right
21:07 pmichaud in other words...
21:07 purl in other words are there good use cases where you'd choose not to use that module
21:07 pmichaud let's bring it down to the single aggregate case
21:08 pmichaud highlevel, I want to do
21:08 pmichaud @xyz[3] = $a
21:08 allison but, you just assigned to an aggregate, it should change the value
21:08 pmichaud that does *not* mean
21:08 pmichaud please, let me finish
21:08 allison yes
21:08 pmichaud @xyz[3] = $a
21:08 pmichaud that does *not* translate to
21:08 pmichaud $P0 = find_lex '$a'
21:08 pmichaud set xyz[3], $P0, ['Undef']
21:09 pmichaud the correct translation is
21:09 pmichaud $P0 = find_lex '$a'
21:09 pmichaud set xyz[3], $P1, ['Undef']
21:09 pmichaud assign $P0, $P1
21:09 allison ?
21:10 pmichaud if we have
21:10 pmichaud set xyz[3], $P0, ['Undef']
21:10 pmichaud when does the ['Undef'] ever come into play?
21:10 pmichaud more to the point, with @xyz[3] = $a
21:11 pmichaud the end result is that xyz[3] and $a have to refer to different PMCs
21:11 allison which different PMCs?
21:11 pmichaud the one tha tholds the value for $a and the one that holds the value for xyz[3]
21:11 pmichaud otherwise
21:11 pmichaud $a++
21:11 pmichaud ends up changing the value of xyz[3]
21:11 pmichaud (if they refer to the same PMC)
21:12 allison as in, assign semantics with a copy of the value instead of binding the value?
21:12 pmichaud in HLL,  '=' typically means "assign", yes.
21:12 pmichaud and assign != set
21:12 pmichaud set has binding semantics, not assignment semantics, at least for the built-in PMC types
21:13 pmichaud and the libraries I'm writing tend to want to use the built-in PMC types
21:13 pmichaud (because that's all we can guarantee to be available at runtime)
21:14 allison assign $P0, xyz[3], ['Undef']
21:14 chromatic I can't see how that is clearer than fetch or vivify.
21:14 pmichaud that looks a lot to me like "vivify"  :-)
21:14 chromatic It could be fetch.
21:14 Coke allison: that opcode doesn't exist.
21:14 chromatic You have to read the opcode body to know whether it fetches or vivifies.
21:15 allison Coke: yes, we're off into "hypothetical added ops" now
21:15 pmichaud I'm okay if   fetch is    set $P0, xyz[3], ['Undef']
21:15 pmichaud and vivify is  assign $P0, xyz[3], ['Undef']
21:15 allison chromatic: the op shouldn't do either, it should call a vtable function
21:15 chromatic A vtable function for this is wrong.
21:15 chromatic This is *not* the responsibility of the vtable.
21:15 japhb allison, But 'fetch' and 'vivify' at least say what they mean, rather than a magic variant of 'assign' that isn't clear.
21:15 pmichaud but this is the crux of what I've been complaining about for two years
21:16 jonathan allison: Your assumption is that languages will only ever touch their own PMC types that use their own semantics.
21:16 allison chromatic: it's the only way to make it overloadable by PMC semantics
21:16 jonathan allison: This is wrong.
21:16 chromatic PMC's should *not* override this.
21:16 chromatic That is the wrong direction.
21:16 allison autovivification is a language feature
21:16 jonathan allison: This is an area where languages want to operate on other data types.
21:16 chromatic PMC's already *can* give themselves vivify or fetch semantics using the existing vtables.
21:16 jonathan And have the semantics of the *language*.
21:16 allison chromatic: yes, that's my point
21:16 chromatic Yes, and that's why you're wrong.
21:17 jonathan This is an operational semantic of the code that is being executed. It's not a behavioral semantic of the data type being operated on.
21:17 jonathan Thus it does not belong in the PMC.
21:17 allison chromatic: the one thing they can't do is specify a type for the autovivification
21:17 chromatic That's the whole point, allison.
21:17 japhb jonathan is correct.  Cross-HLL, you want the semantics of the *calling* code, not the *called* PMC.
21:17 chromatic If this goes into the vtables and not into the ops, this behavior is *unusable* from PIR.
21:17 chromatic It's unsafe and unreliable.
21:17 allison japhb: if that's the case then this is a Perl6 op, not a Parrot op
21:17 chromatic You can't know the semantics of the operation unless you know the exact type of every aggregate used in these expressions.
21:18 chromatic This *does not work* callee-side.
21:18 japhb allison, No, because what I said is correct across any two languages.
21:19 NotFound We provide ops, languages choose what ops to use.
21:19 whiteknight NotFound: it's not just the ops we provide. Those ops define an interface that we would be stuck with
21:19 whiteknight any op we provide is going to demand a particular interface that all our aggregate types need to satisfy
21:20 Coke whiteknight: not true. they could just throw an exception, like many of our core types do when invoking certain vtables.
21:20 jonathan whiteknight: I don't see how you can argue this when it's an op that operates completely in terms of existing PMC vtable interfaces.
21:20 chromatic That's why I said everyone should *read* the existing fetch op's implementation.
21:20 NotFound whiteknight: or not. They can throw on anything they don't spport.
21:20 Coke (I am not advocating this, mind you, justing pointing it out.)
21:20 allison what these ops do is allow you to force autovivification semantics on any aggregate PMC
21:20 pmichaud no they don't
21:20 whiteknight jonathan: we already have tons of inconsistency in the way various VTABLEs are implemented
21:20 pmichaud the aggregate still enforces the set
21:20 allison I can understand why that might be appealing, but it's not right
21:20 Coke I would say they allow you to /use/ autoviv, not /force/ it.
21:20 chromatic the aggregate still enforces the get
21:21 chromatic The aggregate's existing behavior is preserved and respected.
21:21 chromatic That goes for all aggregates as they exist now.
21:21 whiteknight we would need at least a deprecation cycle to get all aggregate VTABLEs set up to uniformly do what we want
21:21 chromatic That goes for all aggregates that may exist in the future.
21:21 allison not with vivify, it's not
21:21 chromatic That goes for all dynpmcs anyone might eventually create that we may never know about.
21:21 pmichaud allison: even with vivify, it goes through the aggregate's set_*_pmc vtables
21:21 NotFound allison: if we don't provide an op, the only difference is that the operation require several ops.
21:21 pmichaud NotFound +1
21:22 NotFound And possibly introspection
21:22 pmichaud unless and until Parrot provides an opcode that has the semantics I need, I'll just be writing the longhand PIR, because at present there's no other way to accomplish the HLL semantics I'm looking for
21:22 allison NotFound: true enough, but if you provide an overridable interface the language can decide how to handle that request
21:22 jonathan whiteknight: What? We've been doing the thing this op would do in many ops for a long time already. It's not going to need any changes to existing VTABLE aggregates.
21:22 allison it's better than a fixed opcode
21:23 Coke allison: you're confusing the language and the PMCs.
21:23 whiteknight jonathan: maybe this particular case works, yes. My point was about the lousyness of the larger VTABLE environment
21:23 chromatic It's *unusable* if it's PMC-side.
21:23 Coke (long
21:23 Coke ww
21:23 allison Coke: quite a bit of language behavior is built into the PMCs, that's the point
21:23 NotFound allison: I don't see the vtable of a type as a language interface, is an object, it doesn't matter much what language cretaed it.
21:23 Coke allison: yes, but there needs to be a boundary. as it is, I despair of having useful interaction across HLLs.
21:23 allison NotFound: yes, but different languages have different object semantics
21:24 allison Okay, take a step back
21:24 pmichaud allison: let's do this
21:24 pmichaud here's my example:
21:24 pmichaud @xyz[3] = $a;  $a++
21:24 pmichaud how would you write that in PIR ?
21:24 pmichaud keeping in mind that $a and @xyz[3] need to have different values at the end
21:25 whiteknight pmichaud: clone
21:25 allison The original design is that different languages implement their own data types with different semantics, and by useing the VTABLE interface the can all interact (because language A doesn't care what's behind "get a pmc from this aggregate" in language B only that it gets a value
21:26 chromatic That does not change with fetch/vivify.
21:26 allison set xyz[3], a; inc a
21:26 pmichaud allison: that changes xyz[3], if a is a PMC
21:26 pmichaud (which most lexicals are)
21:26 allison chromatic: it does change, because you're putting aggregate semantics into an opcode
21:26 allison chromatic: they're carefully designed to have no semantics in opcodes, only semantics in vtable functions
21:27 allison chromatic: that's why the opcodes are so short
21:27 pmichaud if I have:    $P0 = box 5;  set xyz[3], $P0;  inc $P0;   $P1 = xyz[3];  say $P1
21:27 chromatic Okay, then forget the whole thing.
21:27 pmichaud then I end up with 6
21:27 pmichaud and xyz[3] should be 5
21:27 pmichaud please try again
21:27 chromatic I can't answer the "aggregate semantics" argument.
21:27 chromatic I can't refute the "opcodes are short" argument.
21:27 allison pmichaud: hold on, I'll split that out so I can look it over...
21:28 chromatic The only argument I have left is that the caller side already has to perform all of these operations, using the existing, unmodified VTABLEs.
21:28 chromatic It's obviously necessary code.  It's obviously correct semantics and behavior.
21:28 chromatic (argument from existence)
21:28 allison pmichaud: so, you're fetching the value from the aggregate after you create it?
21:29 chromatic It can't go in new VTABLEs, because that's unreliable.
21:29 pmichaud whiteknight: (clone)  the problem with clone is that it breaks bindings.  For example, if I have:    $b := xyz[3];  xyz[3] = $a;  then the clone+set doesn't work
21:29 chromatic The only conclusion is that this is behavior Parrot won't support.
21:29 pmichaud allison: isn't that normal?
21:29 pmichaud @xyz[3] = $a;  $a++;  print @xyz[3]
21:29 whiteknight the alternative is to have a dynpmc lib
21:29 pmichaud I expect the value of $a before it was incremented
21:29 hercynium joined #parrot
21:29 Coke the clone doesn't work on bind, so don't use it on bind.
21:29 allison pmichaud: seems odd, why do you have to refetch $a?
21:29 pmichaud but  set xyz[3], a;  inc a;   doesn't do that
21:30 Coke allison: that isn't a in his print.
21:30 pmichaud oh please come on
21:30 allison I'm really just trying to understand here
21:30 pmichaud allison:  okay, I'll spell it out
21:31 allison I'm getting a sense that there's something fundamentally broken in our current assignment or lexical handling, but I'm not clear yet what it is
21:31 pmichaud I've been saying this for two years
21:31 pmichaud it's broken in assignment
21:31 pmichaud here's the spelled out version
21:31 allison probably so, but I haven't been able to make sense of it yet
21:31 pmichaud HLL:   my $a = 5;  @xyz[3] = $a;  $a++;  print @xyz[3]
21:31 pmichaud PIR (wrong):   a = box 5;  xyz[3] = a;  inc a;  $P0 = xyz[3];  print $P0
21:31 pmichaud it's wrong because it will print out 6, not 5
21:32 pmichaud whereas the HLL expects 5
21:32 pmichaud I have to go pick up kids, back later
21:32 pmichaud (please give me an alternate form of PIR that will work)
21:32 Coke with the existing sytem there, I'd expect to have to clone a there.
21:32 Coke (and yes that won't work for := - but then you wouldn't use clone.)
21:32 NotFound I don't think that's wrong. Is expected in types by reference.
21:32 allison pmichaud: (sorry, have to split the code out on lines to read it)
21:32 chromatic That's a rabbit trail related to the use of these ops.
21:33 chromatic I mean UNrelated.
21:33 chromatic If the general policy for ops is "They basically delegate to VTABLE calls", then we have a lot of ops to deprecate in the next couple of months.
21:33 allison chromatic: not necessarily, if we're adding ops to get around something that's fundamentally broken, we should look at fixing the breakage first
21:34 chromatic I didn't add fetch to get around something that's fundamentally broken.
21:34 chromatic I added fetch to compress a common case of six opcodes in PIR into one.
21:34 chromatic I did not modify a single PMC to do so.
21:34 chromatic I did not change the semantics of a single PMC.
21:34 jonathan Right, and vivify is the same story.
21:35 jonathan Or "the op proposed under the name vivify that you can call what you like"
21:35 chromatic Any aggregate written *after* I wrote fetch will still behave correctly and as intended.
21:35 allison we're trying to reduce our opcode set, adding new opcodes to handle what could be done in an optimization pass is... suboptimal
21:35 Coke we're trying to reduce our opcode set?
21:35 chromatic How in the world would you do this in an optimization pass?
21:35 allison Coke: radically, yes
21:35 Coke allison: can I snark for a second? =-)
21:36 allison chromatic: it's a common pattern, like tail recursion
21:36 allison Coke: why not, join the club :)
21:36 chromatic Specifics, please.
21:36 chromatic How do you optimize this?
21:37 NotFound allison: Is not the contrary, providing an opcode to be used by the optimization phase?
21:37 allison I think patrick's second example isn't what he meant to write, I think he meant a = box 5; xyz[3] = a; inc a; print $P0 instead
21:37 allison (using a refetch)
21:37 allison NotFound: it's not an opcode to be used by the optimization phase though, it is the optimization
21:38 chromatic *What* is the optimization?
21:38 jonathan allison: Where did $P0 come from in that?
21:38 NotFound allison: we have a tailcall opcode
21:38 allison jonathan: sorry, print a
21:38 pmichaud I did not mean print a
21:38 pmichaud I meant the hll form of   print @xyz[3]
21:38 jonathan allison: No, he didn't.
21:38 masak joined #parrot
21:39 allison no? but then it would print 6, yes?
21:39 chromatic I think the problem there is that the HLL has to note whether a primitive container has container or value semantics for that kind of assignment.
21:39 allison for either?
21:39 Coke allison: see "PIR (wrong)"
21:39 pmichaud Coke:  clone semantics bring up other problems
21:40 allison ah, you're saying the P6 = is a copy, not binding?
21:40 jonathan allison: The HLL example should print 5..
21:40 Coke pmichaud: what other problems?
21:40 Coke (ISTR I'm using this in tcl now to address pretty much the same issue.)
21:40 Coke (clone)
21:40 * allison losing the thread
21:40 allison fetch?
21:40 purl fetch is "get a pmc, if it doesn't exist, give me one of this type"
21:41 allison thanks purl, very helpful
21:41 pmichaud Coke: If I have  $a = 5;  $b := @xyz[3];  @xyz[3] = $a;  $a++;   print $b    the $b should be 5, not the value of @xyz[3] before the assignment
21:41 pmichaud i.e., sometimes we have multiple symbols bound to the same PMC
21:41 allison ah, right, opcodes as optimizations...
21:41 Coke pmichaud: why would you use clone if you had a bind operator in the HLL?
21:42 Coke I'm only suggesting it for p6 =, not p6 :=
21:42 pmichaud Coke: the point is, sometimes we ahve both.
21:42 pmichaud and if assignment is really "rebind to a clone", we lose the original bindings from other symbols
21:42 allison chromatic: if we were in the situation of opcodes built from other opcodes, I'd actually be pretty comfortable with that (the optimization opcodes would be more like jittable subs than anything else)
21:43 Coke pmichaud: ok. I think I get it. I have no idea how you'd solve that in PIR, new opcodes or not. =-)
21:44 allison pmichaud: is that different than using assign vs. set?
21:44 pmichaud yes
21:44 allison (maybe set should be called bind, to be clear)
21:44 pmichaud because there is no "assign to a aggregate element" opcode
21:45 pmichaud the only thing we have for aggregate elements is "set", and that always does a binding
21:45 allison oh, weird binding into aggregates that way
21:45 pmichaud huh?
21:45 pmichaud I should always be able to bind any symbol to any PMC
21:45 calculus joined #parrot
21:45 pmichaud and I should be able to modify the value of that PMC
21:45 allison as in, binding $b sticks with the aggregate value even if you rebind the aggregate value to another variable?
21:45 allison oh, no, I see
21:45 pmichaud in a HLL   @xyz[3] = $a   is NOT A BINDING!
21:46 allison $a's value is copied into the aggregate, not bound to it
21:46 NotFound Don't forger that Integer arrays are value containers.
21:46 allison pmichaud: is that true in Perl 5 too?
21:46 allison or, new to Perl 6?
21:46 NotFound They containt INTVAL, not Integer
21:46 pmichaud oh please
21:47 allison I thought things stored in arrays in Perl 5 were references
21:47 pmichaud no
21:47 pmichaud no no no
21:47 pmichaud they are not
21:47 allison (admittedly, it's been something like 3 years since I wrote much Perl 5 code)
21:48 allison so, arrays and hashes are stored as references, but scalars are stored as copies of scalars?
21:48 pmichaud $ perl -e 'my $a = 5; $xyz[3] = $a; $a++; print $xyz[3],"\n";'
21:48 pmichaud 5
21:48 pmichaud it has *always* been this way
21:48 mokurai joined #parrot
21:49 pmichaud afk for abit, another kid to pick up
21:49 allison interesting
21:49 allison doesn't that get expensive?
21:49 allison I suppose it means Rakudo must be using assign everywhere instead of set
21:50 jonathan *sigh*
21:51 jonathan No, we use the copy op.
21:51 ash_ joined #parrot
21:51 allison chromatic: source code optimizations like that are usually "check for pattern, replace pattern x with behavior y"
21:52 allison chromatic: though that does get into partial jitting
21:52 darbelo allison: a peephole optimizer?
21:52 allison chromatic: which is pretty advanced
21:52 allison darbelo: aye, essentially
21:54 allison darbelo: a bit of a tangent, but I had an "ah-ha" moment at the JVM summit, seeing modern processors doing peephole parallelization on the lowest-level instruction sets
21:55 darbelo I can see that working at the PAST or POST level, but I'm not sure it fits after PIR has been generated.
21:55 chromatic What's the source code optimization here?
21:56 allison darbelo: well, PIR is just a language, it's reparsed into an internal representation (somewhat POST-like)
21:56 chromatic If (and that's a big if) fetch is faster than the corresponding longhand, it's because fewer ops are (modestly) faster than more ops.
21:57 chromatic I don't characterize fetch as an optimization.  It's a convenience to make code shorter, simpler, easier to read, easier to reason about, and more difficult to misuse.
21:57 Coke chromatic: ObDevil'sAdvocate - we could do that with a .Fetch hllmacro.
21:57 Coke ... assuming you find hllmacros easier to read.
21:58 allison chromatic: all fetch does is take the C code that would have made up several lines of PIR code and combine it into one line of C code
21:58 chromatic I don't understand what you mean, allison.
21:58 allison chromatic: the same behavior is being run in both cases, so all you gain is from cutting out the overhead of the separate op calls
21:59 allison chromatic: if your ops are made up of other ops (which are templated to be jit-able), you can gain the same benefit without defining a new op for it
21:59 chromatic I just wrote that it has nothing to do with speed.
21:59 allison chromatic: and you can do it once for everyone, instead of putting it off in a separate op
22:00 allison chromatic: oh, I though you said you added fetch to speed up a common case?
22:00 chromatic No, I added fetch to make common code easier to read and to write.
22:00 allison chromatic: that purpose could be served without a new opcode too
22:01 PerlJam allison: were you implementing pynie?
22:01 chromatic I can think of two ways: a PIR macro, which no one uses, and a fake op which IMCC rewrites, of which we've removed several.
22:01 allison PerlJam: working on it, yes
22:02 allison yes, I hate fake ops
22:02 chromatic That leaves a macro.
22:02 PerlJam allison: how do/would you handle the python equivalent to pmichaud's example?  Something like a = 5; b = [1,1,1,1]; b[2] = a; a += 1; print a; print b;  IIRC
22:02 allison the macro seems silly too
22:02 chromatic What's left then?
22:03 darbelo PerlJam: python -c "a = 5; b = [ a ]; a += 1 ; print b[0]"
22:03 allison set $P0, agg[3], type
22:03 PerlJam darbelo: thanks.  my python is completely rusted :)
22:03 chromatic I find that very unclear.
22:04 allison darbelo: b = [ a ]?
22:04 japhb The names matter.  'fetch' and 'vivify' actually mean something.
22:04 PerlJam darbelo: I don't think the b = [ a ] part is quite the same
22:05 allison japhb: but they mean almost exactly the same thing as 'get'
22:05 darbelo My python is kinda rusty too. I could be wrong there.
22:05 allison there's a principle of distinction here
22:05 chromatic You mean "different behaviors have different names"?
22:06 japhb allison, it's the small but critical differences that you want to highlight.
22:07 japhb I want it to be easy to explain to people who don't already know, and have a better than snowball's chance of them remembering it.
22:08 allison darbelo: a more exact translation of pmichauds is python -c "b = [1, 1]; a = 5; b[1] = a; a += 1 ; print b[1]"
22:08 allison (with a little extra to handle the lack of autovivification)
22:09 allison chromatic: aye, and behaviours that are only tiny modifications on existing behaviors don't have different names
22:10 allison If this were an HLL, I'd probably go for something more like $P0 = agg[3] :default('Undef')
22:10 allison but, PIR is a primitive language
22:11 chromatic The fact that we can talk about vivification and get as separate things suggests that the semantic differences are not tiny.
22:11 allison well, on that level, we should have a dozen different opcode names instead of set
22:12 japhb allison, I would disagree with that.  Consider all the ways to declare a variable in Perl (6 especially, but even with 5).  'my' and 'our' are both declaring a variable and are syntactically all but identical, it's only a matter of the scoping mechanism used.  Most beginners don't even realize there is a difference.  But it's highlighted anyway.  Because the distinction is important.
22:12 allison it's an abstraction to hide the complexity
22:12 japhb 'disagree with that' referring to tiny mods don't have different names
22:12 allison yes, distinction and reuse are balanced principles
22:12 allison we're weighing the balance here
22:13 chromatic I don't believe 'fetch' is the best possible name.
22:13 japhb Fair enough.  I argue that this distinction is important enough to warrant different names.
22:13 chromatic I'm open to a better name for 'fetch'.  That better name is not 'set'.
22:13 japhb And I will grant chromatic's point, but I don't know of a better one.
22:14 chromatic As for 'vivify', 'reify' is more accurate, but less clear.
22:14 japhb chromatic, explain why ... My (admittedly weak) memory of reify is not matching this well.
22:15 allison the valuable part of fetch is passing in the default type. there's currently no way to do that
22:15 japhb allison, currently no way to do that *in a single op*
22:15 chromatic reify has the connotation of bringing something abstract into existence
22:16 allison and the redundant code comes from people taking the default value they get back and then creating an alternate default value
22:16 chromatic vivify has the connotation of bringing something to life
22:16 allison japhb: yes
22:16 japhb chromatic, Ah, I thought of it as "making the abstract real", an act of conversion instead of creation or birth.
22:16 allison we do make it cheap by using the singleton PMCNULL, so at least we're not creating a default PMC, throwing it away and creating another default PMC
22:16 japhb I guess that's why you said it was less clear.  :-)
22:17 darbelo japhb: Verdinglichung ;)
22:18 allison the one thing I still don't understand from pmichaud's conversation is the vivify/fetch distinction (essentially, are these orthogonal features?)
22:18 chromatic Yes.
22:18 japhb darbelo, out of curiosity, what is the literal translation of that?  (As opposed to "it means reify")
22:18 chromatic vivify is fetch + store
22:18 pmichaud vivify is:
22:19 pmichaud $P0 = fetch agg, key, ['Undef']
22:19 allison chromatic: yes, but from the beginning of Parrot, we've said that PMCs decide whether to store the default value or not
22:19 pmichaud set agg[key] = $P0
22:19 moritz ding = thing
22:19 pmichaud er
22:19 pmichaud I'll redo
22:19 pmichaud vivify is
22:19 chromatic Unnecessary anthropomorphism is usually less clear.
22:19 moritz verdinglichung = "the processing of making a thing of something"
22:19 pmichaud $P0 = fetch agg, key, ['Undef']
22:19 pmichaud set agg[key], $P0
22:20 moritz (or the process of making somethinig a thing)
22:20 pmichaud except that we don't do the 'set' part if agg[key] already existed at the time of the fetch
22:20 pmichaud so vivify is really more like
22:20 pmichaud $I0 = exists agg[key]
22:20 pmichaud $P0 = fetch agg, key, ['Undef']
22:20 pmichaud if $I0 goto label
22:20 pmichaud set agg[key], $P0
22:20 pmichaud label:
22:20 allison and what HLL code do you translate to vivify? versus what HLL code do you translate to fetch?
22:21 pmichaud @agg[key] = 3;   # vivify
22:21 chromatic Why does that matter?
22:21 pmichaud $a = @agg[key];  # fetch
22:21 allison chromatic: trying to figure out the use
22:21 pmichaud we use vivify when we have an lvalue semantic.  we use fetch when it's an rvalue semantic
22:21 pmichaud more specifically
22:22 pmichaud @agg[key]{'foo'}[bar] = 3;  # vivifies all of @agg[key], @agg[key]{'foo'}, and @agg[key]{'foo'}[bar]
22:22 pmichaud $a = @agg[key]{'foo'}[bar];   # doesn't vivify any of them
22:22 allison pmichaud: on @agg[key] = 3; # vivify... that doesn't translate to set_integer_keyed?
22:22 pmichaud okay, $b then
22:22 darbelo japhb: What moritz said, and I'm probably missing something in the tri-lingual translation but you can think of it as "thingificating an abstract" too.
22:23 pmichaud but no, it's not set_integer_keyed
22:23 pmichaud because set_integer_keyed does a rebind instead of an assignment
22:23 allison well, not with an integer constant
22:23 pmichaud yes, with an integer constant
22:23 pmichaud please go look at the CODE
22:23 allison but with @agg[key] = $a, yes
22:23 pmichaud with    set agg[key], 3    # creates a new PMC, binds agg[key] to it
22:24 pmichaud which stinks if you had some other symbol that was supposed to be bound to agg[key]
22:24 allison pmichaud: sure, but it's the vtable function that decides that
22:25 chromatic And there's a problem right there.
22:25 allison I mean, at the C level, the int that gets passed into the vtable function isn't bound in any way to the constant in the PIR code
22:25 pmichaud my point is that it broke the binding
22:26 allison PMCs have to allow different semantics for different languages
22:26 pmichaud set $P0, agg[key]
22:26 pmichaud store_lex '$b', $P0
22:26 pmichaud agg[key] = 3;   # oops, $b is not 3
22:26 pmichaud (this being a HLL binding, not assignment -- i.e.,   $b := agg[key] )
22:27 pmichaud you can say "its the vtable function that decides the semantics", but I'm working with the vtable functions of the builtin PMCs
22:27 pmichaud if you say "you should have custom PMCs", I really don't want to do that for PGE, NQP, PCT, etc.
22:27 allison that was the design decision that was made for the semantics of those PMCs, yes, but it's not required for all PMCs
22:28 pmichaud and part of the point is that the  builtin PMCs aren't even sophtisticated enough to support the semantics of common HLLs
22:28 pmichaud I mean, not even the basic semantics
22:28 pmichaud at least, not without jumping through lots of hoops
22:28 allison I guess the question there is who the target user is for those core PMCs
22:29 allison yeah, they aren't meant to be complex, they're meant to be a simple baseline
22:29 pmichaud but the simple baseline isn't sufficient to support simple assignments in HLLs
22:29 pmichaud more than that...
22:30 pmichaud our vtables don't give a HLL the ability to make a distinction between assignment to an aggregate element and binding of an aggregate element
22:30 allison that is true, and may be the root problem here
22:30 pmichaud so an HLL gets to choose one, and then figure out how to work around things for the other
22:30 pmichaud and if two HLLs make different choices, then interop is completely gone
22:31 allison (not that I'm entirely fond of adding assign_pmc_keyed, etc...)
22:31 pmichaud assignment versus binding are *basic*, and Parrot has them completely screwed up
22:31 dukeleto holy vivification, batman!
22:31 chromatic Not that that is an argument for, against, alongside, or related to fetch/vivify.
22:31 pmichaud agreed
22:31 pmichaud anyway, here's my takeaway
22:31 allison early on Parrot made the assumption that a language would use either assignment or binding for its aggregates, not both
22:32 pmichaud that's a bad assumption, given that many languages have both
22:32 allison very possibly true, and that may need to change
22:32 pmichaud I see long deprecation cycles in our future, which totally doesn't help me today.
22:32 allison (the default assign_whatever_whatever could always be an alias to the set equivalent)
22:32 allison what's your takeaway?
22:33 allison pmichaud: ah, but this is an addition, which could happen tommorrow
22:33 pmichaud no, because it has to be done for all of the PMCs
22:33 pmichaud and because set and assignment are so screwed up in Parrot already, anything we add is going to make it even more convoluted
22:33 chromatic All PMCs now and forever.
22:33 allison pmichaud: still an addition of new features
22:33 pmichaud I'm telling you, it's completely screwed up internally.
22:34 pmichaud "I see long deprecation cycles in our future."
22:34 allison how about new PMCs?
22:34 pmichaud what new PMCs?
22:34 chromatic Ugh.
22:34 allison the old names are horrible anyway
22:34 pmichaud oh, you mean create all new ones
22:34 pmichaud I doubt that happens "tomorrow"
22:34 allison do you really need anything but ResizablePMCArray?
22:34 chromatic That also means a long deprecation cycle and switchover flag days and....
22:34 pmichaud Hash
22:34 chromatic NameSpace
22:34 purl NameSpace is the internal namespace for things like $c->forward and template paths, anyway or  hll:X::Y, but yes.
22:34 allison or maybe TypedArray?
22:34 pmichaud LexPad
22:35 pmichaud please, not TypedArray
22:35 pmichaud don't make the assumption that all of the elements created in an aggregate are going to be the same type
22:35 pmichaud sometimes that last parameter is ['Undef'].  Sometimes it's ['Hash'] (for the same aggregate)
22:35 allison we're talking about adding new interfaces to them for aggregate assignment
22:35 pmichaud anyway
22:35 allison (not removing the existing interfaces for aggregate set)
22:36 pmichaud my takeaway at the moment:  all I wanted was two simple opcodes to make my coding life easier
22:36 allison ah, well that's the point of TypedArray, get rid of the silly "single type" assumption
22:36 pmichaud those aren't going to come.  my choices seem to be to redesign the Parrot binding and assignment universe, or live with what we have now.
22:36 allison chromatic did great work with CallSignature
22:37 allison I'd love to see that as the new Array, and get rid of all the silly single-typed Arrays
22:37 pmichaud we also need to fix Integer, Float, and String then
22:37 allison they're just single elements
22:37 pmichaud but you can assign to them
22:37 pmichaud more importantly, you might be assigning something that isn't an Integer, Float, or String
22:38 pmichaud but right now, Parrot assumes assignment is of like types
22:38 pmichaud or, more weirdly
22:38 pmichaud if I do
22:38 dukeleto pmichaud: perhaps we can make some dynops for you? that means they are not part of core and don't have to deal with dep cycles
22:38 allison aye, and we already have assign_string_native vtable function
22:38 allison (for example)
22:38 pmichaud If I do:
22:38 pmichaud (HLL)
22:38 pmichaud actually, let's start over
22:38 pmichaud if I do:
22:38 pmichaud $P0 = new ['Hash']
22:38 pmichaud .lex '$a', $P0
22:38 pmichaud $P1 = find_lex '$a'
22:39 pmichaud assign $P1, 3
22:39 pmichaud from a HLL perspective, I'd want $a to be an Integer 3
22:39 pmichaud what I get now is an error
22:39 allison what error?
22:39 purl allison: Srmount error
22:39 allison undefined PMC?
22:39 pmichaud no
22:39 pmichaud it tries to do   assign_integer on the Hash PMC
22:39 pmichaud when what I really wanted (HLL)  was   $a = 3
22:39 pmichaud i.e., $a previously had a Hash in it, but now I want it to be an Integer 3
22:40 allison that's because Parrot doesn't do morphing
22:40 pmichaud right
22:40 pmichaud thus my point that it's messed up
22:40 allison (we carefully ripped out morphing)
22:40 pmichaud being able to store any object in any container isn't available in Parrot, and that's a common feature of dynamic languages
22:40 allison well, it's not Perl 6 semantics, that's true
22:40 allison but, Perl6Hash can do it if it wants to
22:40 pmichaud you're missing my point
22:41 allison maybe what we really need to do is deprecate all the core PMCs
22:41 pmichaud "I see long deprecation cycles in our future..."
22:41 allison seriously, just don't provide any
22:41 pmichaud anyway, I'm sorry, but I'm frustrated enough by this that I just want to drop the whole thing and live with the lousy situation we have now
22:41 allison provide some example dynpmcs
22:41 moritz that will simplify HLL interop enourmously, will it?
22:42 allison moritz: HLL interop is through vtable interfaces
22:42 moritz </sarcasm>
22:42 allison pmichaud: I'm actually less frustrated now, I feel like I'm beginning to understand what you need
22:42 moritz allison: and is that enough to identify objects? detect that $thing_from_oher_hll is an array?
22:43 allison moritz: that's what does and provides are for
22:43 allison (two different ways of declaring that a particular PMC agrees to support a specific set of vtable functions)
22:43 pmichaud what parrot needs is a rethink of its low-level vtable methods, its core PMCs, it's calling convention interface, and who knows what else.  What I need is a platform that can release Rakudo Star in April.
22:44 allison do you need fetch and vivify to be core to do that?
22:44 pmichaud I don't *need* them, it makes my life tons easier.
22:44 pmichaud I can continue to code things the long way.
22:44 allison or define a dynop
22:45 pmichaud these need to be available in core parrot
22:45 pmichaud I'm not talking about Just Rakudo.
22:45 pmichaud These are for the regex engine, and NQP
22:45 pmichaud Rakudo already does stuff entirely different than this.
22:45 allison the regex engine is written in NQP now, yes?
22:45 pmichaud yes
22:45 allison so, it's not relevant there
22:46 pmichaud well, the parsing and compiling bits.  the runtime is still written in PIR
22:46 darbelo Austin's Close and Kakapo would benefit from that as well, if I read him right the last time this was discussed.
22:46 allison and NQP is written in, what, PCT? as in regex plus NQP actions, translated to PIR?
22:46 pmichaud anyway, the reason I wrote the opcodes and provided the patch for chromatic to review was because I said "I can make my life a lot easier if I do this."
22:47 pmichaud If you're just trying to talk me out of the opcodes, please don't waste any more time on it, let's just say "no" and move on.
22:48 pmichaud My life would be easier with the opcodes present.  I'd prefer not to create dynops for NQP, because NQP really wants to be able to compile to core Parrot without any special features (that's its purpose).
22:48 pmichaud i.e., NQP wants to be able to create PIR subroutines that Parrot can run even when NQP isn't present.
22:49 allison yes, agreed
22:49 pmichaud anyway, gotta go, kids need my help.
22:58 Zak joined #parrot
23:00 Whiteknight joined #parrot
23:12 zak_ joined #parrot
23:21 Whiteknight so was there an outcome in the vivify opcode discussion?
23:21 * Whiteknight slowly starts reading through logs
23:22 darbelo Whiteknight: pmichaud had to help his kids.
23:22 Whiteknight well, that is one possible outcome, though not what I was predicting
23:23 kiwichris joined #parrot
23:23 darbelo Not much of an outcome, but there was some very interesting dicussion about asignement and binding sematics.
23:28 Whiteknight there are a lot of aspects in the current situation that I am particularly unhappy with
23:28 Whiteknight binding and assignment are two, vtables in general irritate me to no end.
23:28 darbelo If the vm were perfect we wouldn't be working on it ;)
23:29 * darbelo is removing a vtable now.
23:29 Whiteknight no argument
23:29 Whiteknight In general, I like the idea of the vivify and fetch opcodes. They represent patterns that demonstrably get used A LOT
23:30 Whiteknight I worry that VTABLEs are so limiting, and are so inconsistent between different PMC types
23:30 darbelo Same here. But I think allison was arguiing something different than this particular case.
23:31 Whiteknight I definitely understand what she was saying, it's a shade of the same concern I have
23:31 darbelo Languages have to jump through lots of hoops. fetch/vivify make it a one line hoop.
23:31 kid51 joined #parrot
23:31 darbelo She was arguing that the very existance of the hoop means something's wrong with our design.
23:32 Whiteknight right, but it requires that PMC vtables be more consistent, because we're applying an external interface to them
23:32 Whiteknight and we would rightfully expect that any aggregate would "do the right thing" when passed to a vivify or fetch opcode
23:32 chromatic And they do, if the aggregate does anything at all sane with get/set.
23:33 Whiteknight where "the aggregate" is some of the Resizable*Array types, and Hash (generally)
23:33 darbelo but the current design points in the other direction, the design say 'the PMC decides'.
23:33 japhb Whiteknight, and namespace, and so on.
23:33 japhb er Namespace
23:33 Whiteknight japhb: that's my point! We have lots of types of aggregates, and they all need to behave similarly
23:33 Whiteknight or, at least do what we expect
23:34 Whiteknight what if we pass a MultiSub to vivify? Or Env? Or CallSignature? Or Context? or...
23:35 Zak joined #parrot
23:35 darbelo fetch/vivify are, simultaneously, working around a design decision *and* codifying a very useful and common idiom.
23:35 chromatic At some point you have to expect the caller side to do something sane.
23:35 chromatic That's why callee-side semantics alone are insufficient.
23:35 japhb Whiteknight, given that vivify can be directly translated to a sequence of simpler ops, then the answer is "whatever would happen with the original op sequence"
23:36 jonathan japhb++ # exactly.
23:36 mikehh joined #parrot
23:39 allison Whiteknight: similarly, but not identically
23:40 Whiteknight not identically, no. But the VTABLEs in general are so wildly inconsistent right now
23:40 Whiteknight and I'm not just talking about aggregate-related ones (which tend to be better than most)
23:45 Whiteknight What I like about the vivify and fetch opcodes is that, if aggregates satisfy their role contracts appropriately, we gain the ability to apply new behaviors like autovivification to them externally without changing their internals
23:45 Whiteknight and, we can't deny the huge benefit they have on generated PIR code
23:46 Whiteknight so it's a good use case to show that we need these consistent VTABLE interfaces, so that we can start layering new standard behaviors on top
23:46 japhb Whiteknight++ # well said
23:46 Whiteknight that kind of guarantee is very important if we expect HLLs to be using our PMC types with any surety
23:49 Whiteknight because if we can't even make our *Array types conform to a simple, and commonly used, interface  our HLL developers have no hope of using them effectively
23:51 kiwichris Could someone please help with Parrot_runcode for the RTEMS port ?
23:51 Whiteknight kiwichris: what's the problem?
23:51 purl somebody said the problem was that alpine is talking to an SMTP daemon when making local deliveries, and that is having unexpected effects.
23:52 moritz purl: forget what's the problem
23:52 purl moritz, I didn't have anything matching what's the problem
23:52 moritz purl: forget what's the problem?
23:52 purl moritz, I didn't have anything matching what's the problem
23:52 cotto_work no, the problem is you
23:52 purl okay, cotto_work.
23:52 jonathan purl: forget the problem
23:52 purl jonathan: I forgot problem
23:52 kiwichris Whiteknight, the code seems conditional on EXEC_CAPABLE. Does this mean an exec happens ?
23:52 moritz purl: no, what's the problem? is <reply>|
23:52 purl wish i knew, moritz
23:52 * moritz can't remember the syntax
23:53 Whiteknight kiwichris: okay, we can look at that. I have a strong suspicion that EXEC_CAPABLE is a remnant of a system we no longer have
23:53 kiwichris Whiteknight, great cause I do not have exec being a single address space OS
23:53 darbelo Whiteknight: You are thinking of the exec runcore?
23:54 darbelo kiwichris: What file/line is that giving you trouble in?
23:55 kiwichris darbelo, src/embed.c:828 on 1.6.0 (still to move to 1.7.0)
23:55 darbelo Also, what parrot version are you working with?
23:55 darbelo Ah. 1.6 still had JIT.
23:55 kiwichris darbelo, EXEC_CAPABLE is not defined
23:55 kiwichris darbelo, should I move to 1.7.0 ?
23:55 darbelo kiwichris: Probably.
23:55 kiwichris darbelo, great I will. Back in a while.
23:56 darbelo You could wokr around it by making EXEC_CAPABLE 0 I think.
23:56 japhb kiwichris, and consider doing tests from the svn HEAD as well, as there was some extremely heavy branch merging post 1.7.0, so 1.8.0 may have new surprises for you.
23:57 darbelo japhb: Let's go easy on him, we don't want to scare him away yet. ;)
23:57 dukeleto kiwichris: hello!
23:57 kiwichris japhb, ok, I think HEAD testing is always good to do.
23:58 japhb darbelo, :-)
23:58 kiwichris dukeleto, hi. We need to chat about exit at some point in time. An exit === reboot for me.
23:58 darbelo Hmm, kiwichris are there any recipes for building RTEMS from OpenBSD? I looked around but didn't find much.
23:59 dukeleto kiwichris: oooh. where are we calling exit?
23:59 dukeleto kiwichris: also, I am seeking $food in a few minutes and we back in a bit
23:59 kiwichris kiwichris, yeap in a few places.
23:59 dukeleto kiwichris: but there are lots of nice peeps in here to help you (except purl)

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced