Camelia, the Perl 6 bug

IRC log for #parrot, 2011-05-13

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 bluescreen__ joined #parrot
00:04 benabik joined #parrot
00:25 TiMBuS left #parrot
00:26 TiMBuS joined #parrot
00:27 athomason left #parrot
00:28 cotto_work bacek_at_work: manual bisect result is nonsensical and my attempts to automatedly bisect with cmd are making me insane.
00:29 whiteknight Insanity: it's how nature tells you WHARBLEGARBLE
00:31 athomason joined #parrot
00:37 cotto_work bash looks incredibly friendly all of a sudden
00:41 whiteknight I've always felt like people who develop console and their command syntax must be special kinds of people
00:48 cotto_work It seems like in the long term, it'd be less effort to implement a sane shell from scratch than to use cmd.exe.
00:49 atrodo cotto_work++ # Well volunteered
00:49 cotto_work um, no
00:50 cotto_work unless by "implement", you mean "install cygwin"
00:50 atrodo wfm
00:57 kid51 joined #parrot
01:06 kid51 left #parrot
01:10 sorear Has OSUOSL talked about what happened to trac yet?
01:10 whiteknight sorear: what I've heard is basically what we already guessed
01:11 whiteknight smolder ate all available memory, the VM crashed, files got corrupted, etc
01:11 whiteknight I think that file was probably just in an unlucky sector
01:17 mtk left #parrot
01:19 alester left #parrot
01:19 cotto_work Awesome.  In the process of trying to automate bisecting, I somehow got .git/BISECT_RUN into a state where I can't delete it.
01:20 atrodo Wow, that's rather amazing
01:21 cotto_work nm.  looks like there was a stray git.exe running
01:21 cotto_work poor thing
01:24 mtk joined #parrot
01:54 Coke_ (shell programming on windows) I find JS (invoked via cscript) quite tolerable.
02:00 bluescreen_ left #parrot
02:00 bluescreen__ left #parrot
02:00 bluescreen left #parrot
02:02 whiteknight left #parrot
02:05 cotto joined #parrot
02:11 cotto ~~
02:14 kid51 joined #parrot
02:15 kid51 So tonight my iBook crashed twice, both times on what may be an infected email.
02:15 kid51 And after those crashes, Parrot now PASSes make test on Darwin/PPC.
02:15 kid51 go figure.
02:16 cotto kid51, best virus ever
02:16 cotto btw, does that machine have /dev/urandom?
02:16 cotto need to go offline; will check irclog
02:16 cotto left #parrot
02:16 kid51 plobsing ping
02:17 woosley joined #parrot
02:20 kid51 msg plobsing Our perlcritic standards preclude the use of subroutine prototypes.  Can you revise config/gen/opengl.pm to not have sub any require a prototype?  Thanks.
02:20 aloha OK. I'll deliver the message.
02:25 plobsing kid51: pong
02:25 dalek parrot: 420e2a1 | plobsing++ | tools/dev/nci_thunk_gen.pir:
02:25 dalek parrot: throw error for unsupported types
02:25 dalek parrot: review: https://github.com/parrot/parrot/commit/420e2a15b4
02:26 kid51 plobsing: Can you rework that revision so that it doesn't use any()?
02:26 plobsing kid51: but it explains *exactly* what the operation I want to perform is
02:26 plobsing I would have just used List::MoreUtils, but it doesn't appear to be in core
02:27 kid51 But our current codingstd precludes use of sub prototypes.  A couple of years back we went through and pulled them out.
02:28 kid51 If we would set Perl 5.10 as our minimum version, to be sure, we wouldn't have this problem, because we'd get List::Utils in core.
02:28 kid51 And I, for one, would vote for that.
02:28 kid51 But, in the meantime, I think we should stick to our codingstds.
02:29 plobsing I'd argue that standard is to prevent the missuse of sub protos, as opposed to careful, tactical, and correct usage, as is the case here, but I'll cede.
02:30 Topic for #parrot is now Parrot 3.3.0 released | http://parrot.org | Log: http://irclog.perlgeek.de/parrot/today | Trac accounts should be working properly again; talk to cotto, coke or whiteknight if you have trouble
02:32 dalek parrot: 039c0ed | plobsing++ | config/gen/opengl.pm:
02:32 dalek parrot: avoid sub prototype
02:32 dalek parrot:
02:32 dalek parrot: standards win out over expressivety
02:32 dalek parrot: review: https://github.com/parrot/parrot/commit/039c0edca9
02:35 ttbot Parrot 420e2a15 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/3662
02:35 cotto joined #parrot
02:37 cotto ~~
02:41 cotto dukeleto, thanks for getting the trac passwords back to normal
02:41 cotto dukeleto++
02:44 ttbot Parrot 039c0edc MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/3701
03:16 * kid51 must sleep
03:16 kid51 left #parrot
03:17 atrodo alright, now that i'm done with that distraction, maybe i can actually get work on ipfy done
03:20 plobsing atrodo: care to share what you have planned?
03:20 atrodo plobsing: Nothing earth moving.  Cleanup mostly
03:20 plobsing atrodo: any chance you could figure out how to smooth that noise?
03:21 jsut_ joined #parrot
03:21 atrodo major change would be a meta config file that gets pulled and multiple branches
03:21 atrodo plobsing> Probably better tests and more data
03:21 jsut left #parrot
03:21 atrodo Going to try it on a different machine that does less, but it's also much older
04:04 dalek parrot: 17a997e | plobsing++ | / (2 files):
04:04 dalek parrot: add support for long double NCI parameters
04:04 dalek parrot:
04:04 dalek parrot: long doubles are potentially larger than parrot-native floatvals. this may to
04:04 dalek parrot: undesirable truncation. You have been warned.
04:04 dalek parrot: review: https://github.com/parrot/parrot/commit/17a997ebea
04:04 dalek parrot: ec159d2 | plobsing++ | config/gen/config_h/config_h.in:
04:04 dalek parrot: keep track of sizeof (long long) if the platform has a long long type
04:04 dalek parrot: review: https://github.com/parrot/parrot/commit/ec159d26bf
04:04 dalek parrot: 40d2607 | plobsing++ | / (2 files):
04:04 dalek parrot: add long long support to NCI
04:04 dalek parrot:
04:04 dalek parrot: long long is potentially larger than the parrot-native intval. this may lead to
04:05 dalek parrot: undesired truncation. furhter, long long is a non-standard (but common) type and
04:05 dalek parrot: may not be present on all platforms. using this type reduces the portability of
04:05 dalek parrot: your code. YOU HAVE BEEN WARNED!
04:05 dalek parrot: review: https://github.com/parrot/parrot/commit/40d26076f5
04:05 dalek parrot: c7e27f5 | plobsing++ | / (2 files):
04:05 dalek parrot: add 8, 16, 32, and 64 bit NCI argument types
04:05 dalek parrot:
04:05 dalek parrot: 64 bit integers may be larger than parrot-native intvals. this may lead to
04:05 dalek parrot: undesirable truncation. 64 bit integers are only available where the underlying
04:05 dalek parrot: C compiler provides them. using this type may make your code less portable. YOU
04:05 dalek parrot: HAVE BEEN WARNED!
04:05 dalek parrot: review: https://github.com/parrot/parrot/commit/c7e27f58d5
04:05 dalek parrot/get-entropy: 898cbac | cotto++ | config/gen/makefiles/root.in:
04:05 dalek parrot/get-entropy: add Makefile dependencies for entropy.c
04:05 dalek parrot/get-entropy: review: https://github.com/parrot/parrot/commit/898cbac499
04:06 benabik plobsing: A big warning somewhere in the documentation would be better than one in a commit message.  :-/
04:07 * benabik hopes there is documentation for NCI somewhere.
04:07 plobsing benabik: you can make your hopes a reality
04:08 cotto The best person to document something is the one who's learning it as he goes.
04:08 cotto though it's usually easier for whoever wrote it in the first place
04:13 plobsing I will happily answer questions regarding NCI, especially for people looking to document it.
04:14 bubaflub plobsing: after my last final tomorrow i might take you up on that; i'm more than happy to document as i go for GSoC
04:14 ttbot Parrot c7e27f58 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/3802
04:15 benabik bubaflub++
04:16 theory left #parrot
04:17 dalek TT #1182 closed by plobsing++: Add 'long long' to types supported by NCI
04:17 dalek TT #1182: http://trac.parrot.org/parrot/ticket/1182
04:39 bubaflub left #parrot
04:45 dalek parrot: 4acf951 | plobsing++ | config/gen/opengl.pm:
04:45 dalek parrot: generate opengl bindings which were blocked on TT #1182
04:45 dalek parrot: review: https://github.com/parrot/parrot/commit/4acf95160e
04:46 cotto dukeleto, ping
04:58 ttbot Parrot 4acf9516 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/3978
05:13 dalek parrot/m0-prototype: 02b13b2 | cotto++ | src/m0/m0_interp.pl:
05:13 dalek parrot/m0-prototype: add dummy implementations of all ops to the M0 interp
05:13 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/02b13b2eb2
05:20 Coke_ left #parrot
05:20 Coke_ joined #parrot
05:21 birdwindupbird joined #parrot
05:37 birdwindupbird left #parrot
05:42 jrtayloriv joined #parrot
06:22 JimmyZ joined #parrot
06:25 JimmyZ left #parrot
06:28 rurban_ joined #parrot
06:32 rurban left #parrot
06:32 rurban_ is now known as rurban
06:54 cotto left #parrot
07:01 mj41 joined #parrot
07:08 jrtayloriv left #parrot
07:37 contingencyplan left #parrot
07:44 ligne joined #parrot
07:45 ligne left #parrot
07:46 rurban_ joined #parrot
07:48 rurban left #parrot
07:48 rurban_ is now known as rurban
08:40 ShaneC joined #parrot
08:56 jnthn__ Anybody know what replacd "t" NCI parameter type?
09:02 macroz joined #parrot
09:04 ShaneC left #parrot
09:05 mtk left #parrot
09:11 mtk joined #parrot
09:16 JimmyZ joined #parrot
09:16 bacek_at_work jnthn__, nothing. And I actually will miss it.
09:21 bacek_at_work jnthn__, ask plobsing. He is mastermind of this deprecation.
09:22 jsut joined #parrot
09:24 jnthn__ bacek_at_work: :(
09:25 jnthn__ bacek_at_work: He broke so much in doing that.
09:25 jnthn__ Like, most of useful NCI on Perl 6.
09:25 jnthn__ plobsing--
09:25 jnthn__ plobsing--
09:26 jnthn__ Could just revert it.
09:27 jsut_ left #parrot
09:40 jnthn__ None of the Parrot examples that used it have been updated either.
09:40 jnthn__ The only thing the deprecation notice mentions is use from C land, which isn't our use case.
09:44 jnthn__ https://github.com/parrot/parrot/c​ommit/75e2b4c94d602d3d7e8af4b679c3​25c8ec8d3fd9#src/nci/extra_thunks.nci
09:45 jnthn__ That just ripped out all uses, not updated them to do things in a better way!
10:02 woosley left #parrot
10:08 JimmyZ left #parrot
10:32 bacek jnthn__, I tend to agree with you. But speak to plobsing/mail-list first. May be he has something in mind to replace "t".
10:34 sjn left #parrot
11:02 Psyche^ joined #parrot
11:07 Patterner left #parrot
11:07 Psyche^ is now known as Patterner
11:24 jnthn__ bacek: done so
11:25 bacek jnthn__, ok :)
11:25 dalek nqp: 34e9e7c | bacek++ | src/pmc/sixmodelobject.pmc:
11:25 dalek nqp: Make compiler little bit more happy.
11:26 dalek nqp: review: https://github.com/perl6/nqp/commit/34e9e7cee4
11:26 dalek nqp: ba5200b | bacek++ | src/ops/nqp.ops:
11:26 dalek nqp: Add couple more write_barriers when we poke into DispatcherSub directly.
11:26 dalek nqp: review: https://github.com/perl6/nqp/commit/ba5200b90b
11:34 UltraDM joined #parrot
11:34 darbelo joined #parrot
11:34 jnthn__ oh noes, nci_thunk_gen.pir doesn't work on Win32 :/
11:37 atrodo That seems convenient
11:37 jnthn__ meh, think I give up on NCI stuff for now... :/
11:38 atrodo probably for the best
11:39 jnthn__ <- unimpressed
11:50 JimmyZ joined #parrot
11:53 Coke left #parrot
11:53 Coke joined #parrot
11:59 macroz left #parrot
12:10 mj41 left #parrot
12:11 bluescreen joined #parrot
12:13 Coke left #parrot
12:14 Coke joined #parrot
12:20 woosley joined #parrot
12:22 JimmyZ left #parrot
12:23 bluescreen left #parrot
12:23 bluescreen joined #parrot
12:31 Coke left #parrot
12:31 Coke joined #parrot
12:33 ambs joined #parrot
12:37 dod left #parrot
12:44 Coke left #parrot
12:44 Coke joined #parrot
12:47 smash joined #parrot
12:47 smash hello everyone
12:48 Coke_ hio.
13:06 whiteknight joined #parrot
13:07 bubaflub joined #parrot
13:10 dalek nqp: 509350b | moritz++ | t/setting/01-resizablepmcarray.t:
13:10 dalek nqp: [t/setting] delete an outdated test
13:10 dalek nqp: review: https://github.com/perl6/nqp/commit/509350bc23
13:11 bluescreen_ joined #parrot
13:14 JimmyZ joined #parrot
13:25 dalek nqp: ad31d07 | jonathan++ | src/how/NQPClassHOW.pm:
13:25 dalek nqp: Forbid classes inheriting from themselves.
13:25 dalek nqp: review: https://github.com/perl6/nqp/commit/ad31d07dbe
13:25 whiteknight good morning, #parrot
13:26 JimmyZ good morning whiteknight
13:26 whiteknight hello JimmyZ. How are you doing today?
13:29 bluescreen_ left #parrot
13:29 JimmyZ whiteknight: not too bad, though business is slow
13:30 bluescreen left #parrot
13:44 bluescreen_ joined #parrot
13:44 bluescreen joined #parrot
14:08 UltraDM left #parrot
14:12 bluescreen left #parrot
14:15 bluescreen_ left #parrot
14:16 woosley left #parrot
14:17 lucian joined #parrot
14:17 pmichaud I don't suppose the profiling runcore and tools are getting any love anytime soon.
14:21 pmichaud is there a way in the cachegrind tools to determine how many times a particular function has been called?
14:27 bluescreen joined #parrot
14:27 bluescreen_ joined #parrot
14:31 whiteknight pmichaud: We floated those things as ideas for GSoC projects, but no takers. Without that, we have to formulate a plan to work on those things ourselves
14:32 whiteknight pmichaud: I'm not aware of a way to use valgrind to get information about PIR-level subs
14:41 hercynium joined #parrot
14:46 alester joined #parrot
14:49 cotto joined #parrot
14:54 pmichaud I meant for C-level subs
14:54 pmichaud (or PIR-level subs)
14:55 pmichaud just knowing the number of times certain C-level subs get called would be useful to me
14:56 whiteknight pmichaud: oh, those numbers should appear when you run the file through kcachegrind
14:56 pmichaud I can see the instruction counts, but not the call counts (more)
14:56 pmichaud more precisely, I don't know how to view call counts in kcachegrind
14:56 cotto ~~
14:57 pmichaud and I wasn't able to find anything about it with Google
14:57 whiteknight let me fire it up and take a look.
14:59 pmichaud oh, nm
14:59 pmichaud it's right there
14:59 pmichaud hmmm
15:01 pmichaud so, I guess my questions becomes:  is there a way to get those values via command line (e.g., callgrind_annotate)?
15:01 pmichaud callgrind_annotate seems to just give Ir counts
15:04 theory joined #parrot
15:06 cotto any objections to merging get-entropy?
15:06 pmichaud Can I object after it's merged?  ;-)
15:06 cotto let's find out
15:07 pmichaud did anyone test the branch with rakudo?
15:07 pmichaud if no, would you like me to do so?
15:07 cotto d'oh
15:07 cotto I'll do that now
15:07 pmichaud I can test also.
15:07 cotto I'd be highly surprised if it caused anything other than higher-quality randomness though.
15:07 pmichaud me also, but surprises are what we want to avoid
15:08 cotto yes
15:08 plobsing cotto: I have P(objection) = 0.1. Are you feeling lucky?
15:09 * cotto consults the get-entropy branch
15:10 cotto looks like I do
15:11 pmichaud (from email thread):  "The signatures were removed with the intent that they be replaced later with their equivalents as needed."   I thought our stance these days was that we wouldn't remove a feature until its replacement was available.
15:11 cotto That was the intent.
15:11 pmichaud Hmm.
15:11 whiteknight I think the deprecation notice for those signature strings was for direct removal
15:11 whiteknight I have to go back and look, but I don't remember a replacement being specified
15:12 pmichaud surely we would provide an equivalent capability, though?
15:12 cotto It should have been.  This is the exact kind of situation we want to avoid.
15:12 whiteknight There is an equivalent, pcre bindings use it
15:12 pmichaud does that work for Rakudo, written in PIR?
15:12 atrodo can someone remind me what t was?
15:12 jnthn__ The examples weren't updated, and the mysql signatures were just tossed.
15:12 whiteknight plobsing suggests so, using NCI
15:13 jnthn__ Rather than updated with how they should look.
15:13 whiteknight atrodo: t magically extracted a null-terminated C string from a parrot STRING
15:13 jnthn__ er, *some* of them were...
15:13 atrodo whiteknight> thanks
15:13 cotto rakudo build looks good, running spectest_regression
15:14 whiteknight it turns out to be a pretty expensive operation. Parrot STRING is not null-terminated by default, so the operation has to do a memcopy
15:14 whiteknight plus, Parrot STRING might contain nulls internally, which causes havoc in c libraries
15:14 pmichaud imo, the point of "don't remove until new feature is available" is so that the downstream users have time to switch to the new way of doing things (and test it, and provide feedback about problems) before the old working mechanism disappears entirely.
15:14 dukeleto ~
15:16 plobsing jnthn__: those signatures were created for an internal mysql library that has since been dropped (not sure why). It is my opinion that signatures that are not required by parrot (or any bundled code) should not be included in core. Parrot provides a static thunk generator and a runtime thunk generator as options for module developpers.
15:18 jnthn__ plobsing: Expecting module developers to write static thunks is kinda sucky. The runtime one currently, as far as I know, can't be picked up on Windows as the probe depends on pkg-config. Also, the dlfunc with NULL as first argument doesn't work on Win32. The static thunk generator depends on that also.
15:18 dalek nqp: bb72006 | moritz++ | src/ (2 files):
15:18 dalek nqp: compile methods to anonymous PIR subs
15:18 dalek nqp: review: https://github.com/perl6/nqp/commit/bb720069e2
15:19 jnthn__ (Discovered these today...didn't get chance to ticket them yet...)
15:19 pmichaud what ticket is all of this covered under?
15:19 plobsing pmichaud: that system requires participation of downstream developpers, which rarely if ever seems to happen these days
15:20 jnthn__ pmichaud: This started out from my attempts today to get NativeCall updated because MiniDBI had stopped working.
15:20 pmichaud jnthn__: yes, I know (more)
15:21 pmichaud I'm curious what ticket covers the deprecation.
15:21 plobsing TT #1931
15:21 pmichaud that ticket isn't mentioned in api.yaml
15:21 pmichaud (the api.yaml of 3.3.0 release)
15:22 moritz plobsing: I find it hard as a downstream user to actually decide which discussions are relevant for me
15:22 plobsing pmichaud: that ticket *was* mentioned in DEPRECATED.pod. It was not properly ported over.
15:22 cotto It's in the current api.yaml
15:22 pmichaud I thought deprecations get noticed in supported releases.
15:23 whiteknight pmichaud: yes, it's been listed since at least 3.0.0 in deprecated.pod
15:23 jnthn__ afk
15:23 pmichaud where is deprecated.pod?
15:23 whiteknight it does not appear to have been moved to api.yaml for some reason, but it was in the older file
15:23 whiteknight pmichaud: in the 3.0.0 tag
15:23 plobsing why did we move to api.yaml?
15:23 whiteknight plobsing: programmatic access
15:24 dukeleto plobsing: deprecations as data
15:24 dukeleto plobsing: storing structured info in POD is dumb
15:24 plobsing I don't see why yaml is more desirable than POD
15:24 pmichaud "t manage null-padding in sugar layer
15:24 pmichaud "   (from #1931)
15:25 pmichaud that doesn't seem particularly useful to a user.
15:25 dukeleto plobsing: DEPRECATED.POD had no format. It was free-form
15:25 cotto dukeleto, will you be online later today?  I want to talk M0 but need to get ready for $dayjob soonish.
15:25 plobsing dukeleto: at least it was easy to read
15:25 dukeleto cotto: sure. will be on later.
15:25 cotto great
15:26 plobsing pmichaud: there is also advice for porting in the deprecation page
15:26 dukeleto plobsing: is there a wiki page describing how people can deal with the latest NCI deprecations? You described something on parrot-dev, but is there a deprecation wiki page describing how to deal with the deprecation?
15:26 dukeleto jnthn__: i haven't backlogged yet. Is MiniDBI still between a rock and a hard place?
15:26 pmichaud plobsing: the ticket?  or some other page?
15:26 dalek nqp: c9dd840 | moritz++ | / (2 files):
15:26 dalek nqp: install hash() constructor, make t/setting/02-hash.t pass again
15:26 dalek nqp: review: https://github.com/perl6/nqp/commit/c9dd840160
15:27 cotto t/spec/S03-operators/relational.t .............................. Failed 6/110 subtests
15:27 plobsing http://trac.parrot.org/parrot/wiki/ParrotDepre​cationsFor3.6#SpecialPurposeNCIParameterTypes
15:27 pmichaud dukeleto: yes.
15:27 dalek nqp: ad4a452 | moritz++ | .gitignore:
15:27 dalek nqp: ignore .so files
15:27 cotto should that be a concern?
15:27 dalek nqp: review: https://github.com/perl6/nqp/commit/ad4a4523bd
15:27 pmichaud cotto: all tests successful here.
15:27 pmichaud cotto: I'm guessing you have an older copy of rakudo.
15:27 pmichaud (i.e., from before the NaN fixes to relops)
15:27 cotto so I do
15:27 dukeleto plobsing: that page does not provide sufficient information for Perl 6 devs to fix breakage from 't' changes
15:28 dukeleto plobsing: you gave more info in your email to parrot-dev, but it still is not clear *exactly* how code should change
15:28 darbelo_ joined #parrot
15:29 dukeleto plobsing: can you add some example code to it, showing how 't' was used before, and what the code should change to? Even if it is pseudo-code-ish, that would help
15:29 plobsing the pcre and pg bindings used 't' signatures before and have been updated
15:29 pmichaud and although Rakudo might not need it -- that information really ought to be available for all of the parameter types that were removed
15:30 dukeleto plobsing: yes, but the knowledge of how to convert from 't' to whatever is used now is buried somewhere in the source/history of Parrot and is not very findable, even to Perl 6 devs who are very familiar with parrot
15:30 dukeleto plobsing: i would say that is a failure on our part
15:30 darbelo left #parrot
15:31 dukeleto pmichaud: i agree with you
15:31 dukeleto pmichaud: i think we are still growing into our new deprecation policy. It is better than before, but obviously we still need to get better
15:31 TimToady pity you can't make the omelet and *then* break the eggs...
15:32 pmichaud dukeleto: yes, things are getting better.  we've just had a couple of unwanted surprises in the past couple of weeks
15:32 dukeleto pmichaud: knowing if deprecation wiki pages are sufficiently helpful cannot be programmatically checked :) So we only know when they aren't in times like these, when an HLL dev says, "WTF? Stuff is broke and these docs are incomplete"
15:32 whiteknight we did have a deprecation notice and a wiki page talking about the changes that needed to get made. It seems that nobody read that information still
15:32 dukeleto TimToady: if only the universe were a reversible system...
15:32 whiteknight if a downstream user had read it before now, we would know whether the information was sufficient or not
15:32 pmichaud whiteknight: what wiki page -- I'm not able to find it.
15:33 dukeleto http://trac.parrot.org/parrot/wiki/ParrotDepre​cationsFor3.6#SpecialPurposeNCIParameterTypes
15:33 dukeleto pmichaud: ^^^
15:33 whiteknight pmichaud: that may be true, but nobody alerted us that enough information was not readily available
15:33 pmichaud is that linked from the ticket or deprecation notice?
15:33 atrodo dukeleto> If the world was reversible, my life would be much simplier
15:33 whiteknight nobody looking at the deprecation notice and not seeing that there wasn't a link is telling in itself. We need more participation on both sides
15:34 dukeleto pmichaud: linked from here http://trac.parrot.org/parr​ot/wiki/ParrotDeprecations
15:34 pmichaud also, that notice says deprecation for *3.6*
15:35 plobsing pmichaud: that is the supported release in which the deprecations take effect
15:35 dukeleto pmichaud: yeah, the wiki pages are named oddly. It means deprecations between 3.6 and the previous release
15:35 plobsing which means the removal occurs between 3.3 and 3.6
15:35 dukeleto pmichaud: kind of like the sum of all deprecation changes between major releases
15:35 pmichaud deprecation means "no longer supported".  deprecation occurs prior to removal.
15:36 pmichaud the deprecation occurred in 3.0.  the removal is occuring in 3.6
15:36 plobsing the list is those that have been acted upon
15:36 whiteknight the wiki page looks wrong. Deprecated.pod in 3.0.0 clearly says it's available for removal starting in 3.1
15:36 dukeleto we also have https://github.com/parrot/parrot/b​lob/master/tools/dev/dedeprecator , which is an nqp script that uses api.yaml to look for deprecated code
15:37 dukeleto pmichaud, jnthn__ : the parrot community would love to hear feedback on that script and improvements that can be made to it
15:37 pmichaud one last question:  would it have been possible for Rakudo to migrate to the new system in 3.3.0 ?
15:37 whiteknight having multiple sources of documentation (api.yaml, tickets, wiki) is not helpful if those sources are out of sync
15:37 pmichaud i.e., can I get a version of zavolaj that runs on 3.3.0 but doesn't use the 't' parameter?
15:37 plobsing dukeleto: how is that an improvement over the deprecations warning system?
15:37 dukeleto pmichaud: i think it will currently give you the link to that wiki page when it finds the NCI deprecation
15:38 dukeleto plobsing: because a person can run that script on a codebase and get a list of all deprecations and associated wiki pages, which *hopefully* have detailed instructions for how to deal with the deprecation
15:38 dukeleto plobsing: our dep warnings just give a warning, iirc
15:39 dukeleto plobsing: api.yaml stores regexes, so it can be smarter when looking for deprecated code
15:39 plobsing but static analysis is inherently limited
15:39 dukeleto plobsing: sure. But that is a straw man.
15:39 pmichaud dukeleto: (love to hear feedback)  you're hearing it.  :)
15:39 whiteknight okay, we're getting off onto a tangent
15:39 dukeleto plobsing: we are trying to make something workable, not disprove the Riemann Hypothesis
15:40 whiteknight we need to figure out what Parrot needs to do right now, what we need to do differently in the future.
15:40 pmichaud more directly, from a Rakudo/zavolaj perspective... what do we need to do to get it to work with current Parrot?
15:40 whiteknight I'm most annoyed by the fact that this entry was in DEPRECATED.pod as of 3.0.0 and that it didn't appear in api.yaml for 3.3.0
15:40 dukeleto pmichaud, jnthn__ : one idea is to have the dedeprecator run automatically for all Parrot HLL's, so we can notice breakage automatically and notify people. And/or have a web interface to it
15:40 whiteknight pmichaud: if Parrot needs to revert something, that decision has to happen first
15:40 redicaps joined #parrot
15:40 pmichaud whiteknight: well, obviously we'd prefer to not make Parrot revert.
15:41 dukeleto pmichaud, jnthn__ : does that sound useful to y'all ?
15:41 pmichaud it would be better for all of us if we can just get zavolaj working with the new environment
15:41 whiteknight pmichaud: we're in a grey area. Obviously the entry not appearing in api.yaml is a problem on our side
15:41 pmichaud dukeleto: it sounds useful, but I'm skeptical that it will actually work.  :-)
15:41 dukeleto plobsing: is there any way you can use some of your extensive knowledge of NCI stuff to make zavaloj work again?
15:41 plobsing dukeleto: I'll have a go at it.
15:41 pmichaud dukeleto: a good test would be to run it on zavolaj and see if it offers up the warning
15:41 dukeleto pmichaud: sure. But remember, all progress is made by irrational people, as I am sure you know well :)
15:42 dukeleto pmichaud: i hold out that we can automate some things which we believe can only be done manually
15:42 pmichaud (in this case, we *know* it wouldn't have found the problem because the deprecation wasn't in 3.3.0 api.yaml)
15:42 dukeleto pmichaud: api.yaml was created specifically with that in mind
15:42 pmichaud dukeleto: I don't disagree with the fact that we can automate a lot more stuff.
15:42 pmichaud I'm just not sure that the tool would've had any chance to find this particular deprecation.
15:43 dukeleto pmichaud: sure, but that was a hiccup causes by insufficient data. *If* (a big if) all deprecations are described correctly in api.yaml, we would have been in a better situation
15:43 pmichaud I'd like to be proved wrong.  I'd like to see if we fix up api.yaml if the tool actually finds the deprecation in zavolaj.
15:43 dukeleto pmichaud: yes, that would be lovely.
15:43 whiteknight I want to make it more clear in support_policy.pod that api.yaml is the definitive source of deprecation information
15:43 dukeleto whiteknight: sure. It isn't clear already?
15:44 plobsing from my prior knowledge of zavolaj, I know it builds up signature strings dynamically. the only opportunity it would have for identifying the failure is if it triggered off of every instance of the single character 't' string
15:44 whiteknight dukeleto: no, not really. We had a difference in target date between api.yaml and the wiki, we need to be clear which one wins in a conflict
15:44 whiteknight I would be much happier not duplicating the list, but we have it so we need to be clear about it
15:45 pmichaud dukeleto: the code that zavolaj uses for signatures is https://github.com/jnthn/zavolaj​/blob/master/lib/NativeCall.pm6.  Would your tool have caught this?
15:45 pmichaud if so, what would it have looked for?
15:45 dukeleto plobsing: perhaps we could add a test to zavolaj, and then the dedeprecator would see the test has deprecated code
15:45 pmichaud (line 63 is the one that violates the deprecation)
15:46 rurban_ joined #parrot
15:46 dukeleto pmichaud: no, that is quite hard to catch. But if there was a test for 't' specifically, we would have caught that
15:47 plobsing how many other instances of 't' would we also catch at the same time?
15:47 pmichaud ...what, report every.... what plobsing++ said
15:47 whiteknight it's fruitless to be arguing over the utility of the tool. It's obviously not going to be perfect in all situations
15:48 dukeleto whiteknight++
15:48 pmichaud it's not fruitless if the recommendation we're getting is "use this tool and you'll find all (or even most) of your deprecations"
15:48 whiteknight we have this tool, we have warnings that can be enabled (but rarely are) also. We are trying to provide many mechanisms to help keep up with deprecations
15:48 dukeleto pmichaud: the tool is better than nothing. api.yaml is better than DEPRECATED.pod. Nothing is perfect.
15:48 rurban left #parrot
15:48 rurban_ is now known as rurban
15:49 whiteknight we're really trying to do our best with this deprecation policy, and still keep getting bitten by it
15:49 pmichaud I'm not asking for perfect.  I'm asking for "works"
15:50 plobsing perhaps we should leave deprecation warnings on by default in parrot so that users don't need to know about the functionality beforehand to use it
15:50 whiteknight I'd say we could turn them on for unoptimized builds by default, but Rakudo only uses optimized builds
15:51 pmichaud I don't mind setting rakudo to always run with deprecation warnings, at least for non-releases.
15:51 whiteknight and if we enable the warnings by default for all builds, I'm certain the Rakudo makefile will always disable it by defualt
15:51 plobsing also, I think pmichaud++  brings up a good point about the wiki page being unfindable from the api.yaml and deprecation ticket entries. our SOP should be modified to create that link.
15:51 pmichaud but before doing that, I'd like to know if deprecation warnings would've caught this in 3.3.0
15:52 plobsing pmichaud: I could have easily added a warning about that, and would have had I had reason to believe it would have helped anyone
15:52 dukeleto Some depreacations are impossible to detect automatically. We can all agree on that, right?
15:52 dukeleto Parrot wants to make the ones that *are* possible to find, findable.
15:53 pmichaud plobsing: (could've/would've)   the point of having the flag is that parrot advertises that it'll help if you use it
15:53 pmichaud (more)
15:53 pmichaud you can hardly fault us for not using the flag if it actually doesn't produce anything :-)
15:53 pmichaud i.e., that seems like a circular sort of argument to me :)
15:54 plobsing it is a chicken/egg problem to be sure. there's no point using the flag if it won't warn you about impending deprecations and there's no point using the functionality to warn if noone is listenning
15:54 pmichaud I'm not sure I agree with that latter part.
15:55 pmichaud based on that reasoning, parrot shouldn't have a warn-on-deprecations option if we (parrot) believes nobody will ever actually use it
15:55 pmichaud some things have to be done on faith.  some things have to be done even when nobody is using them simply because we're trying to encourage people to start using them
15:56 pmichaud in this case, it's kind of specious to say anything along the lines of "well, Rakudo ought to be using PARROT_WARNINGS_DEPRECATED_FLAG" when it wouldn't have helpd in this instance anyway
15:57 pmichaud how many of Parrot's other tools are using the flag?
15:57 dukeleto pmichaud: i think you are talking into the wind
15:58 pmichaud I'm used to that, I guess.
15:58 pmichaud I can stop.
15:58 whiteknight here's an extremely important question: We've been doing a hell of a lot more for our deprecations recently, even if we can't do it all perfectly. Are our users getting any noticible returns on our investment?
15:58 pmichaud left #parrot
15:58 dukeleto pmichaud: we aren't trying to break Rakudo on purpose, be sure of that.
15:58 dukeleto wow, I guess I pissed off pmichaud. Awesome.
15:58 * dukeleto feels accomplished for the morning
15:59 whiteknight we have wiki pages where we didn't before, we have tools and flags, and tickets and all this stuff. Are our users benefiting from this all or not?
15:59 dukeleto i was just trying to tell him that he was beating a dead horse that was already buried.
15:59 whiteknight if yes, we need to improve our process to keep things from slipping through the cracks. If no, we need to find more productive ways to spend our energy
16:00 whiteknight obviously, users didn't seem to have enough information before this deprecation to anticipate problems that would arise from it. How do we make sure they have that information in the future?
16:01 whiteknight And, how do we make sure we get the feedback to tell us whether the information we are providing is sufficient
16:02 whiteknight We had a ticket, a wiki page, an entry in DEPRECATED.pod several months ago. Obviously none of that was sufficient to get the information to the people who needed it
16:02 dalek tracwiki: v10 | plobsing++ | HowToDeprecate
16:02 dalek tracwiki: updates to improve pain points experienced by recent zavolaj breakage
16:02 dalek tracwiki: http://trac.parrot.org/parrot/wiki/How​ToDeprecate?version=10&amp;action=diff
16:02 whiteknight because if users had that information in hand, they would have been able to tell us that it wasn't enough, and we could have come back with better documentation on the issue
16:03 whiteknight I'm mostly talking to myself here, but I want to make sure we learn from this and that we start moving in a better direction
16:04 whiteknight Maybe we need to be sending deprecation notices to parrot-users for feedback and discussion
16:04 darbelo_ left #parrot
16:04 whiteknight of course, we have plenty of users not subscribed to that list
16:06 plobsing I think at some point, you need to accept that we'll never reach all users with our warnings
16:10 whiteknight yeah, that's what I'm getting at in a roundabout way. No method is perfect
16:10 plobsing but I do agree we can strive to be better
16:10 plobsing which is why I've put my ideas about how this might have been averted in a small update to the deprecation SOP
16:10 whiteknight What I think we can do is to keep api.yaml up to date, and send out notifications to the parrot-dev and parrot-user lists
16:11 whiteknight Everything else, as we make it, can be linked from api.yaml
16:11 dukeleto whiteknight: seems reasonable
16:11 whiteknight so if we have enough information, we don't need pages on the wiki, etc. If we don't have enough, we add it and link to it
16:11 dukeleto whiteknight: how about this: Email parrot-dev and parrot-users every time a new deprecation is added to api.yaml ?
16:11 whiteknight if we have multiple wiki pages, tickets, email archives etc we link them from api.yaml as they are generated
16:12 whiteknight dukeleto: I like that. If we can automate it, the better
16:12 dukeleto whiteknight: that would at least give the rakudo peeps a heads up
16:12 dukeleto whiteknight: i think it could be a pretty simple tools/dev/announce_deprecation.pl script
16:12 cotto_work ~~
16:13 atrodo dukeleto> With a large "OMG WE'RE DEPRECATING STUFF!!!!11one1" in the subject
16:13 whiteknight dukeleto: okay, I like that
16:14 whiteknight I don't like the ParrotDeprecations page, if all it does is mirror data found in api.yaml
16:14 cotto_work originally api.yaml mirrored it, but it's less important now
16:17 pmichaud_ joined #parrot
16:18 whiteknight what I don't want is for us to have multiple copies of the same data which is not automatically kept in sync
16:20 dukeleto whiteknight: ok, here is an idea
16:21 * dukeleto is good at crazy ideas
16:21 pmichaud_ (just to let others know:  no, I didn't leave because of being pissed off.  I felt I was over-talking and needed to remove myself from the conversation.)
16:21 darbelo joined #parrot
16:21 * dukeleto and pmichaud_ had an enjoyable privmsg talking about stuff. All is well.
16:22 dukeleto whiteknight: ok, do you agree that api.yaml is the best option for "the canonical place for deprecation data" ?
16:22 pmichaud_ "canonical starting point", perhaps??
16:22 pmichaud_ it won't hold all of the data.
16:22 dukeleto pmichaud_: sure. perhaps "canonical nexus" ?
16:23 dukeleto pmichaud_: nexus ~~ starting point, so I think we agree
16:23 atrodo nexus sounds cooler
16:24 pmichaud_ I already have a Nexus, and I don't want it to get deprecated.  :-P
16:24 pmichaud_ anyway, "nexus" is fine.
16:24 dukeleto what if we had code which read in api.yaml and generated deprecation info, which could be exported in various formats, as well as having a WWW::Mechanize script to shove it into our trac wiki
16:24 alester Trac doesn't have any other API?
16:25 dukeleto alester: not sure, but i doubt it.
16:25 cotto_work I'd love for trac to have an api.
16:25 pmichaud_ can I make a couple of proposals?
16:25 dukeleto pmichaud_: please do
16:25 alester pmichaud_: Yes, yes, I'll marry you!
16:26 * dukeleto thinks Trac is good for ticket tracking and not much else
16:26 * alester is as happy as a little girl.
16:26 pmichaud_ first, I'd like to see us create docs/project/deprecated.pod
16:26 pmichaud_ in it, I'd like to see us document a process for deprecation
16:26 pmichaud_ much like we do for release_manager_guide
16:26 pmichaud_ 1.  Create a trac ticket
16:26 pmichaud_ 2. Add a notice to api.yaml
16:26 pmichaud_ 3. Document the replacement feature
16:27 pmichaud_ 4.  Provide examples of how to modify code to work after deprecation takes effect
16:27 pmichaud_ (most of this is already in docs/project/stability.pod, but not as a process)
16:28 pmichaud_ docs/project/deprecated.pod can also contain the step-by-step guide for users who want to keep up with deprecations
16:28 pmichaud_ 1.  Monitor api.yaml / mailing list / whatever for deprecations that might apply to you
16:29 pmichaud_ 2.  Apply the modifications given in * to avoid the deprecation
16:29 pmichaud_ etc.
16:29 pmichaud_ mainly, let's have a deprecation checklist
16:29 plobsing we have a wiki page for deprecator procedure entitled "HowToDeprecate"
16:30 pmichaud_ I think it belongs in docs/project, then.
16:31 whiteknight I have some ideas for the process. I'll write up a draft
16:31 pmichaud_ iwbni api.yaml could also contain the links to the individual parts
16:31 pmichaud_ (or somewhere)
16:31 pmichaud_ for example -- a link to the documentation explaining how to upgrade the code
16:32 pmichaud_ then we can say that a deprecation can't be completed until all of the deprecation requirements have been met (as indicated by tags in api.yaml)
16:32 darbelo left #parrot
16:33 pmichaud_ plobsing++ :  I didn't know HowToDeprecate existed.
16:33 whiteknight pmichaud_: I like the spirit of it, but I still worry that we're not taking the information to the user, we are expecting the user to come and try to find it themselves
16:33 whiteknight that's clearly not a working strategy
16:33 dalek parrot: 557712a | dukeleto++ | NEWS:
16:33 dalek parrot: Give NEWS some love
16:33 dalek parrot: review: https://github.com/parrot/parrot/commit/557712a484
16:34 whiteknight no matter how many pages we create in the wiki, no matter how much we add to api.yaml, if the user doesn't see it they are still going to get scrwed when a changover happens
16:34 pmichaud_ whiteknight: overall, I don't know that you can do much more about "taking information to the user" (more)
16:34 cotto_work Maybe we need EverythingYouEverWantedToKnowAbo​utDeprecationsButWereAfraidToAsk
16:34 pmichaud_ and in some sense, I'm not sure that's even the issue
16:34 pmichaud_ from a rakudo perspective, I don't mind so much that something broke (more)
16:34 pmichaud_ it's that when we went to fix it.... we couldn't.
16:34 whiteknight pmichaud_: I don't want to see a system where users are still confused and surprised, and the recourse for them is to come in and nitpick the process to catch us on a technicallity and force us to revert
16:35 darbelo joined #parrot
16:35 whiteknight the more steps we have to follow, the less likely any of them get done well enough
16:35 pmichaud_ and the reason we couldn't fix it is because the information wasn't available to fix.
16:35 dukeleto i think it comes down to parrot being more vocal and reminding people about deprecations
16:35 cotto_work hio darbelo
16:36 darbelo hio
16:36 pmichaud_ I think surprise is inevitable, on both sides.
16:36 whiteknight pmichaud_: and nobody went looking for the information. Nobody noticed it didn't exist until the changeover happened and peopel were confused and surprised
16:36 dukeleto perhaps every release announcement/blog post should contain a "these important deprecations happened, here are the wiki pages about them" clause
16:36 whiteknight I would rather see us engage users in deprecation conversations, as opposed to deprecation process
16:36 pmichaud_ dukeleto: that wouldn't have helped in this case -- the deprecation was four months ago
16:36 dukeleto and emailing parrot-dev and parrot-users with every additional deprecation will reduce surprise
16:37 whiteknight that's my thinking
16:37 dukeleto pmichaud_: sure. but reminding users more often is a better direction for us, than letting them always be surprised
16:37 whiteknight If we write a deprecation notice and expect users to be surprised by it, why do we have a mandatory waiting period built-in?
16:37 pmichaud_ I'm thinking surprises may be inevitable
16:38 pmichaud_ (more)
16:38 pmichaud_ I'd like surprises to be fail-softly rather than "they never occur"
16:38 whiteknight Waiting is counter-productive if surprises are inevitable
16:38 pmichaud_ we have two very recent examples to work from
16:38 pmichaud_ first, random number generation in Parrot
16:39 pmichaud_ second, the deprecated 't' feature
16:39 cotto_work pmichaud_: what do you mean by "fail-softly"?
16:39 pmichaud_ cotto_work: the impression of many of the rakudo devs is that when we report a surprise, the initial Parrot response is that it's somehow our fault
16:39 whiteknight also, the idea that we should provide the old feature and the replacement together for a time to allow switchover makes no sense if we expect the user to be surprised when the old feature is removed
16:39 pmichaud_ "you should've seen the deprecation from 3.0.0"
16:40 pmichaud_ "you shouldn't rely on Parrot for random sequences on each run"
16:40 whiteknight pmichaud_: I don't feel that the current situation is workable from either side, and there is a lot of undue blame from both sides
16:41 pmichaud_ cotto_work: but beyond that, "fail softly" to me means that when a surprise occurs, there's a concerted effort to fix the surprise
16:42 pmichaud_ in this case, we need code to show how we can bring zavolaj up to date.
16:42 pmichaud_ an example would help
16:44 cotto_work pmichaud_: the rng thing was a failure on my part.  I don't consider any significant to fault to be with Rakudo.
16:44 pmichaud_ cotto_work: but when jnthn first reported it, he was basically told "you need to fix Rakudo to work around it"
16:44 pmichaud_ to the point that when I asked on #perl6 about it, he pretty much said it was a "parrot FAIL" and we'd have to come up with our own answer
16:45 ttbot Parrot 557712a4 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/4089
16:46 cotto_work that's true
16:46 pmichaud_ it wasn't until I made noises about "deprecation fail" that it got "fixed" in Parrot.
16:48 pmichaud_ in today's issue, jnthn's question was met with
16:48 whiteknight pmichaud_: it was in DEPRECATED.pod back in 3.0.0. If any user had read that, they could have noticed that there was insufficient information to perform an update back then (more)
16:49 pmichaud_ whiteknight: in some sense, I think that the users expect Parrot to provide that information without having to be asked.  After all, the policy documents all say that Parrot will do this.
16:49 whiteknight DEPRECATED.pod and api.yaml really don't serve as good sources of information, because we can't force users to come read them and figure out which parts affect them
16:49 whiteknight pmichaud_: A far better strategy would be to email parrot-dev and parrot-users, talk to the users, and find out what information the users need
16:50 whiteknight We could have started the conversation months ago and said "We're removing 't' from NCI. Tell us who is using it and what information you need to upgrade"
16:50 pmichaud_ I don't think that would've worked (ore)
16:50 pmichaud_ (more)
16:50 whiteknight We had a wiki page, and from the perspective of the involved developers, it appeared sufficient
16:50 whiteknight We don't know it's not sufficient until a user actually reads it
16:51 whiteknight and if we can't force the users to come to our wiki, we can send emails out to them
16:51 pmichaud_ how many people knew that zavolaj was relying on 't' ?
16:51 whiteknight pmichaud_: none of the parrot devs
16:51 pmichaud_ I suspect only a few of the rakudo devs.  Perhaps even only one.
16:51 whiteknight it's the darkpan problem. We don't and can't know what all our users are using
16:51 pmichaud_ right
16:51 pmichaud_ which is why I'm after a fail softly approach
16:52 whiteknight And we don't know how much effort each user is going to need to go through to fix deprecation breakages
16:52 whiteknight pmichaud_: exactly. And the only way we know how much information is "sufficient" to bring a soft fail is to get users involved in the dialog
16:52 pmichaud_ (no, I don't know what "fail softly" looks like in this situation.  I simply use the term to say "we need a better mechanism of handling deprecation fails rather than assumign they don't happen")
16:52 whiteknight and since we don't know which users specifically are using which features, we need to broadcast
16:53 pmichaud_ broadcast is fine.  It wouldn't have helped in the last two deprecation fails.
16:54 pmichaud_ fwiw, I *did* see the commit and messages that indicated that 't' would be going away.
16:54 pmichaud_ it didn't occur to me that Rakudo would be affected.
16:54 redicaps left #parrot
16:55 pmichaud_ (because I'm not intimately familiar with every aspect of every piece of code that goes into Rakudo and Rakudo Star)
16:55 ambs seen coke?
16:55 aloha coke was last seen in #parrot 4 hours 11 mins ago joining the channel.
16:55 darbelo left #parrot
16:55 whiteknight pmichaud_: I suspect it would have helped. If we sent out an email to parrot-users saying NCI was going to change, jnthn might have seen that and said "I use NCI, I could use some more information about this"
16:55 ambs seen Coke_ ?
16:55 aloha Sorry, I haven't seen Coke_ .
16:55 ambs ahaha
16:56 whiteknight or sorear might have seen it
16:56 whiteknight and then we would have been able to give those guys information tailored to them, in a more timely manner
16:57 pmichaud_ I'm saying a mail did at least go out to parrot-dev (or the commits list), because I did see it.
16:57 pmichaud_ I presume jnthn++ monitors that as well.
16:57 whiteknight I don't even monitor the commits list :) I can't expect any of our users to be reading that and filtering out garbage from it
16:57 whiteknight at least parrot-users has lower traffic and could be more focused and noise-free
16:57 whiteknight parrot-dev too
16:58 pmichaud_ fair enough
17:00 pmichaud_ ah, I know where I saw it.  In the trac ticket.
17:01 whiteknight it takes a certain familiarity with the code to even recognize that a failure would have been caused by NCI signature changes. At least, I hope so
17:01 darbelo joined #parrot
17:02 pmichaud_ right.  which is why I think the "broadcast" approach won't significantly reduce the number of deprecation fails
17:02 whiteknight I'm not trying to be combative here, I'm sincerely looking to help alleviate these problems
17:02 pmichaud_ because it's only helpful if it happens to reach the person familiar enough with the code to say "oh, that could be a problem"
17:02 pmichaud_ (and that person has to not be distracted with other things)
17:05 pmichaud_ I'm going to lunch soon; but I think a message from jnthn++'s original post says it best:
17:05 pmichaud_ "I'm fine with
17:05 pmichaud_ > deprecations if I'm given a clue what to do to get things wroking again. But
17:05 pmichaud_ > a removal of a feature used by *Perl 6 database access* with no instructions
17:05 pmichaud_ > or updated examples that I can find, or maybe not even an actual
17:05 pmichaud_ > replacement?"
17:06 pmichaud_ we're fine if the deprecation fails happen.  but give us some help when they do happen.
17:06 darbelo left #parrot
17:06 whiteknight pmichaud_: okay. We'll do some thinking and discussing on our end and try to come up with some fixes
17:06 darbelo joined #parrot
17:08 plobsing jnthn__: how does zavolaj unwrap NativeArray as a parameter to hand off the inner $!unmanaged to NCI?
17:11 JimmyZ left #parrot
17:14 pmichaud_ plobsing: I'm not completely familiar with zavolaj but will try to help figure it out
17:14 plobsing I'm basically looking to manipulate the arguements (capture?) that gets passed in.
17:15 plobsing to be able to pass the NativeArray wrapper as an argument, I'd assume zavolaj would do similar, but it does not appear to do that
17:15 plobsing unless there's magic I don't see
17:18 pmichaud_ pass the NativeArray as an argument to the NCI func?  I don't think that happens
17:18 plobsing ok
17:18 sorear whiteknight: what might I have seen?
17:19 whiteknight sorear: deprecation notices on parrot-user
17:19 whiteknight sorear: sorry about the name-drop. I was just using you as an example
17:20 pmichaud_ oh, I could be wrong
17:20 pmichaud_ looking
17:21 plobsing it seems like something you'd want to do (pass a value returned from a C function to a C function), but I don't see the mechanism to do it
17:21 plobsing if it doesn't exist, that's fine
17:27 pmichaud_ I think that values returned from C functions get cast into Rakudo-equivalent types
17:28 pmichaud_ I don't know that we ever pass NativeArrays as argument to C functions (I could be very wrong about that)
17:30 Coke_ I am deep in review. checking /code/ with a regular expression is the wrong way to find deprecations. the right way is to add assertions (perhaps even the kind that go away in an optimized build) that are triggered at runtime.
17:31 pmichaud_ oh, there must be some way of doing it in order for the sqlite3 example to someday work
17:31 pmichaud_ but that's the only example that I see that would want to pass a NativeArray to C func
17:32 pmichaud_ (and it's listed as "not working")
17:33 bluescreen left #parrot
17:34 pmichaud_ yeah, looks like "doesn't exist" to me.
17:34 Coke_ pmichaud_: I feel your pain, and wish I had more tuits to make parrot suck less.
17:34 Coke_ but for now, I'll just commiserate and bemoan the near death of partcl. ;)
17:35 pmichaud_ death of partcl makes me sad.  Maybe I should do something about that :)
17:37 Coke_ It's only mostly dead.
17:37 Coke_ (most of the actual parrotbugs/deprecations/changes have been avoided. Though I haven't tried to run it lately...)
17:38 Coke_ I don't have easy access to a dev box atm but will check when I get home.
17:38 Coke_ (and, code always appreciated.)
17:39 Coke_ (runtime assertions - we have parrot -w, and I added code to warn about deprecated ops. warning about other deprecated things is also pretty doable.)
17:39 dodathome joined #parrot
17:40 benabik Coke++
17:41 * benabik is still running at a tuit shortage, or would help.
17:41 darbelo_ joined #parrot
17:42 smash left #parrot
17:45 darbelo left #parrot
17:46 Coke_ did that NCI change end up in a release?
17:46 Coke_ (worse, a supported release?)
17:46 whiteknight Coke_: no, I think it's recent
17:47 cotto_work last few days iirc
17:47 Coke_ April 22, 2011
17:48 Coke_ (from the commit link in jnthn's email.)
17:48 Coke_ looks like the release was 4/19? excellent. easy peasy.
17:49 cotto_work dukeleto: Is it a good time to talk about M0?
17:50 dukeleto cotto_work: for a bit, yes.
17:50 cotto_work dukeleto: ok.  What's your understanding of what the binary version of the bytecode segment needs to contain?
17:51 * Coke_ wonders how this discussion could have gotten any further than "oh, right, we removed something and didn't give a replacement right away."
17:51 Coke_ "let's fix that immediately and then figure out the upgrade path before we do that again."
17:51 dukeleto cotto_work: well, each line of M0 source should map to a binary representation
17:52 cotto_work sure
17:53 dukeleto cotto_work: when actually converting from the textual representation to the binary, we look up the opcode name and replace it with the op number
17:53 cotto_work the op and its three arguments, each of which is a byte
17:53 dukeleto cotto_work: perhaps I was misunderstandig if the 3 arguments need to be processed in some way
17:54 dukeleto cotto_work: do the raw integer offsets go directly into the binary, or do we have to look up variables in the variable table, and replace them with constants?
17:54 cotto_work dukeleto: the only processing is to convert values like "I0" or "S99" into their equivalent int values
17:54 pmichaud_ Having thought about this some:  Passing C-strings to NCI functions seems like such a common use case that I'm surprised that Parrot isn't supporting it directly and natively.
17:55 cotto_work dukeleto: the raw offsets go directly into bytecode
17:55 davidfetter joined #parrot
17:56 dukeleto cotto_work: yes, after thinking about it some more, I came to that realization after I asked you about it
17:56 dukeleto cotto_work: good to hear confirmation on that. That makes it a lot easier.
17:56 cotto_work dukeleto: glad to hear it
17:57 dukeleto cotto_work: the assembler is much closer to done than i thought
17:58 cotto_work pmichaud_: very surprising
17:59 * dukeleto has ssh access to the parrot.org vm now
17:59 dukeleto osuosl++
18:00 davidfetter dukeleto, groovy. we're about a week out from the PL summit. got anything to add?
18:05 dukeleto davidfetter: nope
18:06 davidfetter might you have anything to add before then?
18:06 dukeleto davidfetter: nope. i have given you my 2 cents
18:07 dalek TT #2111 created by whiteknight++: new_s and new_s_i opcodes
18:07 dalek TT #2111: http://trac.parrot.org/parrot/ticket/2111
18:08 davidfetter dukeleto, i'm asking because while you were giving it, you mentioned looking into plparrot.c and trying to give yourself a case of PTSD^W^W^W^W^W^Wrecall things that should have been available as APIs
18:10 dukeleto davidfetter: in general, frameworks for PL's to use for caching and security would be nice. For instance, PL/Perl does very fancy caching at many layers. If PG had that in core, then all PL's could benefit from it
18:10 dukeleto davidfetter: PL/Parrot only mildly imitates the caching in PL/Perl
18:10 * davidfetter adds this to dukeleto's list of gripes
18:10 pmichaud_ Coke++  # message to parrot-dev re: NCI
18:13 pmichaud_ Coke++  # message to parrot-dev re: NCI, worth two karma
18:15 dukeleto davidfetter: as for security, pushing some of the security features of PL/Perl into a "pl security framework" could be something else to talk about
18:15 pmichaud_ 17:51  * Coke_ wonders how this discussion could have gotten any further than "oh, right, we removed something and didn't give a replacement  right away."
18:15 pmichaud_ 17:51 <Coke_> "let's fix that immediately and then figure out the upgrade path before we do that again."
18:16 davidfetter dukeleto, could you expand that a bit? what would such a framework look like?
18:16 davidfetter .oO(what does marsellus wallace look like?)
18:17 pmichaud_ Coke says what I was trying to say earlier.  When we report a problem, we'd like to see "ooops, a 'upgrade tax' mistake -- let's revert" instead of a lot of pushback about it.
18:21 dukeleto davidfetter: not sure. That is for you and the pl summit people to talk about :)
18:21 dukeleto davidfetter: but as a guide "emulate the security guards that pl/perl undertakes" and make it easier for other PL's to do similar things
18:21 davidfetter what marsellus wallace looks like?
18:22 dukeleto davidfetter: even if it is just good docs about "this is how you harden your PL"
18:22 dukeleto davidfetter: because, as you well know, there have been many gaping security problems in Postgres PL's in the past, particularly PL/Perl. CVE's and such
18:23 davidfetter ah, excellent point
18:23 davidfetter so you're thinking there should be APIs designated as "trusted" and "untrusted?"
18:23 davidfetter dukeleto, rather than having people figure out which is which and then implement same, however well?
18:24 rblackwe joined #parrot
18:24 dukeleto davidfetter: yeps. give people a framework. Throw PL authors a frickin' bone :)
18:25 davidfetter anything else bugging you?
18:26 dukeleto the twitter failwhale
18:26 * dukeleto goes afk
18:35 contingencyplan joined #parrot
18:53 dalek parrot: 9eab52a | Whiteknight++ | / (5 files):
18:53 dalek parrot: Merge branch 'master' of github.com:parrot/parrot
18:53 dalek parrot: review: https://github.com/parrot/parrot/commit/9eab52a1fd
19:02 ttbot Parrot 9eab52a1 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/4152
19:05 Coke_ we sure do get a lot more merge commits than I would expect.
19:07 [hercynium] joined #parrot
19:10 darbelo_ left #parrot
19:11 hercynium left #parrot
19:11 [hercynium] is now known as hercynium
19:11 darbelo joined #parrot
19:13 hercynium left #parrot
19:42 ShaneC joined #parrot
19:44 dalek Rosella: 05afcda | Whiteknight++ | src/string/String.winxed:
19:44 dalek Rosella: Add in some stub code for a new strings library
19:44 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/05afcdabf1
19:44 dalek Rosella: c9a93a6 | Whiteknight++ | setup.winxed:
19:44 dalek Rosella: Add in a tokenizer class which breaks a series of strings up into tokens based on cclass.
19:44 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/c9a93a6fbf
19:44 dalek Rosella: a612b95 | Whiteknight++ | src/ (2 files):
19:44 dalek Rosella: Add in two stub files that I twiddled around with a few months ago, which may turn into new libraries
19:44 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/a612b95d08
19:44 dalek Rosella: 51f09df | Whiteknight++ | src/string/CClassTokenizer.winxed:
19:44 dalek Rosella: Add missing tokenizer file
19:44 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/51f09df0ea
19:44 dalek Rosella: c5c98ce | Whiteknight++ | s (6 files):
19:44 dalek Rosella: fix setup script for merge
19:44 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/c5c98ce0f9
19:44 dukeleto msg plobsing please take a look at http://jitterbug.leto.net:3000/api​/build/parrot/c7e27f58d5f1c956bd9d​7018e7a08d200eee4b08/perl-v5.10.1 . do you know what is up?
19:44 aloha OK. I'll deliver the message.
19:47 ShaneC left #parrot
19:56 dalek Rosella/gh-pages: dfa5226 | Whiteknight++ | libraries/future.md:
19:56 dalek Rosella/gh-pages: mention new futures libraries
19:56 dalek Rosella/gh-pages: review: https://github.com/Whiteknig​ht/Rosella/commit/dfa5226ca9
20:00 cotto_work 11.25/11.24
20:00 aloha 1.0008896797153
20:00 dalek Rosella: 169f832 | Whiteknight++ | src/winxed/Distutils.winxed:
20:00 dalek Rosella: build winxed files without warnings
20:00 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/169f8326b7
20:01 dalek Rosella: 9db3019 | Whiteknight++ | src/winxed/Distutils.bootstrap.pir:
20:01 dalek Rosella: update distutils bootstrap
20:01 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/9db3019735
20:01 dalek Rosella: 6a1a973 | Whiteknight++ | VERSION:
20:01 dalek Rosella: add string to VERSION
20:01 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/6a1a973a59
20:04 dukeleto whiteknight: have you seen treehugger.js ? https://github.com/zefhemel/treehugger
20:05 whiteknight no
20:05 whiteknight oh, nice
20:08 whiteknight calling all rohit.
20:08 whiteknight :)
20:08 cotto_work that looks familiar
20:08 dukeleto could be useful for Javascript on Parrot
20:11 darbelo_ joined #parrot
20:11 cotto_work That's shiny.
20:13 whiteknight if we can get Javascript running on Parrot without too much axelgrease, that would be a powerful tool for other HLLs to use too
20:14 whiteknight if the Javascript standard library isn't too heavy, I hope it will be very useful
20:16 darbelo left #parrot
20:19 darbelo_ left #parrot
20:19 darbelo joined #parrot
20:24 ambs left #parrot
20:28 whiteknight left #parrot
20:38 mtk left #parrot
20:47 dodathome left #parrot
20:52 contingencyplan left #parrot
21:07 darbelo_ joined #parrot
21:12 darbelo left #parrot
21:17 cotto_work any objections to merging get-entropy?
21:19 dukeleto cotto_work: yes
21:19 pmichaud_ no objection here.
21:20 cotto_work dukeleto: ok.  What objection?
21:21 dukeleto cotto_work: has it been tested on solaris or bsd ?
21:21 cotto_work dukeleto: no, but wikipedia claims that both have /dev/urandom
21:21 cotto_work well, open and net
21:23 cotto_work freebsd also seems to
21:25 pmichaud_ my Nexus One has /dev/urandom.  :-)
21:25 dukeleto cotto_work: gonna kick off a test suite on freebsd
21:25 cotto_work dukeleto: awesome
21:27 bacek left #parrot
21:29 dukeleto cotto_work: is smolder working?
21:29 cotto_work dukeleto: looks like no
21:31 * dukeleto grumbles
21:31 dukeleto cotto_work: do you see that the get-entropy branch fails under jitterbug?
21:31 dukeleto cotto_work: it looks like some configure.pl junk is messed up
21:31 dukeleto cotto_work: http://jitterbug.leto.net
21:31 cotto_work dukeleto: I missed that
21:32 cotto_work It looks like jitterbug's running three instances of the build concurrently
21:34 cotto_work dukeleto: it does the same thing with plobsing's branch
21:34 tadzik what kind of machine build Rakudo in 8 seconds? /o\
21:34 cotto_work looks partially like a jitterbug bug
21:34 dukeleto tadzik: rakudo on jitterbug is messed up :)
21:35 cotto_work I suspect the buildsplosion results from the separate builds stepping on each other's feet
21:35 cotto_work dukeleto: same for whiteknight's branch
21:36 dukeleto cotto_work: yeah, something is going funky
21:36 dukeleto cotto_work: it is a problem with jitterbug. Parrot seems to find a lot of them :)
21:37 cotto_work dukeleto: excellent!
21:37 dukeleto cotto_work: jitterbug seems to test Perl code pretty well, but parrot has many tricks
21:37 dukeleto cotto_work: i am caching the git repo
21:38 dukeleto cotto_work: so we don't clone the git repo for every commit
21:38 bubaflub dukeleto: would being able to build parrot out of directory help in this case?
21:38 cotto_work dukeleto: quite sensible
21:38 cotto_work dukeleto: I remember that from your jitterbug talk
21:38 dukeleto cotto_work: but when a build explodes, i think i don't clean up properly in jitterbug
21:38 whiteknight joined #parrot
21:38 dukeleto cotto_work: usually, a "git clean -fdx" happens
21:39 dukeleto cotto_work: but i think some edgecase prevents that from happening
21:40 cotto_work dukeleto: should I consider merging safe if your FreeBSD tests pass?
21:41 dalek Rosella/path_refactor: 148e9a9 | Whiteknight++ | / (6 files):
21:41 dalek Rosella/path_refactor: perform the bulk of the refactor. Move the path-searching logic into a single function loop, and make the searchers more simple. We lose one test assertion for now, I need to decide if we still want that or not
21:41 dalek Rosella/path_refactor: review: https://github.com/Whiteknig​ht/Rosella/commit/148e9a93ad
21:41 dalek Rosella/path_refactor: 900124e | Whiteknight++ | src/path/Path.winxed:
21:41 dalek Rosella/path_refactor: more path cleanups
21:41 dalek Rosella/path_refactor: review: https://github.com/Whiteknig​ht/Rosella/commit/900124e3d2
21:43 dukeleto cotto_work: looks like the parrot build fails on openbsd (get-entropy) branch
21:43 lucian left #parrot
21:43 lucian_ joined #parrot
21:44 darbelo_ left #parrot
21:44 cotto_work dukeleto: thanks for catching it then!  Can you fix it or nopaste something for me to work with?
21:45 cotto_work dukeleto++
21:45 cotto_work I'm thinking I should add a fallback to /dev/random if urandom is absent
21:46 bluescreen_ left #parrot
21:50 dukeleto cotto_work: openbsd probably doesn't compile on master either. I doubt it is get-entropy's fault
21:51 cotto_work I was hoping for something to fix.  Whose fault is it?
21:51 dukeleto cotto_work: https://gist.github.com/971378
21:52 dukeleto cotto_work: nobody tests openbsd regularly. Hence the need for a jitterbug instance or smoker on openbsd
21:52 dukeleto cotto_work: those are the first errors, and then everything bombs
21:52 lucian joined #parrot
21:52 cotto_work may be an old gcc thing
21:53 dukeleto cotto_work: yeah, it might not understand __attrribute_notnull
21:53 dukeleto cotto_work: my freebsd box is hosed for now. can't test on it
21:54 cotto_work well nuts
21:54 cotto_work I guess I'll have to merge
21:56 lucian_ left #parrot
21:58 cotto_work done
21:58 dalek parrot: 658fd0a | cotto++ | / (8 files):
21:58 dalek parrot: Merge branch 'get-entropy'
21:58 dalek parrot: review: https://github.com/parrot/parrot/commit/658fd0a765
22:12 * dukeleto is starting to daydream in M0 bytecode. Can't decide if that is good or bad.
22:14 davidfetter yes
22:15 cotto_work I guess that'll make it easier to generate.
22:17 ttbot Parrot 658fd0a7 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/4478
22:17 cotto_work same as I see on my windows machine
22:19 * cotto_work tries to manually rebase again
22:23 cotto_work C:\src\parrot-mingw/src/nci_test.c:416: undefined reference to `_imp__Parrot_str_free_cstring'
22:41 Coke left #parrot
22:41 Coke joined #parrot
22:47 cotto_work 6f0cfa824ff117c6731ab47320e0375402f14e80 is the first bad commit
22:47 cotto_work msg bacek 6f0cfa824ff117c6731ab47320e0375402f14e80 is what breaks the mingw build for me
22:47 aloha OK. I'll deliver the message.
22:48 Coke left #parrot
22:48 Coke joined #parrot
23:01 Anxuiz joined #parrot
23:24 davidfetter left #parrot
23:25 whiteknight Rosella, which has a hell of  lot more code, builds faster than Plumage does
23:25 davidfetter joined #parrot
23:26 cotto_work winxed is nice like that
23:38 davidfetter left #parrot
23:46 rurban_ joined #parrot
23:49 davidfetter joined #parrot
23:50 rurban left #parrot
23:50 rurban_ is now known as rurban

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

Parrot | source cross referenced