Parrot 1.7.0 "African Grey" is out! | Fix issues caused by the pcc_reapply and context_auto_attrs merges | find out what's up with the slice opcode | Latest modified TT's: icanhaz.com/parrotbugs
Set by moderator on 1 November 2009.
00:05 ash_ joined 00:07 brooksbp_ joined
NotFound clear winxed style, revision 2: winxed -e "print((new 'FileHandle').open('tput clear', 'rp').readall())" 00:08
Try that with python X-) 00:09
00:13 payload joined 00:29 theory joined 00:48 brooksbp joined 00:53 abqar joined 01:18 Whiteknight joined 01:26 b0nk joined
b0nk lo 01:26
01:28 JimmyZ joined
Whiteknight hello 01:33
01:33 ash_ joined 01:35 mokurai1 joined 01:36 b0nk joined
JimmyZ Whiteknight: hello, good localtime. 01:41
Whiteknight hello JimmyZ 01:43
01:44 kiwichris joined 01:55 kid51 joined 02:04 mokurai joined 02:06 cognominal joined 02:18 JimmyZ joined
dalek TT #1174 created by kjs++: Disallow .local declarations in long-style call statement 02:21
ash_ so, Whiteknight, i had some questions about L1 if your not busy 02:25
Whiteknight ash_: sure thing 02:27
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
I guess, some of the things that confuse me are if L1 is going to emit C code, can it only statically compile stuff?
i am confused how all of that works together really 02:30
if your going to have a compiler for L1 code, or just runtime support for it
dalek tracwiki: v6 | coke++ | StringsTasklist 02:31
tracwiki: trac.parrot.org/parrot/wiki/String...ction=diff
tracwiki: v7 | coke++ | StringsTasklist 02:37
tracwiki: trac.parrot.org/parrot/wiki/String...ction=diff
chromatic What we'll eventually execute is only Lorito ops. 02:39
Whiteknight ash_: L1 is just another programming language that has a very simple translation into machine language 02:42
so instead of writing things in C, we write it in Lorito, which can be compiled down to machine language just like C
except simpler then C
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
once we have a Lorito "compiler", we can rewrite all our ops definitions in Lorito instead of C
Coke RT: 126 02:44
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 rrot-linear-algebra: 8b58ae2 | Whiteknight++ | (2 files):
add an is_equal vtable and tests. Add tests for the clone vtable using the new is_equal functionality
rrot-linear-algebra: 1bcaec7 | Whiteknight++ | t/10-nummatrix.t:
add tests for the resize method
rrot-linear-algebra: b844ab6 | Whiteknight++ | (2 files):
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
rrot-linear-algebra: 66f7571 | Whiteknight++ | t/10-nummatrix.t:
add tests for fill method
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
...and optimize as a group
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:47
dalek tracwiki: v8 | coke++ | StringsTasklist 02:50
tracwiki: trac.parrot.org/parrot/wiki/String...ction=diff
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
that is from line 647-648 in src/pmc/fixedpmcarray.pmc
currently that call to _ is blocking porting to RTEMS, it shows up as undefined at link time with the cross-compiling setup 02:53
any body know what is up with it?
include/parrot/parrot.h 02:55
236:# define _(s) gettext(s)
242:# define _(s) (s)
what the junk is up with that?
02:56 Zak joined
chromatic l10n and i18n 02:56
dukeleto chromatic: i see, says the blind man 02:57
the calls to _() are blocking porting to RTEMS right now
chromatic Somehow you have to get the #define on line 242 then.
nopaste "dukeleto" at 69.64.235.54 pasted "Current link failure on RTEMS port" (23 lines) at nopaste.snit.ch/18527 02:58
dukeleto this was given to me, run against parrot 1.6.0
chromatic Somehow they're defining PARROT_HAS_GETTEXT then. 02:59
dukeleto chromatic: and they shouldn't? 03:00
chromatic: what kind of gettext's do we support?
03:07 kiwichris joined
dalek TT #1175 created by particle++: Get external Perl5 modules out of the parrot repo 03:07
Coke I would dig up particle, as I recall he's behind any attempts at gettext. 03:11
... unless this is just a x-compilation issue. 03:12
dukeleto 'ello 03:13
03:13 theory joined
dukeleto msg particle are you the gettext() man? 03:13
purl Message for particle stored.
dukeleto msg particle fix this: nopaste.snit.ch/18527 and you get a pony 03:14
purl Message for particle stored.
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:16
03:17 brooksbp joined 03:18 mokurai1 joined 03:20 brooksbp joined
dukeleto chromatic: ok, i think i have worked passed that issue with them 03:21
chromatic: now we are dealing with powl() being an optional posix extension
we should have a Configure-time check for wether powl exists 03:26
pct? 03:29
purl it has been said that pct is the Parrot Compiler Toolkit
Coke kid51++ # forcing me to change my email as I was composing by closing a ticket. 03:30
dukeleto: yes. instead of that define hackery, there should be a config check for it. 03:31
(and then you can override it for that platform.)
dalek TT #1176 created by dukeleto++: Configure-time check for whether to use powl() or pow(), since powl() is ... 03:33
dukeleto powl isn't even needed either. pretty hilarious. just youthful indescretion 03:35
03:36 janus joined, RobertLJ joined
Coke if it's not needed, kill it? 03:37
dukeleto Coke: let me see if the test suite passes if I change it to pow() 03:38
kiwichris Ah ok. 03:39
dukeleto kiwichris: hell!
hello, even
dukeleto is too excited
#if NUMVAL_SIZE == DOUBLE_SIZE 03:40
# define POW pow
#else
# define POW powl
#endif
lulz
that is wronger than wrong
/* local macro to call proper pow version depending on FLOATVAL */
kiwichris: you are using the released version of parrot 1.6.0, correct? 03:42
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.
dukeleto, there could all sorts of things I have missed. The FC9 box is 64bits. Does that help ?
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.
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:46
kiwichris dukeleto, #define NUMVAL_SIZE 4, and #define DOUBLE_SIZE 8 03:47
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
we assume that if NUMVAL_SIZE != DOUBLE_SIZE , powl() should be used. i guess that is just not always true. 03:51
powl() should only be used if it exists
kiwichris kiwichris, agreed
chromatic powl() is C99 and POSIX 2001. powl() returning only a double, not long double, is C89. 03:53
03:59 Andy joined
kiwichris dukeleto, Any idea what Parrot_set_config_hash is ? 04:01
dukeleto kiwichris: hmmm 04:02
kiwichris: what trouble is it causing you? 04:03
kiwichris dukeleto, unresolved external
dukeleto, called in main.c
dukeleto kiwichris: src/parrot_config.c 04:05
src/parrot_config.c
15:void Parrot_set_config_hash(void);
'make coretest' passes on darwin/x86 when I change POW to be pow() 04:06
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?
Coke dukeleto: I abstain. 04:12
but if you close 10 RTs, I'll vote yes. =-)
msg pmichaud will nqp-rx make it easier to implement the tcl RE syntax? 04:14
purl Message for pmichaud stored.
Coke is there a way to change the output of Parrot_sprintf_format so that there are no leading 0s on an exponent? 04:29
(or do I have to post-process it myself?) 04:30
dukeleto Coke: i don't know about sprintf 04:31
Coke: the new nqp-rx runs faster and has variable interpolation and implements the perl 6 regex spec more correctly
Coke: i would guess that interpolation is the biggest win for you 04:32
Coke: 'make fulltest' passes when I change POW=powl to POW=pow
Coke dukeleto: my offer of a yes vote for closing out 10 RTs still stands. =-) 04:34
dukeleto Coke: ok. I am verifying that fulltest also passes on linux. I will look at some RTs :) 04:35
kiwichris dukeleto, fixed the last external and all links. Many thanks. Will try and run in qemu. 04:37
dukeleto kiwichris: awesome! 04:38
purl awesome is a window manager or at awesome.naquadah.org or awesome!
dukeleto purl, go play in traffic and die in a fire
purl dukeleto: excuse me?
dukeleto purl, go play in traffic and die in a fire is on the double!
purl OK, dukeleto.
dukeleto purl, go play in traffic 04:39
purl wanders off to dent some cars.
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.
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
kiwichris: but a patch against 1.6.0 is very useful to us as well 04:41
kiwichris dukeleto, does that mean using svn ?
dukeleto kiwichris: nope. just downloading the 1.7.0 tarball
kiwichris: ftp://ftp.parrot.org/pub/parrot/releases/devel/1.7.0/
kiwichris dukeleto, thanks 04:42
dukeleto kiwichris: it looks like our latest dev release link never got updated. that is my fault
www.parrot.org/release/developer points to 1.6.0 still. that is wrong
kiwichris dukeleto, ah ok now I understand
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.
dukeleto kiwichris: it hopefully has less bugs and more features :) 04:47
kiwichris: grub is a formidable devil
kiwichris dukeleto, it is nice when it is working ... just getting to that point .....
dukeleto kiwichris: indeed. 04:50
dalek rtcl: ae412db | coke++ | t/cmd_expr.t:
Add a test for this issue.
dukeleto is running fulltest on linux with POW=pow
04:53 szabgab joined
kiwichris dukeleto, runs until the following error PackFile_set_header: Unsupported floattype NUMVAL_SIZE=4, PARROT_BIGENDIAN=little-endian 04:53
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 nopaste.snit.ch/18528
dukeleto kiwichris: can you post the full error on nopaste.snit.ch ?
kiwichris dukeleto, That is it.
dukeleto kiwichris: there is an option there to post the link to the channel 04:55
04:56 ash__ joined
dukeleto Coke: fulltest passes on linux with POW=pow 04:56
nopaste "kiwichris" at 58.172.128.7 pasted "RTEMS parrot on i386 qemu fails" (2 lines) at nopaste.snit.ch/18529 04:57
dukeleto kiwichris: src/packfile.c 05:01
1305: exit_fatal(1, "PackFile_set_header: Unsupported floattype NUMVAL_SIZE=%d,"
kiwichris: are you playing around with PARROT_BIGENDIAN ? 05:02
kiwichris: what is NUMVAL_SIZE ?
kiwichris: oh, it is 4. duh
kiwichris dukeleto, Not BE but yes NUMVAL_SIZE 05:03
dukeleto kiwichris: we don't seems to have a branch for NUMVAL_SIZE=4
s/seems/seem/
kiwichris dukeleto, what us NUMVAL_SIZE ?
s/us/is/
dukeleto kiwichris: it is defined in include/parrot/config.h 05:05
/* We don't have a portable config for 64-bit * registers yet. */
that comment does not sit well with me
kiwichris dukeleto, but I am only 32bits. We do not support 64bit targets yet. It is happening but on the PC.
dukeleto are you defining NUMVAL_SIZE=4 somewhere? we set it to 8 and then it gets changed from under us, it looks like.
kiwichris dukeleto, The linux that did the configure is 64bits 05:06
dukeleto kiwichris: that could be an issue
kiwichris: but I am not sure
kiwichris dukeleto, yeap I suspect so. I will dig around later for a 32bit Linux host and see what it reports. 05:07
dukeleto, have to run and again many thanks for the help. It is close now
dukeleto kiwichris: awesome, thanks for the great work! 05:08
dalek rrot: r42217 | dukeleto++ | trunk/src/string/api.c:
[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
TT #1177 created by dukeleto++: test buffer_size in t/pmc/parrotio.t 05:23
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
TT #1179 created by dukeleto++: Test open file, close file, delete file, reopen previously opened stream 05:29
dukeleto Ticket 46827: Permission Denied 05:30
i can't seem to close some RT's
pmichaud Coke: Yes, nqp-rx will make it much easier to implement the tcl re syntax 05:36
msg Coke yes, nqp-rx will make it much easier to implement the tcl re syntax 05:39
purl Message for coke stored.
dukeleto pmichaud: ping! 05:44
Coke danke.
pmichaud dukeleto: pong
Coke: writing a p5 syntax parser for nqp-rx is on my todo list 05:45
Coke dukeleto++
dukeleto pmichaud: so in general, you will attempt to make released versions of nqp-rx that are pegged to released versions of parrot?
pmichaud explicitly so that we can then create a real tcl-rx
dukeleto: can't say for sure
Coke pmichaud: spif. danke.
dukeleto pmichaud: i am trying to work out how parrot should utilize nqp-rx
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
dukeleto pmichaud: also, how do you feel about HLL's that require nqp-rx as well as parrot?
pmichaud: what if you released the week after the parrot release? 05:47
pmichaud dukeleto: I think that's going to be the norm.
dukeleto pmichaud: yep, because I am hacking on github.com/leto/kea and I am going to start with nqp-rx, no matter what :)
Coke dukeleto: do you have permission to reject tickets at RT?
dukeleto Coke: i just wanted to resolve it 05:48
Coke: i guess not?
pmichaud so, either parrot bundles a version of nqp-rx, or all of the hll implementors end up requiring it on their own
Coke rt.perl.org/rt3/Ticket/Display.html?id=46827, e.g., is still open.
dukeleto pmichaud: yeah. which is the better solution?
Coke if you can't reject them, I can.
dukeleto Coke: i don't think I can reject them, please do if you can.
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 %" ?
pmichaud but this is an important question for libraries in general
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?
for example, let's suppose that I have a SQL library that parrot wants to bundle
dukeleto pmichaud: there is no doubt that nqp-rx will get in Parrot core. But how often will it be updated?
pmichaud does the Jun release of Parrot want to be bundling the SQL library that targets the May release? 05:51
or, if we go with "supported releases"
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?
chromatic That seems like a leading question.
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.
pmichaud dukeleto: on #perl6 you said you were concerned that nqp-rx was not targeting a released version of Parrot
er, that it depends on a non-released version of parrot
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)
pmichaud which isn't sufficient enough to support nqp's latest features
dukeleto Coke: yeah, managing all those tickets is kind of annoying. they are all about the same test file
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.
dukeleto pmichaud: i think that in the short term, nqp-rx should depend on whatever it wants
Coke dukeleto++
pmichaud then in november, when Parrot creates a bundle, it would end up using the nqp that is limited to the prior Parrot release
Coke I'll make you a bugmonger on RT. moment.
dukeleto pmichaud: i am just trying to understand how parrot should update nqp-rx
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
Coke dukeleto: or, I would have,if somone didn't delete the rt docs from docs/project...
dukeleto pmichaud: so you would be happy with parrot pulling from the nqp-rx repo each month?
Coke ah well. feel free to assign tickets that need to be deleted to me, I can close em out.
(or bug someone here.) 05:56
pmichaud dukeleto: sure, why not?
dukeleto Coke: dealing with RT right now is an enigma wrapped in a word problem
pmichaud: just verifying
pmichaud if it doesn't work out, we can go to a different policy
dukeleto pmichaud: this makes git submodules very attractive
pmichaud we just need to make sure that we're comfortable with the way it works by the January release
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
dukeleto: there's already been quite a bit of testing of nqp-rx in rakudo :)
dukeleto pmichaud: do you have any things that you need tests written for in the nqp-rx test suite?
pmichaud we've made amazing accomplishments in the past 72 hours
we can always use more tests :)
dukeleto pmichaud: that is good. I want to make sure plumage still works, too :)
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
i think that could work
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
msg bernhard hello!
purl Message for bernhard stored.
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]
dukeleto hmm
pmichaud if it were me I wouldn't use git submodules. not everyone has (or wants) git on their machine
so if pulling the parrot repo requires git, that's probably a non-starter. 06:02
dukeleto pmichaud: are we talking about developer or end-users? 06:04
pmichaud either. both. 06:05
dukeleto pmichaud: because end-users would be using a tarball
pmichaud I'm primarily thinking developers.
dukeleto pmichaud: so what I am talking about, it when parrot switches to git. we would use nqp-rx as a git submodule
s/it when/is when/
pmichaud "when parrot switches to git" isn't expected for quite some time, iiuc 06:06
as in, not before 2.6
dukeleto pmichaud: i heard not before 2.0, where did you hear 2.6?
pmichaud in one of the discussions somewhere on irc or parrotsketch
chromatic There's no particular date on it, as I understand.
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
dukeleto pmichaud: parrot will switch to git. the only question is, when?
Coke relying on git submodules probably makes as much sense as external svn modules, neh? 06:08
if we have an external dependency, just make it external.
like our perl modules. or the HLL's reliance on parrot.
dukeleto pmichaud: i keep a mirror of parrot updated every 2 hours on github: github.com/leto/parrot . Parrot exists in git, we just need to choose a time to switch the canonical repo over
Coke: yes.
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.
pmichaud: I am telling you about it. Right now. It will happen. I promise.
Coke dukeleto: ... ok. great. how does this help with nqp-rx? 06:10
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:11
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
Coke not especially, no.
dukeleto s/with/which/
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.
dukeleto: I thought I was pretty clear. Let's just make it a dependency in our toolchain. Or, we could bundle it with.
dukeleto Coke: what are these ways? I am talking about a process that is repeated on a time interval. Not a one time thing.
Coke we don't need to do any VCS magic to do either of those things.
pmichaud we're only talking about *four files*. We don't need an external linkage to make it happen.
Coke (it's not like when we bundled icu. =-) 06:14
dukeleto Coke: what do you propose instead of VCS magic? 06:15
Coke dukeleto: ... copying the files in.
dukeleto Coke: someone manually copying 4 files every month?
Coke or, making an /external/ dependency.
dukeleto: not every month.
dukeleto Coke: this wants to be synced every month
Coke why do you think we want to do it every month? it'd be "whenever something interesting happened in nqp"
dukeleto: not necessarily, no.\\
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
Coke depends on what goes in to nqp-rx.
dukeleto: they're welcome to do that, of course.
dukeleto s/requires/requiring/
Coke: yes, they are. but why not give them what they want in parrot core?
Coke: do we really want to make it harder to use parrot?
Coke dukeleto: strawman. how do you know what they want?
dukeleto: who the hell is suggesting that?
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. =-)
dukeleto: really? 'Cause I'd rather use "stable".
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.
Coke dukeleto: as I understand it, a release of nqp-rx will not rely on any particular version.
to build it, sure.
to run it? that's not the impression I got.
pmichaud to run, yes, also.
nqp-rx needs to have certain features from the PAST libraries in Parrot 06:19
those weren't present in 1.7.0
dukeleto Coke: we then invoke dependency hell, having to deal with parrot-with-nqp-rx and nqp-rx-in-the-wild
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
s/it/a copy of it/
dukeleto Coke: so you are proposing manually copying 4 files every month, again? 06:23
Coke dukeleto: not every month!
/when necessary/
yes.
dukeleto Coke: at which frequency?
Coke dukeleto: as I said before, that depends on what is happening in nqp-rx.
pmichaud dukeleto: why does it need a set frequency?
dukeleto Coke: 'when necessary' doesn't compute for me. who would decide 'when necessary'?
Coke dukeleto: ... the developers of parrot? 06:24
"oh, look, shiny. new thing."
dukeleto pmichaud: why do rakudo and parrot release monthly?
pmichaud dukeleto: why not "whenever a new version of nqp-rx is available that doesn't break too many things for parrot users" ?
Coke the same people who would decide when to update the revision pointed to in a submodule.
dukeleto pmichaud: that is not acceptable re: our deprecation policy
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
dukeleto Coke: but your plan has no definite time to take action. just "wait around" until it is "necessary" which is ambiguous
Coke dukeleto: ... kind of like our HLL developers already do with parrot? 06:26
pmichaud ambiguity is no problem
dukeleto pmichaud: we like time-based releases because they saved both projects from oblivion
Coke (except we'd be hiding this particular decision from them, so they didn't have to worry about it.)
pmichaud dukeleto: look, ubuntu does time-based releases, but they don't require their upstream modules to do the same
dukeleto pmichaud: rakudo and parrot are a bit different than ubuntu, but I appreciate your point.
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
the people who package the ubuntu release decide what versions of what components to include in that release
the same would be true for parrot
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
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...
pmichaud: everyone is excited to merge nqp-rx now. what about in a few years?
s/what I want/but I want/ 06:29
Coke dukeleto: what if nqp-rx breaks master and we're on time based includes?
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
Coke you need someone to /decide/.
dukeleto Coke: I AM THE DECIDER
Coke we can make it trivial to copy in the new files.
we can automate it more if we move to git, sure. 06:30
pmichaud nah, The Decider lives a few miles from here. :)
Coke dukeleto: then I presume you will keep on top of merging nqp-rx for some time.
chromatic If it's external, people who want a newer version can use a newer version on their own.
pmichaud since Rakudo will be heavily dependent on nqp-rx, I'm certain that *I'll* be on top of it for some time. :)
dukeleto How do we tell users of parrot which version of nqp-rx we are bundled with?
pmichaud nqp-rx is likely to have version numbers one way or another 06:31
dukeleto say it in parrot_nqp --version ?
Coke: Ahem.
Coke dukeleto: ?
pmichaud right now I'm thinking of "release.commit"
so that 1.234 would be 234 commits after release 1
dukeleto chromatic: yes. 06:32
pmichaud (since git doesn't have sequential revision numbers like svn)
dukeleto pmichaud: directed acyclic graphs aren't linear :)
pmichaud they're linear in master 06:33
particle1 use tags
dukeleto particle: welcome to the party
06:33 Zak joined
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
particle hello, and goodnight
pmichaud particle: I could use a small bit of time to chat about S19 with you
(not tonight, but sometime soon-ish) 06:34
dukeleto particle: you are always one to ruin the party ;)
particle ok, can do tomorrow
pmichaud great
that would be perfect
particle ah, the enemy of the good...
bedward &
dukeleto pmichaud: a linear graph is an example of a DAG, but the entire history of a repo is not a linear graph
pmichaud dukeleto: I don't have to keep track of the entire history 06:35
dukeleto pmichaud: touche. git does it for you :)
pmichaud all I have to do is say "how many commits in the master branch since tag 'xyz'?"
Coke -> zzz
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
and it's consistently increasing 06:37
perljam also suggested a date-based scheme, which I'm also considering. Just record an ISO date and use that.
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 :)
dukeleto needs a drink 06:40
pmichaud on migration to git, last I heard was from the 09-29 parrotsketch meeting: 06:41
19:17
Second q: On git, chromatic and I propose to table the migration discussion for now.
19:18
Util
+1
purl 1
pmichaud
19:18
allison
We can't migrate until after 2.0 or maybe even 3.0 for stability of development process anyway.
oops, sorry for copy-paste spamo
dukeleto pmichaud: yes, I remember that. "2.0 or maybe 3.0" 06:42
pmichaud: I shall get a definitive answer about which.
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.
dukeleto goes in search of $food
pmichaud: yes! duly noted ;) 06:44
dalek p-rx: 81afeca | pmichaud++ | src/Regex/P6Regex/Grammar.pm:
[p6regex]: Argument value computed incorrectly -- fixed.
 06:50
p-rx: c65b0dd | pmichaud++ | src/Regex/P6Regex/ (2 files):
Refactor p6regex's handling of argument lists.
p-rx: 218e91c | pmichaud++ | src/stage0/ (3 files):
Stage 0 files update.
p-rx: 195e47c | pmichaud++ | src/NQP/Grammar.pm:
Allow <assertion(args)> to use NQP expressions as arguments.
p-rx: a10d983 | pmichaud++ | src/stage0/ (3 files):
Update stage-0 files.
nopaste "kiwichris" at 58.172.128.7 pasted "RTEMS parrot runs, now what ?" (3 lines) at nopaste.snit.ch/18530 07:00
07:10 uniejo joined
Coke kiwichris: getting a make test run? 07:12
must zzz.
kiwichris Coke, RTEMS does not have a make. It is all cross-compiled. 07:20
07:33 fperrad joined 07:56 baest joined 07:57 iblechbot joined
dalek TT #1180 created by moritz++: examples/nci/ls.pir prints only lines with one character each 08:09
08:37 gaz joined 08:48 Zak joined 09:03 cosimo joined 09:50 Austin_away joined 10:29 ask joined 10:46 mikehh joined 11:01 mikehh joined 11:15 mokurai1 left 11:18 mikehh joined, kj joined 11:21 rob joined 11:29 Andy joined 11:34 mikehh joined 11:47 mikehh joined, krunen joined 11:51 KatrinaTheLamia joined 11:57 mikehh joined 12:21 mikehh joined 12:47 whiteknight joined 12:48 kid51 joined
whiteknight good morning #parrot 12:50
kid51 good morning whiteknight
whiteknight hello kid51, how are you today?
kid51 good; soon to go to $job 12:51
12:51 payload joined
kid51 whiteknight: At a high level, where do we stand with respect to areas like JIT? GC? Lorito? 12:51
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)?
whiteknight for both GC and JIT, we're still in planning/design stages, though we are building significant interest 12:53
12:53 masak joined
whiteknight I suspect we will have at least one in place for 2.0, yes 12:53
depends how things go
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.
kid51 Now a different question. Background first.
Coke JIT for 2.0 ? I wouldn't say that's feasible at all.
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
Since I've been working my way thru the PIR book, I'm starting to get a little facility for writing tests in PIR.
Coke cover?
purl cover is not at link?
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.
Coke coverage? 12:56
purl well, coverage is cv.perl6.cz
Coke e.g. tapir2.ro.vutbr.cz/cover/cover-resu...t-ops.html 12:57
(which has 0 coverage which is questionable)
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.
To clarify:
Coke kid51: there isn't a direct mapping.
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
And those coverage results guide the next tests I write.
Is it possible to establish such a feedback loop for the C, PIR, ops components? 13:00
13:00 plobsing joined
whiteknight kid51: I'm not sure of any good way, no 13:00
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
not always an easy task
13:02 payload joined
Coke part of the problem with that mapping is that you don't really use the opcodes in isolation. 13:05
but, as far as feedback loops: get the coverage of .ops files in that URL to reflect reality, then drive them up. 13:06
even if it's not a 1:N correspondence between file/opcode, that's still moving things in the right direction.
(also PMCS, since you can see those from PIR and invoke them.)
e.g.: 13:07
tapir2.ro.vutbr.cz/cover/cover-resu...e-pmc.html - line 223
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:08
tapir2.ro.vutbr.cz/cover/cover-resu...b-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:09
13:11 rob left
Coke mdiep++ # deleting old parrot version 13:11
( from cpan)
13:23 Andy joined 13:35 payload joined 13:53 riffraff joined 13:57 Andy joined
dalek rrot: r42218 | coke++ | trunk/t/pmc/parrotio.t:
remove reference to rejected ticket.
 14:00
14:03 Andy joined
Coke RT: 120 14:04
surely someone could copy over 5 tickets. =-)
14:22 ash_ joined
Coke coverage? 14:25
purl coverage is cv.perl6.cz
dalek TT #1181 created by coke++: make cover doesn't show coverage of *.ops files. 14:31
14:44 bubaflub joined 14:58 iblechbot joined
Coke RT? 15:05
purl rumour has it RT is just RT (bestpractical.com/rt) or (:rt3) or (: rt bugs) or Obra's trouble ticketing system or the first IBM RISC workstation (www.contrib.andrew.cmu.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
Coke parrot RT?
purl parrot RT is probably rt.perl.org or rt.perl.org/rt3/Public/Bug/Display....id=$bugnum
15:06 Andy joined
masak re 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:25
do I close the ticket? 15:27
Coke if the OP cannot duplicate the segfault, that seems reasonable. 15:28
15:30 Psyche^ joined
masak oki. 15:30
hm. I don't seem to have the privs to close it. 15:31
Coke just comment on it, the magic ticket fairy will close it. 15:32
masak :)
15:33 ash_ left
dalek TT #1134 closed by coke++: Extremely weird stack trace produced my Parrot when allocating things in a ... 15:35
whiteknight good 'ol magic ticket fairy 15:44
Coke if only he'd clean up RT for me. 15:51
dukeleto++
kid51++
Essobi heh 15:52
15:52 Essobi left
dalek rrot: r42219 | coke++ | trunk/runtime/parrot/library/Getopt/Obj.pir:
remove comment referencing rejected ticket.
 15:56
rrot: r42220 | coke++ | trunk/src/oo.c:
remove comment for rejected ticket.
 16:03
rrot: r42221 | coke++ | trunk/compilers/imcc/cfg.c:
remove comment for rejected ticket.
 16:06
Coke does the equivalent of tr/// to find out how many /'s there are in CFMX. 16:13
Coke feels a little wrong.
dalek a: a8170ec | fperrad++ | (2 files):
start to implement debug.getinfo()
 16:25
rrot: r42222 | pmichaud++ | trunk (2 files):
Fix MultiSub PMCs so that they stringify to the name

Also change the "No applicable methods" exception to be much more informative, by reporting "No applicable candidates found to dispatch to for '$subname'."		 16:33
bubaflub hey ya'll, can parrot be a target language for SWIG bindings? 16:34
maybe that's a bad question
cotto_work good morning
16:35 brooksbp joined
whiteknight good morning 16:38
bubaflub: I don't know a lot about SWIG bindings. what are the requirements?
bubaflub the idea is that i could write some SWIG interfaces to a C module 16:39
and it'll output code in a bunch of different languages for native interface
Coke swig?
purl hmmm... swig is a competitor to XS. or simplified wrapper and interface generator/bifrost.lanl.gov/~dmb/SWIG/Doc1.1/Perl5.html///www.swig.org/ or at bifrost.lanl.gov/~dmb/SWIG/Doc1.1/Perl5.html or simplified wrapper and interface generator or at www.swig.org/
Coke swig tutorial is www.swig.org/tutorial.html
bubaflub java, python, perl 5 modules, etc.
wow, that said it better than i could have 16:40
Coke so, it should be possible to generate the appropriate parrot code there.
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"
but it should be possible to add us as a swig target, if someone has already written the swig template.
16:43 frodwith joined
Coke wonders if a swig on parrot POC would be helpful. 16:43
bubaflub ah, cool. just wondering.
i thought it may be helpful getting some modules available to parrot
as there may be some stuff already out there
16:57 PerlJam joined
japhb fperrad, ping 16:59
17:00 theory joined
Coke japhb: if you could close|migrate RT# 56628, that'd be awesome. 17:01
japhb Coke, I may have lost my access info to RT, lemme see 17:02
japhb is WAY backlogged today
dukeleto 'ello 17:04
bubaflub: i was talking to a SWIG guy about just that at the gsoc conf 17:05
bubaflub dukeleto: no way.
i saw you had some work on Math::GMP::SWIG
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.
dukeleto bubaflub: we need the docs for how to add a new target langauge (PIR/PASM) to swig 17:07
bubaflub hmmmm
japhb Woah, couple few Parrot updates since Saturday
bubaflub i'll root around
dukeleto bubaflub: your mission, should you choose to accept it ...
Coke japhb: that would be awesome.
bubaflub haha. i haven't bisect'd to see where make -j fails yet, but finding docs should be easy
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 :)
bubaflub: i am pretty sure the pcc_reapply merge broke make -j, don't worry about bisecting that 17:08
bubaflub ok
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
Coke: and it was broke for me about 2 days ago, still
Coke I've been having no trouble with it. YMMV. 17:11
Coke investigates.
Coke tries a -j 20 17:12
bubaflub i think the problem may be after a make realclean 17:13
i just ran -j 4 no problem, but only a few files needed to be re-made
Coke dukeleto: works fine here. 17:15
if you find a problem, open a ticket with the build log, easy enough to fix.
dukeleto Coke: are you doing make realclean; perl Configure.pl; make -j 4 ? 17:16
Coke: it only fails after a realclean
nopaste "coke" at 72.228.52.192 pasted "how I build parrot all the time." (7 lines) at nopaste.snit.ch/18533 17:17
moritz now tries on 4 cores with -j (no limit)
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
Coke Some deps were added in the past week. More I cannot say. 17:18
I squawk loudly if I get bit by that, as I had to spend time fixing it the first time.
moritz wow, that works
dalek kudo: 74f561e | moritz++ | src/setting/Complex.pm:
call .perl on $.re and $.im in Complex.perl
Coke moritz: what works?
moritz Coke: building with -j after realclean
Coke moritz: why wouldn't it?
oh, because of aforementioned bug?
moritz eys
*yes 17:19
or because of resource limits :-)
Coke I remember the dark times, when Configure.pl said, "dont' use -j"
stupid dark times.
dukeleto Coke: you must not have noticed, because it was broke since the pcc_reapply merge until recently
moritz dukeleto: no
it was fixed pretty soon after the merge
maybe it broke again, and was fixed again
dukeleto bubaflub: wasn't it broke for you, just a few days ago? 17:20
moritz iirc
dukeleto moritz: sinusoidal bugs!
Coke in any case, if it's failing, open a ticket.
moritz real 0m1.255s for make -j
dukeleto Coke: tickets welcome! check.
moritz and user 0m3.544s
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
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++ ;)
Coke aha. found a bug. -j20 worked, -j failed. checking...
dalek rrot: r42223 | japhb++ | trunk/config/auto/opengl.pm:
[OpenGL] Document Cygwin native v. X conflicts to resolve RT 56628
bubaflub bahaha. roger wilco
dukeleto Coke: THE HORRORS
Coke (finding bugs is a crapshoot with -j)
"make clean;make src/oo.o" 17:23
whiteknight Coke: that causes a problem? 17:24
japhb Coke, RT #56628 now resolved. Is that the only RT that was assigned to me? 17:26
Coke whiteknight: yes. it depends on .h files that don't exist. 17:27
whiteknight oh, hotness
Coke not to mention the .str file.
fixed.
dukeleto: let me know if you can find another failure.
(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
(did I mention boring?)
bubaflub ooooh i'm bored!
actually, i'm at work, working on parrot 17:29
which is a great way to get paid to work on parrot
also a great way to get fired
dalek rrot: r42224 | coke++ | trunk/config/gen/makefiles/root.in:
Fix dependencies for src/oo.c
Coke I think ideally we'd want a 'make depend' target that detected these things and made sure they were in the makefile.
Coke japhb: if you close the ticket, be sure to cc the list.
dukeleto Coke: we could write a test for that
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.
dukeleto Coke: the test that gets you tarred and feathered if you break it on trunk
Coke some things are just easier to fix after the fact.
(but yes, if it magically appeared, that'd be nice. =-)
17:32 Patterner joined
Coke japhb++ # closing tickets. 17:33
(note, that's plural! do another to earn that karma!) 17:34
japhb Coke, I'm actively trying to right now. :-) 17:35
Coke, did you do the CC, or should I go back and do so?
dalek tracwiki: v114 | jkeenan++ | WikiStart 17:36
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
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.
japhb Coke, is there some link or button that does that, or do I now need to copy & paste?
Coke Just reply to your comment. 17:39
with a note "cc'ing final response to list" or some such. 17:40
japhb Coke, done 17:42
Coke japhb++
whiteknight kid51: ping 17:45
Coke whiteknight: he's at work all day. 17:46
17:47 solarion joined
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.
Coke whiteknight: I wouldn't reject that. 17:48
having a config.log to post for tickets would be nice.
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:49
that's why I'm asking kid51: If anybody is actually interested in implementing it, good. 17:50
Coke just like JIT?
nice to have, but...
(yes, that's not exactly a 1:1 mapping) 17:51
but "no one is interested in writing it now" is not a valid reason to delete a ticket.
17:53 brooksbp joined
whiteknight Coke: RT #40438, you're doing this right now in partcl, right? 17:54
(adding PIR methods to a dynpmc)
dalek rrot-plumage: 07852ee | japhb++ | :
[CORE] Util.nqp: Apply modified patch from fperrad++ implementing PATHEX...
 17:57
japhb What's the current status of NCI thunk building? 17:58
I've got a new ticket and an old one that both want 'long long' or 'unsigned long long' support. 17:59
whiteknight japhb: no support just yet 18:01
Coke whiteknight: yes, I'm doing that now. 18:02
18:02 chromatic joined
Coke having a test in core would be spif. 18:02
(but that can go on some sort of "testing tasks" page.)
japhb whiteknight, darn.
dalek rrot: r42225 | whiteknight++ | trunk/src/pmc/default.pmc:
[pmc] remove some unneeded code that's been commented out for a while. Resolves RT 46659
 18:03
japhb Coke, RT 53406 can be moved to Trac. I'm not sure what your process there is. 18:04
dalek rrot: r42226 | japhb++ | trunk/config/gen/opengl.pm:
[OpenGL] Applied patch from fperrad++ to fix TT #1167
 18:13
Coke japhb: lists.parrot.org/pipermail/parrot-d...03154.html 18:14
dalek TT #1167 closed by japhb++: some new types not handled by gen::opengl step 18:15
japhb What is the proper TT 'Component' for NCI stuff? 18:20
dalek rrot: r42227 | pmichaud++ | trunk (2 files):
[p6object]: Add .WHO and .WHERE methods, with tests.
Coke japhb: when in doubt, other.
japhb There's no 'other' in the list 18:21
Coke checking...
none is the new other. 18:22
japhb Coke: OK, thanks
OK, RT #53406 -> TT#1182 18:24
dalek TT #1182 created by japhb++: [TODO] Add 'long long' to types supported by NCI 18:25
18:26 brooksbp joined
Coke japhb++ 18:27
18:27 darbelo joined
darbelo Ohhh. Eventful weekend. 18:31
Leave you guys alone for a bit, and I get a broken make -j and test failures. 18:33
dalek p-rx: e478a58 | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION so we get P6object .WHO and .WHERE.
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.
Coke darbelo: ok. (I just fixed one of these moments ago.)
darbelo I just added pmc/pmc_context.h to the deps for scheduler.$(O) and it's building fine. 18:36
Coke darbelo++
darbelo I'll try with higher -j values before committing 18:37
Coke is scheduler a src file?
(or a pmc?) 18:38
(just do make clean; make path/to/scheduler.o) to test.
(I suppose make -j path/to/scheduler.o is better.) 18:40
dalek rrot-linear-algebra: 1a03b3b | Whiteknight++ | src/pmc/nummatrix2d.pmc:
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
darbelo Coke: That doesn't find problems in other files :) 18:47
chromatic A short Perl program could look at the #include files in our .c files and compare them to the Makefile dependencies. 18:49
18:49 allison joined
darbelo Okay, it survived a -dp run, commit is on the way. 18:51
dalek rrot: r42228 | darbelo++ | trunk/config/gen/makefiles/root.in:
Adjust the dependencies of $(SRC_DIR)/scheduler$(O) in order to fix BSD make parallel builds.
 18:54
Coke is bit by a svn bug from 1.x 18:55
(non parrot repo)
18:55 brooksbp joined 18:56 mikehh joined
dalek TT #1183 created by bubaflub++: dies_ok() for Test::More 19:03
cotto_work chromatic, Andy was working on something like that at some point. 19:07
chromatic I thought he was using a special make flag. 19:09
dalek TT #1184 created by bubaflub++: [PATCH] fix trailing white space on src/pmc/multisub.pmc 19:10
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
I would like to see that class of errors eliminated.
darbelo And, while we're asking for poinies, we should eliminate the sub-makefiles. 19:13
19:14 mikehh joined
Coke darbelo: you can have #1184. =-) 19:15
darbelo Trac?
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. projects.edgewall.com/trac/ or Python, SQLite and ClearSilver or killing killtrac or a bug-tracking tool or at trac.parrot.org/parrot/ or slow or REALLY slow
cotto_work Andy, whatever happened with that project?
seen andy
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]
Andy which
cotto_work the makedep replacement for parrot
Coke darbelo: yes
Andy oh, heck
I don't even remember
darbelo fix trailing white space on src/pmc/multisub.pmc? 19:16
cotto_work darbelo, do you think you're up for it?
darbelo I son't know, cotto_work, it sounds like it needs skills I don't have. 19:17
cotto_work There's deep magic in that whitespace. 19:18
Coke cotto_work: you own RT #36407 and RT#48439, btw.
cotto_work looks
Coke please to be the transferance.
cotto_work please to the English yes? 19:19
dukeleto darbelo: wanna apply trac.parrot.org/parrot/ticket/1184 ?
Coke dukeleto: welcome to 4 minutes ago. =-)
darbelo dukeleto: doin' it now.
Coke cotto_work: translationparty says "Please forward full ticket."
dukeleto yay, fulltest rejoices 19:20
that will be two accepted patches for bubaflub++, so he can ask for a commit bit then, right?
dalek rrot-linear-algebra: a33c53a | Whiteknight++ | README:
Updated README with current status and information that I now know
 19:21
darbelo dukeleto: I have no idea. I was forced to get a bit ;)
dalek, you up? 19:24
Coke msg jonathan rt.perl.org/rt3/Ticket/Display.html?id=46687 seems to be yours. If you could move it over to trac or reject it, that would be spif.
purl Message for jonathan stored.
dukeleto darbelo: dalek hates me
Coke msg jonathan (or resolve it, even!)
purl Message for jonathan stored.
Coke darbelo: he takes his time. no worries.
dalek rrot: r42229 | darbelo++ | trunk/src/pmc/multisub.pmc:
Fix trailing white space on src/pmc/multisub.pmc
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 ?
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
pmichaud Coke: =-) 19:30
dukeleto darbelo: i meant to say, the bug has been fixed and reappeared, a few times, even
pmichaud that always gets a huuuuuge laugh when I pull it up. It also eats up valuable lightning talk time.
19:37 mikehh joined
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
(my hand-written PIR, that is)
chromatic Show me an example and you'll get it. 19:43
19:44 joeri joined
Coke pmichaud: www.wall.org/~lewis/ huh. 19:50
(mentions rakudo)
dalek TT #1185 created by bubaflub++: [PATCH] attempted to rewrite t/op/00ff-dos.t in PIR 19:51
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
dukeleto darbelo: yes. Can we make sure to shuffle deps properly from now on? 19:53
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.
Coke chromatic: I try to key off those.
(hard on big mergebacks)
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.
dukeleto also, every branch should allow "make -j" before being merged
darbelo: all commits to trunk should pass "make fulltest"
darbelo dukeleto: Don't hold your beath. 19:57
dalek rrot-linear-algebra: c42f643 | Whiteknight++ | src/pmc/nummatrix2d.pmc:
add comments to NumMatrix2D METHODs, and add a quick sanity check to the initialization method
rrot-linear-algebra: bbb9d00 | Whiteknight++ | src/pmc/nummatrix2d.pmc:
add methods to get and set blocks. This will help in partitioning algorithms and, eventually, autothreading
TT #1186 created by bubaflub++: [PATCH] convert t/op/00ff-unix.t to PIR 19:58
whiteknight bubaflub++
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
whiteknight you get nominated, at #ps we vot
dukeleto then you submit the CLA and then you get a bit 20:00
whiteknight right, CLA
chromatic Two contributions is for PaFo *membership*.
Commit bit policy is submit enough good patches that someone is sick of committing them for you.
darbelo Hmm. I wonder if giving plobsing one would speed up the libjit work.
dukeleto darbelo: the JIT work or the libjit work? 20:01
moritz it would simplify things
dukeleto are we still planning on supporting libjit and llvm? Because I need to tell you all, that is a really bad idea.
whiteknight dukeleto: I'm not convinced of the doom and gloom 20:02
I certainly see no problem supporting two frame builders
darbelo dukeleto: Really? Sounds like what a llvm dev would say :)
Coke whiteknight: split resource allocation.
dukeleto whiteknight: what is the difference between 2 frame builders and supporting 2 JIT backends?
chromatic Writing a *good* JIT backend is a lot of work.
Coke increases complexity and support costs. 20:03
chromatic Writing a decent framebuilder is not.
whiteknight Coke: I don't think so, split resource allocation means there are people who would work on both
Coke whiteknight: if someone hands us one of each, sure.
if we are trying to come up with a plan for limited resources, that's where my concern comes in.
whiteknight I, for instance, will probably only work on the LLVM version
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.
whiteknight but if there's another developer who is only interested in working on libjit, that's their prerogative
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.
whiteknight you guys with the worrying! We already have a concrete plan spelled out
we're doing LLVM first
that's the plan
we do LLVM first
dukeleto whiteknight: I like that plan!
whiteknight then memorize it!
and don't worry about other things! 20:05
dukeleto jit?
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-)
Coke dukeleto: now we just need to make sure we stop after that point. =-)
darbelo dukeleto: llvm only leaves platforms out.
dukeleto darbelo: which platforms?
purl which platforms are 8.3 an issue on, anyway?
darbelo OpenBSD, all arches.
whiteknight there are motivations for LLVM to expand to more platforms
we can help push that 20:06
dukeleto whiteknight: does trac.parrot.org/parrot/wiki/JITRewrite say that we are doing LLVM first? I don't see that spelled out.
darbelo: so llvm does not support OpenBSD. Good to know. Anything else?
whiteknight dukeleto: allison made the announcement on the list
(I should spell it out on the wiki though, that's true)
dukeleto whiteknight: you expect me to read my email? ;)
whiteknight I read email, and I don't read the wiki 20:07
:)
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
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? openports.se/devel/llvm
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 ;)
nopaste "pmichaud" at 72.181.176.220 pasted "vivify opcode patch (for review by chromatic)" (87 lines) at nopaste.snit.ch/18535 20:12
chromatic How is that different from existing, pmichaud?
pmichaud + VTABLE_set_pmc_keyed(interp, $2, $3, $1); 20:13
on each case
whiteknight pmichaud: what does the :base_core flag do?
dukeleto whiteknight: all your base core are belong to parrot
chromatic Oh, I thought that was fetch, for some reason.
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
pmichaud vivify looks a lot like fetch, it just has the extra bind at the end
whiteknight do we need fetch and vivify?
pmichaud I do
whiteknight okay
(just making sure)
pmichaud I have a case where I'm writing code and it turns 14 lines of PIR into 2
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.
darbelo dukeleto: If supported platforms are measured by active developers you can take windows off that list.
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 :)
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 ;)
darbelo: that is interesting
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:18
allison pmichaud: vivify looks very language-specific in its behavior 20:21
pmichaud allison: it's not 20:22
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"
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?
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?
pmichaud allison: sure, but to do it in PIR is a sequence of about 5 opcodes
actually, 6
and I end up writing it *a lot* 20:24
(by hand, not just generated code)
darbelo The name is rather perlish, but I think it is a generally useful feature.
allison pmichaud: the part that looks interesting is specifying the type of the autovivify
pmichaud allison: right
that's the most useful part
allison pmichaud: (as opposed to always PMCNULL or Undef)
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?
pmichaud but no, I don't see it as being very perl specific. In fact, Rakudo won't be using this opcode at all.
allison get_pmc_keyed_typed, or something like that, with an extra argument
pmichaud that's "fetch"
we have two opcode
fetch is "get a pmc, if it doesn't exist, give me one of this type"
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
basically fetch is rvalue lookup
allison is there a single datatype that needs to be able to do both?
pmichaud vivify is lvalue lookup
...single datatype? 20:27
allison a PMC
pmichaud I'll be using this all over the place, quite honestly
namespaces, hashes, arrays, lexpads, etc.
it's not specific to a type
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
the PMC can't know the conetxt unless we tell it
allison what factors does it depend on?
chromatic the lvalue/rvalueness of the expression
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
pmichaud except that set and get don't vivify
right now I have to go through a sequence of
allison not for the PMCs we have now, but they could
pmichaud $P0 = get agg[key]
unless null $P0 goto done
$P0 = new ['XYZ'] 20:30
agg[key] = $P0
done
s/get//
allison right, the only part of that we don't have now is the ability to specify what 'XYZ' is
pmichaud set doesn't vivify, it binds
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?
pmichaud just writing those long sets of instructions over and over 20:32
I'm saying that 'set' is not really 'lvalue context'
allison so, I'm suggesting $P0 = get agg[key], ['XYZ']
pmichaud why is that any different than $P0 = fetch agg, key, ['XYZ'] # which is what we have now
allison where the second arg is "type to fetch/vivify"
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
pmichaud you're adding a new opcode with 'get' 20:33
allison oh, sorry, cut and paste error
$P0 = agg[key], ['XYZ']
pmichaud okay, that binds the new object, or doesn't?
and whether it does, how do I get to the other form? 20:34
allison PMC chooses
pmichaud how can the PMC know?
Coke
allison you said it was lvalue/rvalue that determines, yes?
chromatic Isn't that adding a new opcode?
pmichaud yes but lvalue and rvalue are determined by context of the operation, not by the PMC
not by the aggregate PMC
if I'm writing 20:35
allison chromatic: it's adding an option to an existing opcode
pmichaud $a = @xyz[3]
that's rvalue context
if I'm writing
@xyz[3] = $a
that's lvalue context
the aggregate is the same in both cases (@a)
dukeleto If a PMC's VTABLE is called in the woods, and no one is there, does it make a sound?
pmichaud thus the aggregate cannot know which operation to perform
(sorry, @xyz in example above) 20:36
allison pmichaud: well, a = xyz[3] and xyz[3] = a are different operations in PIR too
pmichaud no no no
allison pmichaud: are you saying that you're using some other combination of operations to represent the high-level assignment?
pmichaud well, yes yes yes, if you mean that we need two opcode for this
allison I'm saying we have two operations for this already
pmichaud allison: please note that $P0[key] = $P1 is *not* assignment
it's not not not 20:37
allison remember, = isn't an operator in PIR
pmichaud fine
set $P0[key], $P1 is *not* an assignment
allison it's just syntactic sugar for completely different opcodes
pmichaud chromatic, coke, can someone help me out here, please?
allison I'm definitely not getting what you're driving at
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.
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
Coke and then allison can (perhaps) show you how you can simplify that without changing PIR.
chromatic I don't understand how to do this *without* adding an opcode.
allison chromatic: I'm trying to figure out what patrick wants
Coke there was a post to the mailing list. digging.
pmichaud I want a way to represent lvalue semantics in PIR
chromatic It's two high-level operations.
pmichaud set $P0[key], $P1 is not lvalue semantics
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."
"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."
allison set is PMC-determined semantics, it's variable
pmichaud (writing example sequence that Coke suggested0
Coke (list) perhaps not.
pmichaud++
pmichaud allison: I want to do this on our existing PMCs
Hash. ResizablePMCArray. NameSpace. 20:40
chromatic I don't want to modify every existing aggregate and every possible existing aggregate.
allison but those explicitly don't use those semantics
chromatic The PMCs don't have to use those semantics. Their existing set/fetch semantics are fine.
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?"
pmichaud just a sec, the example should make it clear
Coke allison: it doesn't force the pmc to autovivify.
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"
chromatic: (and whether to store that return)
whiteknight allison: autovivification seems to me like it's the particular assignment operation, and not something that the PMC should or should not support
chromatic And that doesn't always work for PIR programs.
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.
allison whiteknight: it's the semantics of the data type, part of the defined API of the PMC
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.
nopaste "pmichaud" at 72.181.176.220 pasted "example use of vivify opcode" (24 lines) at nopaste.snit.ch/18536
20:44 davidfetter joined
chromatic Suppose I want a Ruby-style hash which supports a default value. 20:44
allison but, putting that behavior in an external opcode means we dictate autovivification semantics for all languages and all PMC types 20:45
we've been bitten by that enough times to learn not to repeat it
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.
pmichaud I'm not asking to replace our existing set opcode.
jonathan allison: Huh? We're supplying an additional opcode that a language can use to say who something from an aggregate autovivifies.
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/
allison ResizablePMCArray was intentionally created not to autovifify like that
Coke (which we'd need to implement with more opcodes)
whiteknight more vtables does sound to me like the solution here, although I generally advocate having fewer of them
chromatic Why would we need more vtables?
jonathan allison: Which is good - because then we can actually use it with langauges that have different auto-vivification semantics/interests.
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"
chromatic Okay.
allison whiteknight: yes, that's more what I'm leaning toward
chromatic I'm declaring a moratorium on discussion from everyone who hasn't read the patches.
jonathan allison: But the op has an argument saying what to auto-vivify to.
solarion QUESTION: could there be some sort of reward system for ubuntu devs and MoTUs to encrouage bug-fixing?
sorry; w/c
allison chromatic: I read the vivify experimental op patch, are there others?
chromatic There's a fetch opcode in experimental.ops. 20:48
solarion allison: thanks for the book, btw
(_Parrot_Developer's_Guide_) 20:49
allison solarion: glad you found it useful
chromatic: yup, fetch should be get_pmc_keyed_typed 20:51
pmichaud and the opcode to access the vtable...?
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
pmichaud allison: what variant of set, please?
allison pmichaud: set_p_p_p_p
pmichaud please give full example 20:54
allison get_p_p_p_p
pmichaud there needs to be a key there
allison (was looking at vivify by that point)
pmichaud please give me a full set opcode involving $P0 (result), agg, key, and type
e.g. set $P0, agg[key], type
or
set $P0, agg, key, type
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
allison comparing to existing get opcodes 20:56
pmichaud there are no "get" opcodes
it's all "set"
fwiw, it would probably live with just having an rvalue form of set $P0, agg[key], type 20:57
s/it/I/
because then I would end up writing 20:58
set $P0, agg[key], type
set agg[key], $P0
whenever I need my lvalue semantics
(which seems a bit wasteful... but what can you do?)
20:59 brooksbp joined
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.
pmichaud when I'm doing an rvalue lookup 21:00
in high level code
allison Coke: which is why the core types are simple, so they're friendly everywhere
Coke allison: they're not simple.
pmichaud my $a = @xyz{'foo'}[5][7]
Coke see also the array issue. =-)
allison Coke: well, they avoid things like autovivification intentionally
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
but it shouldn't vivify them in the process
in the sense of putting them into the aggregate
Coke (e.g. calling 'push' on something that does 'array' is not safe.)
(but that's another argument.)
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
pmichaud no, which is why I've been wanting two different opcode
purl okay, pmichaud.
pmichaud *opcodes
one for lvalue context, one for rvalue context
but if I can't have that, then please give me the rvalue one
allison wouldn't you use set agg[key], $P0, type for the second instead? 21:03
(those are two different opcodes)
jonathan That'd be binding rather than assignment though, no?
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
pmichaud if there's also a set agg[key], $P0, type form, that's fine
but the problem with that is that it's $P0 that gets modified
allison pmichaud: my point is, adding typing is a nice feature, but adding new opcode (names) is unnecessary complexity
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?
pmichaud japhb: I don't have much time, please don't tangent yet
Coke allison: adding another variant called 'set' is ok?
japhb pmichaud, roger that
Coke I don't think pmichaud cares what the opcode is named.
allison japhb: (briefly) different languages have very different semantics for autovivification
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?
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
allison: because when I'm done, I want the aggregate and the rvalue to be pointing to different PMCs 21:07
@xyz{'foo'}[5][7] = $a; $a = 6; # should not change the @xyz... value
in other words, with
allison to be clear, the aggregate is @xyz and the rvalue is $a?
pmichaud right
in other words...
purl in other words are there good use cases where you'd choose not to use that module
pmichaud let's bring it down to the single aggregate case
highlevel, I want to do 21:08
@xyz[3] = $a
allison but, you just assigned to an aggregate, it should change the value
pmichaud that does *not* mean
please, let me finish
allison yes
pmichaud @xyz[3] = $a
that does *not* translate to
$P0 = find_lex '$a'
set xyz[3], $P0, ['Undef']
the correct translation is 21:09
$P0 = find_lex '$a'
set xyz[3], $P1, ['Undef']
assign $P0, $P1
allison ?
pmichaud if we have 21:10
set xyz[3], $P0, ['Undef']
when does the ['Undef'] ever come into play?
more to the point, with @xyz[3] = $a
the end result is that xyz[3] and $a have to refer to different PMCs 21:11
allison which different PMCs?
pmichaud the one tha tholds the value for $a and the one that holds the value for xyz[3]
otherwise
$a++
ends up changing the value of xyz[3]
(if they refer to the same PMC)
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.
and assign != set
set has binding semantics, not assignment semantics, at least for the built-in PMC types
and the libraries I'm writing tend to want to use the built-in PMC types 21:13
(because that's all we can guarantee to be available at runtime)
allison assign $P0, xyz[3], ['Undef'] 21:14
chromatic I can't see how that is clearer than fetch or vivify.
pmichaud that looks a lot to me like "vivify" :-)
chromatic It could be fetch.
Coke allison: that opcode doesn't exist.
chromatic You have to read the opcode body to know whether it fetches or vivifies.
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']
and vivify is assign $P0, xyz[3], ['Undef']
allison chromatic: the op shouldn't do either, it should call a vtable function
chromatic A vtable function for this is wrong.
This is *not* the responsibility of the vtable.
japhb allison, But 'fetch' and 'vivify' at least say what they mean, rather than a magic variant of 'assign' that isn't clear.
pmichaud but this is the crux of what I've been complaining about for two years
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
jonathan allison: This is wrong.
chromatic PMC's should *not* override this.
That is the wrong direction.
allison autovivification is a language feature
jonathan allison: This is an area where languages want to operate on other data types.
chromatic PMC's already *can* give themselves vivify or fetch semantics using the existing vtables.
jonathan And have the semantics of the *language*.
allison chromatic: yes, that's my point
chromatic Yes, and that's why you're wrong.
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
Thus it does not belong in the PMC.
allison chromatic: the one thing they can't do is specify a type for the autovivification
chromatic That's the whole point, allison.
japhb jonathan is correct. Cross-HLL, you want the semantics of the *calling* code, not the *called* PMC.
chromatic If this goes into the vtables and not into the ops, this behavior is *unusable* from PIR.
It's unsafe and unreliable.
allison japhb: if that's the case then this is a Perl6 op, not a Parrot op
chromatic You can't know the semantics of the operation unless you know the exact type of every aggregate used in these expressions.
This *does not work* callee-side. 21:18
japhb allison, No, because what I said is correct across any two languages.
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
any op we provide is going to demand a particular interface that all our aggregate types need to satisfy
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.
chromatic That's why I said everyone should *read* the existing fetch op's implementation.
NotFound whiteknight: or not. They can throw on anything they don't spport.
Coke (I am not advocating this, mind you, justing pointing it out.)
allison what these ops do is allow you to force autovivification semantics on any aggregate PMC
pmichaud no they don't
whiteknight jonathan: we already have tons of inconsistency in the way various VTABLEs are implemented
pmichaud the aggregate still enforces the set
allison I can understand why that might be appealing, but it's not right
Coke I would say they allow you to /use/ autoviv, not /force/ it.
chromatic the aggregate still enforces the get
The aggregate's existing behavior is preserved and respected. 21:21
That goes for all aggregates as they exist now.
whiteknight we would need at least a deprecation cycle to get all aggregate VTABLEs set up to uniformly do what we want
chromatic That goes for all aggregates that may exist in the future.
allison not with vivify, it's not
chromatic That goes for all dynpmcs anyone might eventually create that we may never know about.
pmichaud allison: even with vivify, it goes through the aggregate's set_*_pmc vtables
NotFound allison: if we don't provide an op, the only difference is that the operation require several ops.
pmichaud NotFound +1
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
allison NotFound: true enough, but if you provide an overridable interface the language can decide how to handle that request
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.
allison it's better than a fixed opcode
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
chromatic It's *unusable* if it's PMC-side.
Coke (long
ww
allison Coke: quite a bit of language behavior is built into the PMCs, that's the point
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.
Coke allison: yes, but there needs to be a boundary. as it is, I despair of having useful interaction across HLLs.
allison NotFound: yes, but different languages have different object semantics
Okay, take a step back 21:24
pmichaud allison: let's do this
here's my example:
@xyz[3] = $a; $a++
how would you write that in PIR ?
keeping in mind that $a and @xyz[3] need to have different values at the end
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
chromatic That does not change with fetch/vivify. 21:26
allison set xyz[3], a; inc a
pmichaud allison: that changes xyz[3], if a is a PMC
(which most lexicals are)
allison chromatic: it does change, because you're putting aggregate semantics into an opcode
chromatic: they're carefully designed to have no semantics in opcodes, only semantics in vtable functions
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
chromatic Okay, then forget the whole thing.
pmichaud then I end up with 6
and xyz[3] should be 5
please try again
chromatic I can't answer the "aggregate semantics" argument.
I can't refute the "opcodes are short" argument.
allison pmichaud: hold on, I'll split that out so I can look it over...
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
It's obviously necessary code. It's obviously correct semantics and behavior.
(argument from existence)
allison pmichaud: so, you're fetching the value from the aggregate after you create it?
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
chromatic The only conclusion is that this is behavior Parrot won't support.
pmichaud allison: isn't that normal?
@xyz[3] = $a; $a++; print @xyz[3]
whiteknight the alternative is to have a dynpmc lib
pmichaud I expect the value of $a before it was incremented
21:29 hercynium joined
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?
pmichaud but set xyz[3], a; inc a; doesn't do that
Coke allison: that isn't a in his print. 21:30
pmichaud oh please come on
allison I'm really just trying to understand here
pmichaud allison: okay, I'll spell it out
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
it's broken in assignment
here's the spelled out version
allison probably so, but I haven't been able to make sense of it yet
pmichaud HLL: my $a = 5; @xyz[3] = $a; $a++; print @xyz[3]
PIR (wrong): a = box 5; xyz[3] = a; inc a; $P0 = xyz[3]; print $P0
it's wrong because it will print out 6, not 5
whereas the HLL expects 5 21:32
I have to go pick up kids, back later
(please give me an alternate form of PIR that will work)
Coke with the existing sytem there, I'd expect to have to clone a there.
(and yes that won't work for := - but then you wouldn't use clone.)
NotFound I don't think that's wrong. Is expected in types by reference.
allison pmichaud: (sorry, have to split the code out on lines to read it)
chromatic That's a rabbit trail related to the use of these ops.
I mean UNrelated. 21:33
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.
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
chromatic I didn't add fetch to get around something that's fundamentally broken. 21:34
I added fetch to compress a common case of six opcodes in PIR into one.
I did not modify a single PMC to do so.
I did not change the semantics of a single PMC.
jonathan Right, and vivify is the same story.
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.
allison we're trying to reduce our opcode set, adding new opcodes to handle what could be done in an optimization pass is... suboptimal
Coke we're trying to reduce our opcode set?
chromatic How in the world would you do this in an optimization pass?
allison Coke: radically, yes
Coke allison: can I snark for a second? =-)
allison chromatic: it's a common pattern, like tail recursion 21:36
Coke: why not, join the club :)
chromatic Specifics, please.
How do you optimize this?
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
(using a refetch)
NotFound: it's not an opcode to be used by the optimization phase though, it is the optimization
chromatic *What* is the optimization? 21:38
jonathan allison: Where did $P0 come from in that?
NotFound allison: we have a tailcall opcode
allison jonathan: sorry, print a
pmichaud I did not mean print a
I meant the hll form of print @xyz[3]
jonathan allison: No, he didn't.
21:38 masak joined
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.
allison for either?
Coke allison: see "PIR (wrong)"
pmichaud Coke: clone semantics bring up other problems
allison ah, you're saying the P6 = is a copy, not binding? 21:40
jonathan allison: The HLL example should print 5..
Coke pmichaud: what other problems?
(ISTR I'm using this in tcl now to address pretty much the same issue.)
(clone)
allison losing the thread
fetch?
purl fetch is "get a pmc, if it doesn't exist, give me one of this type"
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
i.e., sometimes we have multiple symbols bound to the same PMC
allison ah, right, opcodes as optimizations...
Coke pmichaud: why would you use clone if you had a bind operator in the HLL?
I'm only suggesting it for p6 =, not p6 := 21:42
pmichaud Coke: the point is, sometimes we ahve both.
and if assignment is really "rebind to a clone", we lose the original bindings from other symbols
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)
Coke pmichaud: ok. I think I get it. I have no idea how you'd solve that in PIR, new opcodes or not. =-) 21:43
allison pmichaud: is that different than using assign vs. set? 21:44
pmichaud yes
allison (maybe set should be called bind, to be clear)
pmichaud because there is no "assign to a aggregate element" opcode
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
pmichaud huh?
I should always be able to bind any symbol to any PMC
21:45 calculus joined
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?
oh, no, I see
pmichaud in a HLL @xyz[3] = $a is NOT A BINDING!
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.
allison pmichaud: is that true in Perl 5 too?
or, new to Perl 6?
NotFound They containt INTVAL, not Integer
pmichaud oh please
allison I thought things stored in arrays in Perl 5 were references 21:47
pmichaud no
no no no
they are not
allison (admittedly, it's been something like 3 years since I wrote much Perl 5 code)
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";'
5
it has *always* been this way
21:48 mokurai joined
pmichaud afk for abit, another kid to pick up 21:49
allison interesting
doesn't that get expensive?
I suppose it means Rakudo must be using assign everywhere instead of set
jonathan *sigh* 21:50
No, we use the copy op. 21:51
21:51 ash_ joined
allison chromatic: source code optimizations like that are usually "check for pattern, replace pattern x with behavior y" 21:51
chromatic: though that does get into partial jitting 21:52
darbelo allison: a peephole optimizer?
allison chromatic: which is pretty advanced
darbelo: aye, essentially
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:54
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?
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.
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.
... assuming you find hllmacros easier to read.
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.
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
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.
allison chromatic: and you can do it once for everyone, instead of putting it off in a separate op
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.
allison chromatic: that purpose could be served without a new opcode too
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.
allison PerlJam: working on it, yes
yes, I hate fake ops 22:02
chromatic That leaves a macro.
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
allison the macro seems silly too
chromatic What's left then?
darbelo PerlJam: python -c "a = 5; b = [ a ]; a += 1 ; print b[0]" 22:03
allison set $P0, agg[3], type
PerlJam darbelo: thanks. my python is completely rusted :)
chromatic I find that very unclear.
allison darbelo: b = [ a ]? 22:04
japhb The names matter. 'fetch' and 'vivify' actually mean something.
PerlJam darbelo: I don't think the b = [ a ] part is quite the same
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.
allison there's a principle of distinction here
chromatic You mean "different behaviors have different names"?
japhb allison, it's the small but critical differences that you want to highlight. 22:06
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:07
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
(with a little extra to handle the lack of autovivification)
chromatic: aye, and behaviours that are only tiny modifications on existing behaviors don't have different names 22:09
If this were an HLL, I'd probably go for something more like $P0 = agg[3] :default('Undef') 22:10
but, PIR is a primitive language
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
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
japhb 'disagree with that' referring to tiny mods don't have different names
allison yes, distinction and reuse are balanced principles
we're weighing the balance here
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.
chromatic I'm open to a better name for 'fetch'. That better name is not 'set'.
japhb And I will grant chromatic's point, but I don't know of a better one.
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.
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*
chromatic reify has the connotation of bringing something abstract into existence
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
allison japhb: yes
japhb chromatic, Ah, I thought of it as "making the abstract real", an act of conversion instead of creation or birth.
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
japhb I guess that's why you said it was less clear. :-)
darbelo japhb: Verdinglichung ;) 22:17
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.
japhb darbelo, out of curiosity, what is the literal translation of that? (As opposed to "it means reify")
chromatic vivify is fetch + store
pmichaud vivify is:
$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
pmichaud set agg[key] = $P0
moritz ding = thing
pmichaud er
I'll redo
vivify is
chromatic Unnecessary anthropomorphism is usually less clear.
moritz verdinglichung = "the processing of making a thing of something"
pmichaud $P0 = fetch agg, key, ['Undef']
set agg[key], $P0
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
so vivify is really more like
$I0 = exists agg[key]
$P0 = fetch agg, key, ['Undef']
if $I0 goto label
set agg[key], $P0
label:
allison and what HLL code do you translate to vivify? versus what HLL code do you translate to fetch?
pmichaud @agg[key] = 3; # vivify 22:21
chromatic Why does that matter?
pmichaud $a = @agg[key]; # fetch
allison chromatic: trying to figure out the use
pmichaud we use vivify when we have an lvalue semantic. we use fetch when it's an rvalue semantic
more specifically
@agg[key]{'foo'}[bar] = 3; # vivifies all of @agg[key], @agg[key]{'foo'}, and @agg[key]{'foo'}[bar] 22:22
$a = @agg[key]{'foo'}[bar]; # doesn't vivify any of them
allison pmichaud: on @agg[key] = 3; # vivify... that doesn't translate to set_integer_keyed?
pmichaud okay, $b then
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.
pmichaud but no, it's not set_integer_keyed 22:23
because set_integer_keyed does a rebind instead of an assignment
allison well, not with an integer constant
pmichaud yes, with an integer constant
please go look at the CODE
allison but with @agg[key] = $a, yes
pmichaud with set agg[key], 3 # creates a new PMC, binds agg[key] to it
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
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
pmichaud my point is that it broke the binding
allison PMCs have to allow different semantics for different languages 22:26
pmichaud set $P0, agg[key]
store_lex '$b', $P0
agg[key] = 3; # oops, $b is not 3
(this being a HLL binding, not assignment -- i.e., $b := agg[key] )
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
if you say "you should have custom PMCs", I really don't want to do that for PGE, NQP, PCT, etc.
allison that was the design decision that was made for the semantics of those PMCs, yes, but it's not required for all PMCs
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
I mean, not even the basic semantics
at least, not without jumping through lots of hoops
allison I guess the question there is who the target user is for those core PMCs
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
more than that...
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
pmichaud so an HLL gets to choose one, and then figure out how to work around things for the other
and if two HLLs make different choices, then interop is completely gone
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
dukeleto holy vivification, batman!
chromatic Not that that is an argument for, against, alongside, or related to fetch/vivify.
pmichaud agreed
anyway, here's my takeaway
allison early on Parrot made the assumption that a language would use either assignment or binding for its aggregates, not both
pmichaud that's a bad assumption, given that many languages have both 22:32
allison very possibly true, and that may need to change
pmichaud I see long deprecation cycles in our future, which totally doesn't help me today.
allison (the default assign_whatever_whatever could always be an alias to the set equivalent)
what's your takeaway?
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
and because set and assignment are so screwed up in Parrot already, anything we add is going to make it even more convoluted
chromatic All PMCs now and forever.
allison pmichaud: still an addition of new features
pmichaud I'm telling you, it's completely screwed up internally.
"I see long deprecation cycles in our future." 22:34
allison how about new PMCs?
pmichaud what new PMCs?
chromatic Ugh.
allison the old names are horrible anyway
pmichaud oh, you mean create all new ones
I doubt that happens "tomorrow"
allison do you really need anything but ResizablePMCArray?
chromatic That also means a long deprecation cycle and switchover flag days and....
pmichaud Hash
chromatic NameSpace
purl NameSpace is the internal namespace for things like $c->forward and template paths, anyway or hll:X::Y, but yes.
allison or maybe TypedArray?
pmichaud LexPad
please, not TypedArray 22:35
don't make the assumption that all of the elements created in an aggregate are going to be the same type
sometimes that last parameter is ['Undef']. Sometimes it's ['Hash'] (for the same aggregate)
allison we're talking about adding new interfaces to them for aggregate assignment
pmichaud anyway
allison (not removing the existing interfaces for aggregate set)
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
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.
allison chromatic did great work with CallSignature
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
allison they're just single elements
pmichaud but you can assign to them
more importantly, you might be assigning something that isn't an Integer, Float, or String
but right now, Parrot assumes assignment is of like types 22:38
or, more weirdly
if I do
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
allison aye, and we already have assign_string_native vtable function
(for example)
pmichaud If I do:
(HLL)
actually, let's start over
if I do:
$P0 = new ['Hash']
.lex '$a', $P0
$P1 = find_lex '$a'
assign $P1, 3 22:39
from a HLL perspective, I'd want $a to be an Integer 3
what I get now is an error
allison what error?
purl allison: Srmount error
allison undefined PMC?
pmichaud no
it tries to do assign_integer on the Hash PMC
when what I really wanted (HLL) was $a = 3
i.e., $a previously had a Hash in it, but now I want it to be an Integer 3
allison that's because Parrot doesn't do morphing 22:40
pmichaud right
thus my point that it's messed up
allison (we carefully ripped out morphing)
pmichaud being able to store any object in any container isn't available in Parrot, and that's a common feature of dynamic languages
allison well, it's not Perl 6 semantics, that's true
but, Perl6Hash can do it if it wants to
pmichaud you're missing my point
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..."
allison seriously, just don't provide any
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
allison provide some example dynpmcs
moritz that will simplify HLL interop enourmously, will it?
allison moritz: HLL interop is through vtable interfaces 22:42
moritz </sarcasm>
allison pmichaud: I'm actually less frustrated now, I feel like I'm beginning to understand what you need
moritz allison: and is that enough to identify objects? detect that $thing_from_oher_hll is an array?
allison moritz: that's what does and provides are for 22:43
(two different ways of declaring that a particular PMC agrees to support a specific set of vtable functions)
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.
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.
I can continue to code things the long way.
allison or define a dynop
pmichaud these need to be available in core parrot 22:45
I'm not talking about Just Rakudo.
These are for the regex engine, and NQP
Rakudo already does stuff entirely different than this.
allison the regex engine is written in NQP now, yes?
pmichaud yes
allison so, it's not relevant there
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.
allison and NQP is written in, what, PCT? as in regex plus NQP actions, translated to PIR?
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."
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:47
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
i.e., NQP wants to be able to create PIR subroutines that Parrot can run even when NQP isn't present.
allison yes, agreed 22:49
pmichaud anyway, gotta go, kids need my help.
22:58 Zak joined 23:00 Whiteknight joined 23:12 zak_ joined
Whiteknight so was there an outcome in the vivify opcode discussion? 23:21
Whiteknight slowly starts reading through logs
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
darbelo Not much of an outcome, but there was some very interesting dicussion about asignement and binding sematics. 23:23
Whiteknight there are a lot of aspects in the current situation that I am particularly unhappy with 23:28
binding and assignment are two, vtables in general irritate me to no end.
darbelo If the vm were perfect we wouldn't be working on it ;)
darbelo is removing a vtable now. 23:29
Whiteknight no argument
In general, I like the idea of the vivify and fetch opcodes. They represent patterns that demonstrably get used A LOT
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.
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
darbelo She was arguing that the very existance of the hoop means something's wrong with our design. 23:31
Whiteknight right, but it requires that PMC vtables be more consistent, because we're applying an external interface to them 23:32
and we would rightfully expect that any aggregate would "do the right thing" when passed to a vivify or fetch opcode
chromatic And they do, if the aggregate does anything at all sane with get/set.
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'.
japhb Whiteknight, and namespace, and so on.
er Namespace
Whiteknight japhb: that's my point! We have lots of types of aggregates, and they all need to behave similarly
or, at least do what we expect
what if we pass a MultiSub to vivify? Or Env? Or CallSignature? Or Context? or... 23:34
23:35 Zak joined
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.
That's why callee-side semantics alone are insufficient.
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"
jonathan japhb++ # exactly. 23:36
23:36 mikehh joined
allison Whiteknight: similarly, but not identically 23:39
Whiteknight not identically, no. But the VTABLEs in general are so wildly inconsistent right now 23:40
and I'm not just talking about aggregate-related ones (which tend to be better than most)
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
and, we can't deny the huge benefit they have on generated PIR code
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
Whiteknight that kind of guarantee is very important if we expect HLLs to be using our PMC types with any surety
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:49
kiwichris Could someone please help with Parrot_runcode for the RTEMS port ? 23:51
Whiteknight kiwichris: what's the problem?
purl somebody said the problem was that alpine is talking to an SMTP daemon when making local deliveries, and that is having unexpected effects.
moritz purl: forget what's the problem 23:52
purl moritz, I didn't have anything matching what's the problem
moritz purl: forget what's the problem?
purl moritz, I didn't have anything matching what's the problem
cotto_work no, the problem is you
purl okay, cotto_work.
jonathan purl: forget the problem
purl jonathan: I forgot problem
kiwichris Whiteknight, the code seems conditional on EXEC_CAPABLE. Does this mean an exec happens ?
moritz purl: no, what's the problem? is <reply>|
purl wish i knew, moritz
moritz can't remember the syntax
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
darbelo Whiteknight: You are thinking of the exec runcore?
kiwichris: What file/line is that giving you trouble in? 23:54
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?
Ah. 1.6 still had JIT.
kiwichris darbelo, EXEC_CAPABLE is not defined
darbelo, should I move to 1.7.0 ?
darbelo kiwichris: Probably.
kiwichris darbelo, great I will. Back in a while.
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.
darbelo japhb: Let's go easy on him, we don't want to scare him away yet. ;) 23:57
dukeleto kiwichris: hello!
kiwichris japhb, ok, I think HEAD testing is always good to do.
japhb darbelo, :-) 23:58
kiwichris dukeleto, hi. We need to chat about exit at some point in time. An exit === reboot for me.
darbelo Hmm, kiwichris are there any recipes for building RTEMS from OpenBSD? I looked around but didn't find much.
dukeleto kiwichris: oooh. where are we calling exit? 23:59
kiwichris: also, I am seeking $food in a few minutes and we back in a bit
kiwichris kiwichris, yeap in a few places.
dukeleto kiwichris: but there are lots of nice peeps in here to help you (except purl)

Powered by Cro and the Raku® Programming Language.

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

Thank you!