Parrot 3.3.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today | trac accounts are wonky; talk to cotto, coke or whiteknight if you have trouble
Set by moderator on 10 May 2011.
00:00 bluescreen__ joined 00:04 benabik joined 00:25 TiMBuS left 00:26 TiMBuS joined 00:27 athomason left
cotto_work bacek_at_work: manual bisect result is nonsensical and my attempts to automatedly bisect with cmd are making me insane. 00:28
whiteknight Insanity: it's how nature tells you WHARBLEGARBLE 00:29
00:31 athomason joined
cotto_work bash looks incredibly friendly all of a sudden 00:37
whiteknight I've always felt like people who develop console and their command syntax must be special kinds of people 00:41
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:48
atrodo cotto_work++ # Well volunteered 00:49
cotto_work um, no
unless by "implement", you mean "install cygwin" 00:50
atrodo wfm
00:57 kid51 joined 01:06 kid51 left
sorear Has OSUOSL talked about what happened to trac yet? 01:10
whiteknight sorear: what I've heard is basically what we already guessed
smolder ate all available memory, the VM crashed, files got corrupted, etc 01:11
I think that file was probably just in an unlucky sector
01:17 mtk left 01:19 alester left
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:19
atrodo Wow, that's rather amazing 01:20
cotto_work nm. looks like there was a stray git.exe running 01:21
poor thing
01:24 mtk joined
Coke_ (shell programming on windows) I find JS (invoked via cscript) quite tolerable. 01:54
02:00 bluescreen_ left, bluescreen__ left, bluescreen left 02:02 whiteknight left 02:05 cotto joined
cotto ~~ 02:11
02:14 kid51 joined
kid51 So tonight my iBook crashed twice, both times on what may be an infected email. 02:15
And after those crashes, Parrot now PASSes make test on Darwin/PPC.
go figure.
cotto kid51, best virus ever 02:16
btw, does that machine have /dev/urandom?
need to go offline; will check irclog
02:16 cotto left
kid51 plobsing ping 02:16
02:17 woosley joined
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.
plobsing kid51: pong 02:25
dalek rrot: 420e2a1 | plobsing++ | tools/dev/nci_thunk_gen.pir:
throw error for unsupported types
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
I would have just used List::MoreUtils, but it doesn't appear to be in core
kid51 But our current codingstd precludes use of sub prototypes. A couple of years back we went through and pulled them out. 02:27
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
And I, for one, would vote for that.
But, in the meantime, I think we should stick to our codingstds.
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:29
moderator Parrot 3.3.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Trac accounts should be working properly again; talk to cotto, coke or whiteknight if you have trouble 02:30
dalek rrot: 039c0ed | plobsing++ | config/gen/opengl.pm:
avoid sub prototype

standards win out over expressivety		 02:32
ttbot Parrot 420e2a15 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/3662 02:35
02:35 cotto joined
cotto ~~ 02:37
dukeleto, thanks for getting the trac passwords back to normal 02:41
dukeleto++
ttbot Parrot 039c0edc MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/3701 02:44
kid51 must sleep 03:16
03:16 kid51 left
atrodo alright, now that i'm done with that distraction, maybe i can actually get work on ipfy done 03:17
plobsing atrodo: care to share what you have planned? 03:20
atrodo plobsing: Nothing earth moving. Cleanup mostly
plobsing atrodo: any chance you could figure out how to smooth that noise?
03:21 jsut_ joined
atrodo major change would be a meta config file that gets pulled and multiple branches 03:21
plobsing> Probably better tests and more data
03:21 jsut left
atrodo Going to try it on a different machine that does less, but it's also much older 03:21
dalek rrot: 17a997e | plobsing++ | / (2 files):
add support for long double NCI parameters

long doubles are potentially larger than parrot-native floatvals. this may to undesirable truncation. You have been warned.		 04:04
rrot: ec159d2 | plobsing++ | config/gen/config_h/config_h.in:
keep track of sizeof (long long) if the platform has a long long type
rrot: 40d2607 | plobsing++ | / (2 files):
add long long support to NCI

long long is potentially larger than the parrot-native intval. this may lead to undesired truncation. furhter, long long is a non-standard (but common) type and may not be present on all platforms. using this type reduces the portability of your code. YOU HAVE BEEN WARNED!
rrot: c7e27f5 | plobsing++ | / (2 files):
add 8, 16, 32, and 64 bit NCI argument types

64 bit integers may be larger than parrot-native intvals. this may lead to undesirable truncation. 64 bit integers are only available where the underlying C compiler provides them. using this type may make your code less portable. YOU HAVE BEEN WARNED!
rrot/get-entropy: 898cbac | cotto++ | config/gen/makefiles/root.in:
add Makefile dependencies for entropy.c
benabik plobsing: A big warning somewhere in the documentation would be better than one in a commit message. :-/ 04:06
benabik hopes there is documentation for NCI somewhere. 04:07
plobsing benabik: you can make your hopes a reality
cotto The best person to document something is the one who's learning it as he goes. 04:08
though it's usually easier for whoever wrote it in the first place
plobsing I will happily answer questions regarding NCI, especially for people looking to document it. 04:13
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 tt.taptinder.org/cmdinfo/3802
benabik bubaflub++ 04:15
04:16 theory left
dalek TT #1182 closed by plobsing++: Add 'long long' to types supported by NCI 04:17
TT #1182: trac.parrot.org/parrot/ticket/1182
04:39 bubaflub left
dalek rrot: 4acf951 | plobsing++ | config/gen/opengl.pm:
generate opengl bindings which were blocked on TT #1182
 04:45
cotto dukeleto, ping 04:46
ttbot Parrot 4acf9516 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/3978 04:58
dalek rrot/m0-prototype: 02b13b2 | cotto++ | src/m0/m0_interp.pl:
add dummy implementations of all ops to the M0 interp
 05:13
05:20 Coke_ left, Coke_ joined 05:21 birdwindupbird joined 05:37 birdwindupbird left 05:42 jrtayloriv joined 06:22 JimmyZ joined 06:25 JimmyZ left 06:28 rurban_ joined 06:32 rurban left, rurban_ is now known as rurban 06:54 cotto left 07:01 mj41 joined 07:08 jrtayloriv left 07:37 contingencyplan left 07:44 ligne joined 07:45 ligne left 07:46 rurban_ joined 07:48 rurban left, rurban_ is now known as rurban 08:40 ShaneC joined
jnthn__ Anybody know what replacd "t" NCI parameter type? 08:56
09:02 macroz joined 09:04 ShaneC left 09:05 mtk left 09:11 mtk joined 09:16 JimmyZ joined
bacek_at_work jnthn__, nothing. And I actually will miss it. 09:16
jnthn__, ask plobsing. He is mastermind of this deprecation. 09:21
09:22 jsut joined
jnthn__ bacek_at_work: :( 09:24
bacek_at_work: He broke so much in doing that. 09:25
Like, most of useful NCI on Perl 6.
plobsing--
Could just revert it. 09:26
09:27 jsut_ left
jnthn__ None of the Parrot examples that used it have been updated either. 09:40
The only thing the deprecation notice mentions is use from C land, which isn't our use case.
github.com/parrot/parrot/commit/75...thunks.nci 09:44
That just ripped out all uses, not updated them to do things in a better way! 09:45
10:02 woosley left 10:08 JimmyZ left
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:32
10:34 sjn left 11:02 Psyche^ joined 11:07 Patterner left, Psyche^ is now known as Patterner
jnthn__ bacek: done so 11:24
bacek jnthn__, ok :) 11:25
dalek p: 34e9e7c | bacek++ | src/pmc/sixmodelobject.pmc:
Make compiler little bit more happy.
p: ba5200b | bacek++ | src/ops/nqp.ops:
Add couple more write_barriers when we poke into DispatcherSub directly.
11:34 UltraDM joined, darbelo joined
jnthn__ oh noes, nci_thunk_gen.pir doesn't work on Win32 :/ 11:34
atrodo That seems convenient 11:37
jnthn__ meh, think I give up on NCI stuff for now... :/
atrodo probably for the best 11:38
jnthn__ <- unimpressed 11:39
11:50 JimmyZ joined 11:53 Coke left, Coke joined 11:59 macroz left 12:10 mj41 left 12:11 bluescreen joined 12:13 Coke left 12:14 Coke joined 12:20 woosley joined 12:22 JimmyZ left 12:23 bluescreen left, bluescreen joined 12:31 Coke left, Coke joined 12:33 ambs joined 12:37 dod left 12:44 Coke left, Coke joined 12:47 smash joined
smash hello everyone 12:47
Coke_ hio. 12:48
13:06 whiteknight joined 13:07 bubaflub joined
dalek p: 509350b | moritz++ | t/setting/01-resizablepmcarray.t:
[t/setting] delete an outdated test
 13:10
13:11 bluescreen_ joined 13:14 JimmyZ joined
dalek p: ad31d07 | jonathan++ | src/how/NQPClassHOW.pm:
Forbid classes inheriting from themselves.
 13:25
whiteknight good morning, #parrot
JimmyZ good morning whiteknight 13:26
whiteknight hello JimmyZ. How are you doing today?
13:29 bluescreen_ left
JimmyZ whiteknight: not too bad, though business is slow 13:29
13:30 bluescreen left 13:44 bluescreen_ joined, bluescreen joined 14:08 UltraDM left 14:12 bluescreen left 14:15 bluescreen_ left 14:16 woosley left 14:17 lucian joined
pmichaud I don't suppose the profiling runcore and tools are getting any love anytime soon. 14:17
is there a way in the cachegrind tools to determine how many times a particular function has been called? 14:21
14:27 bluescreen joined, bluescreen_ joined
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:31
pmichaud: I'm not aware of a way to use valgrind to get information about PIR-level subs 14:32
14:41 hercynium joined 14:46 alester joined 14:49 cotto joined
pmichaud I meant for C-level subs 14:54
(or PIR-level subs)
just knowing the number of times certain C-level subs get called would be useful to me 14:55
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)
more precisely, I don't know how to view call counts in kcachegrind
cotto ~~
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.
pmichaud oh, nm 14:59
it's right there
hmmm
so, I guess my questions becomes: is there a way to get those values via command line (e.g., callgrind_annotate)? 15:01
callgrind_annotate seems to just give Ir counts
15:04 theory joined
cotto any objections to merging get-entropy? 15:06
pmichaud Can I object after it's merged? ;-)
cotto let's find out
pmichaud did anyone test the branch with rakudo? 15:07
if no, would you like me to do so?
cotto d'oh
I'll do that now
pmichaud I can test also.
cotto I'd be highly surprised if it caused anything other than higher-quality randomness though.
pmichaud me also, but surprises are what we want to avoid
cotto yes 15:08
plobsing cotto: I have P(objection) = 0.1. Are you feeling lucky?
cotto consults the get-entropy branch 15:09
looks like I do 15:10
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.
pmichaud Hmm.
whiteknight I think the deprecation notice for those signature strings was for direct removal
I have to go back and look, but I don't remember a replacement being specified
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.
whiteknight There is an equivalent, pcre bindings use it
pmichaud does that work for Rakudo, written in PIR?
atrodo can someone remind me what t was?
jnthn__ The examples weren't updated, and the mysql signatures were just tossed.
whiteknight plobsing suggests so, using NCI
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
jnthn__ er, *some* of them were...
atrodo whiteknight> thanks
cotto rakudo build looks good, running spectest_regression
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
plus, Parrot STRING might contain nulls internally, which causes havoc in c libraries
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.
dukeleto ~
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:16
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 p: bb72006 | moritz++ | src/ (2 files):
compile methods to anonymous PIR subs
jnthn__ (Discovered these today...didn't get chance to ticket them yet...) 15:19
pmichaud what ticket is all of this covered under?
plobsing pmichaud: that system requires participation of downstream developpers, which rarely if ever seems to happen these days
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)
I'm curious what ticket covers the deprecation. 15:21
plobsing TT #1931
pmichaud that ticket isn't mentioned in api.yaml
(the api.yaml of 3.3.0 release)
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.
cotto It's in the current api.yaml
pmichaud I thought deprecations get noticed in supported releases.
whiteknight pmichaud: yes, it's been listed since at least 3.0.0 in deprecated.pod 15:23
jnthn__ afk
pmichaud where is deprecated.pod?
whiteknight it does not appear to have been moved to api.yaml for some reason, but it was in the older file
pmichaud: in the 3.0.0 tag
plobsing why did we move to api.yaml?
whiteknight plobsing: programmatic access
dukeleto plobsing: deprecations as data 15:24
plobsing: storing structured info in POD is dumb
plobsing I don't see why yaml is more desirable than POD
pmichaud "t manage null-padding in sugar layer
" (from #1931)
that doesn't seem particularly useful to a user. 15:25
dukeleto plobsing: DEPRECATED.POD had no format. It was free-form
cotto dukeleto, will you be online later today? I want to talk M0 but need to get ready for $dayjob soonish.
plobsing dukeleto: at least it was easy to read
dukeleto cotto: sure. will be on later.
cotto great
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?
jnthn__: i haven't backlogged yet. Is MiniDBI still between a rock and a hard place?
pmichaud plobsing: the ticket? or some other page?
dalek p: c9dd840 | moritz++ | / (2 files):
install hash() constructor, make t/setting/02-hash.t pass again
cotto t/spec/S03-operators/relational.t .............................. Failed 6/110 subtests 15:27
plobsing trac.parrot.org/parrot/wiki/ParrotD...meterTypes
pmichaud dukeleto: yes.
dalek p: ad4a452 | moritz++ | .gitignore:
ignore .so files
cotto should that be a concern?
pmichaud cotto: all tests successful here.
cotto: I'm guessing you have an older copy of rakudo.
(i.e., from before the NaN fixes to relops)
cotto so I do
dukeleto plobsing: that page does not provide sufficient information for Perl 6 devs to fix breakage from 't' changes
plobsing: you gave more info in your email to parrot-dev, but it still is not clear *exactly* how code should change 15:28
15:28 darbelo_ joined
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
pmichaud and although Rakudo might not need it -- that information really ought to be available for all of the parameter types that were removed
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
plobsing: i would say that is a failure on our part
15:30 darbelo left
dukeleto pmichaud: i agree with you 15:31
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
TimToady pity you can't make the omelet and *then* break the eggs...
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"
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
dukeleto TimToady: if only the universe were a reversible system...
whiteknight if a downstream user had read it before now, we would know whether the information was sufficient or not
pmichaud whiteknight: what wiki page -- I'm not able to find it.
dukeleto trac.parrot.org/parrot/wiki/ParrotD...meterTypes 15:33
pmichaud: ^^^
whiteknight pmichaud: that may be true, but nobody alerted us that enough information was not readily available
pmichaud is that linked from the ticket or deprecation notice?
atrodo dukeleto> If the world was reversible, my life would be much simplier
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
dukeleto pmichaud: linked from here trac.parrot.org/parrot/wiki/ParrotDeprecations 15:34
pmichaud also, that notice says deprecation for *3.6*
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
plobsing which means the removal occurs between 3.3 and 3.6
dukeleto pmichaud: kind of like the sum of all deprecation changes between major releases
pmichaud deprecation means "no longer supported". deprecation occurs prior to removal.
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
whiteknight the wiki page looks wrong. Deprecated.pod in 3.0.0 clearly says it's available for removal starting in 3.1
dukeleto we also have github.com/parrot/parrot/blob/mast...deprecator , which is an nqp script that uses api.yaml to look for deprecated code
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 ?
whiteknight having multiple sources of documentation (api.yaml, tickets, wiki) is not helpful if those sources are out of sync
pmichaud i.e., can I get a version of zavolaj that runs on 3.3.0 but doesn't use the 't' parameter?
plobsing dukeleto: how is that an improvement over the deprecations warning system?
dukeleto pmichaud: i think it will currently give you the link to that wiki page when it finds the NCI deprecation
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
plobsing: our dep warnings just give a warning, iirc
plobsing: api.yaml stores regexes, so it can be smarter when looking for deprecated code 15:39
plobsing but static analysis is inherently limited
dukeleto plobsing: sure. But that is a straw man.
pmichaud dukeleto: (love to hear feedback) you're hearing it. :)
whiteknight okay, we're getting off onto a tangent
dukeleto plobsing: we are trying to make something workable, not disprove the Riemann Hypothesis
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?
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
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
whiteknight pmichaud: if Parrot needs to revert something, that decision has to happen first
15:40 redicaps joined
pmichaud whiteknight: well, obviously we'd prefer to not make Parrot revert. 15:40
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
whiteknight pmichaud: we're in a grey area. Obviously the entry not appearing in api.yaml is a problem on our side
pmichaud dukeleto: it sounds useful, but I'm skeptical that it will actually work. :-)
dukeleto plobsing: is there any way you can use some of your extensive knowledge of NCI stuff to make zavaloj work again?
plobsing dukeleto: I'll have a go at it.
pmichaud dukeleto: a good test would be to run it on zavolaj and see if it offers up the warning
dukeleto pmichaud: sure. But remember, all progress is made by irrational people, as I am sure you know well :)
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)
dukeleto pmichaud: api.yaml was created specifically with that in mind
pmichaud dukeleto: I don't disagree with the fact that we can automate a lot more stuff.
I'm just not sure that the tool would've had any chance to find this particular deprecation.
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.
dukeleto pmichaud: yes, that would be lovely.
whiteknight I want to make it more clear in support_policy.pod that api.yaml is the definitive source of deprecation information
dukeleto whiteknight: sure. It isn't clear already?
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
I would be much happier not duplicating the list, but we have it so we need to be clear about it
pmichaud dukeleto: the code that zavolaj uses for signatures is github.com/jnthn/zavolaj/blob/mast...eCall.pm6. Would your tool have caught this? 15:45
if so, what would it have looked for?
dukeleto plobsing: perhaps we could add a test to zavolaj, and then the dedeprecator would see the test has deprecated code
pmichaud (line 63 is the one that violates the deprecation)
15:46 rurban_ joined
dukeleto pmichaud: no, that is quite hard to catch. But if there was a test for 't' specifically, we would have caught that 15:46
plobsing how many other instances of 't' would we also catch at the same time? 15:47
pmichaud ...what, report every.... what plobsing++ said
whiteknight it's fruitless to be arguing over the utility of the tool. It's obviously not going to be perfect in all situations
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"
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
dukeleto pmichaud: the tool is better than nothing. api.yaml is better than DEPRECATED.pod. Nothing is perfect.
15:48 rurban left, rurban_ is now known as rurban
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"
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
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
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.
pmichaud but before doing that, I'd like to know if deprecation warnings would've caught this in 3.3.0
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?
Parrot wants to make the ones that *are* possible to find, findable.
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
(more)
you can hardly fault us for not using the flag if it actually doesn't produce anything :-)
i.e., that seems like a circular sort of argument to me :)
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.
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
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
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:56
how many of Parrot's other tools are using the flag? 15:57
dukeleto pmichaud: i think you are talking into the wind
pmichaud I'm used to that, I guess. 15:58
I can stop.
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
dukeleto pmichaud: we aren't trying to break Rakudo on purpose, be sure of that. 15:58
wow, I guess I pissed off pmichaud. Awesome.
dukeleto feels accomplished for the morning
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.
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
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:00
And, how do we make sure we get the feedback to tell us whether the information we are providing is sufficient 16:01
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
tracwiki: updates to improve pain points experienced by recent zavolaj breakage
tracwiki: trac.parrot.org/parrot/wiki/HowToDe...ction=diff
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
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:03
Maybe we need to be sending deprecation notices to parrot-users for feedback and discussion 16:04
16:04 darbelo_ left
whiteknight of course, we have plenty of users not subscribed to that list 16:04
plobsing I think at some point, you need to accept that we'll never reach all users with our warnings 16:06
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
which is why I've put my ideas about how this might have been averted in a small update to the deprecation SOP
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
Everything else, as we make it, can be linked from api.yaml 16:11
dukeleto whiteknight: seems reasonable
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
dukeleto whiteknight: how about this: Email parrot-dev and parrot-users every time a new deprecation is added to api.yaml ?
whiteknight if we have multiple wiki pages, tickets, email archives etc we link them from api.yaml as they are generated
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
whiteknight: i think it could be a pretty simple tools/dev/announce_deprecation.pl script
cotto_work ~~
atrodo dukeleto> With a large "OMG WE'RE DEPRECATING STUFF!!!!11one1" in the subject 16:13
whiteknight dukeleto: okay, I like that
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
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:18
dukeleto whiteknight: ok, here is an idea 16:20
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
dukeleto and pmichaud_ had an enjoyable privmsg talking about stuff. All is well. 16:21
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??
it won't hold all of the data.
dukeleto pmichaud_: sure. perhaps "canonical nexus" ?
pmichaud_: nexus ~~ starting point, so I think we agree 16:23
atrodo nexus sounds cooler
pmichaud_ I already have a Nexus, and I don't want it to get deprecated. :-P 16:24
anyway, "nexus" is fine.
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
alester Trac doesn't have any other API?
dukeleto alester: not sure, but i doubt it. 16:25
cotto_work I'd love for trac to have an api.
pmichaud_ can I make a couple of proposals?
dukeleto pmichaud_: please do
alester pmichaud_: Yes, yes, I'll marry you!
dukeleto thinks Trac is good for ticket tracking and not much else 16:26
alester is as happy as a little girl.
pmichaud_ first, I'd like to see us create docs/project/deprecated.pod
in it, I'd like to see us document a process for deprecation
much like we do for release_manager_guide
1. Create a trac ticket
2. Add a notice to api.yaml
3. Document the replacement feature
4. Provide examples of how to modify code to work after deprecation takes effect 16:27
(most of this is already in docs/project/stability.pod, but not as a process)
docs/project/deprecated.pod can also contain the step-by-step guide for users who want to keep up with deprecations 16:28
1. Monitor api.yaml / mailing list / whatever for deprecations that might apply to you
2. Apply the modifications given in * to avoid the deprecation 16:29
etc.
mainly, let's have a deprecation checklist
plobsing we have a wiki page for deprecator procedure entitled "HowToDeprecate"
pmichaud_ I think it belongs in docs/project, then. 16:30
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
(or somewhere)
for example -- a link to the documentation explaining how to upgrade the code
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
16:32 darbelo left
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
that's clearly not a working strategy
dalek rrot: 557712a | dukeleto++ | NEWS:
Give NEWS some love
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)
cotto_work Maybe we need EverythingYouEverWantedToKnowAboutDeprecationsButWereAfraidToAsk
pmichaud_ and in some sense, I'm not sure that's even the issue
from a rakudo perspective, I don't mind so much that something broke (more)
it's that when we went to fix it.... we couldn't.
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
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.
dukeleto i think it comes down to parrot being more vocal and reminding people about deprecations
cotto_work hio darbelo
darbelo hio 16:36
pmichaud_ I think surprise is inevitable, on both sides.
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
dukeleto perhaps every release announcement/blog post should contain a "these important deprecations happened, here are the wiki pages about them" clause
whiteknight I would rather see us engage users in deprecation conversations, as opposed to deprecation process
pmichaud_ dukeleto: that wouldn't have helped in this case -- the deprecation was four months ago
dukeleto and emailing parrot-dev and parrot-users with every additional deprecation will reduce surprise
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
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?
pmichaud_ I'm thinking surprises may be inevitable
(more) 16:38
I'd like surprises to be fail-softly rather than "they never occur"
whiteknight Waiting is counter-productive if surprises are inevitable
pmichaud_ we have two very recent examples to work from
first, random number generation in Parrot
second, the deprecated 't' feature 16:39
cotto_work pmichaud_: what do you mean by "fail-softly"?
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
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
pmichaud_ "you should've seen the deprecation from 3.0.0"
"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
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:41
in this case, we need code to show how we can bring zavolaj up to date. 16:42
an example would help
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"
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
ttbot Parrot 557712a4 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/4089 16:45
cotto_work that's true 16:46
pmichaud_ it wasn't until I made noises about "deprecation fail" that it got "fixed" in Parrot.
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)
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
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
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)
(more)
whiteknight We had a wiki page, and from the perspective of the involved developers, it appeared sufficient
We don't know it's not sufficient until a user actually reads it
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' ?
whiteknight pmichaud_: none of the parrot devs
pmichaud_ I suspect only a few of the rakudo devs. Perhaps even only one.
whiteknight it's the darkpan problem. We don't and can't know what all our users are using
pmichaud_ right
which is why I'm after a fail softly approach
whiteknight And we don't know how much effort each user is going to need to go through to fix deprecation breakages 16:52
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
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")
whiteknight and since we don't know which users specifically are using which features, we need to broadcast
pmichaud_ broadcast is fine. It wouldn't have helped in the last two deprecation fails. 16:53
fwiw, I *did* see the commit and messages that indicated that 't' would be going away. 16:54
it didn't occur to me that Rakudo would be affected.
16:54 redicaps left
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?
aloha coke was last seen in #parrot 4 hours 11 mins ago joining the channel.
16:55 darbelo left
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_ ?
aloha Sorry, I haven't seen Coke_ .
ambs ahaha
whiteknight or sorear might have seen it 16:56
and then we would have been able to give those guys information tailored to them, in a more timely manner
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
I presume jnthn++ monitors that as well.
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
at least parrot-users has lower traffic and could be more focused and noise-free
parrot-dev too
pmichaud_ fair enough 16:58
ah, I know where I saw it. In the trac ticket. 17:00
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
17:01 darbelo joined
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
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"
(and that person has to not be distracted with other things)
I'm going to lunch soon; but I think a message from jnthn++'s original post says it best: 17:05
"I'm fine with
> deprecations if I'm given a clue what to do to get things wroking again. But
> a removal of a feature used by *Perl 6 database access* with no instructions
> or updated examples that I can find, or maybe not even an actual
> replacement?"
we're fine if the deprecation fails happen. but give us some help when they do happen. 17:06
17:06 darbelo left
whiteknight pmichaud_: okay. We'll do some thinking and discussing on our end and try to come up with some fixes 17:06
17:06 darbelo joined
plobsing jnthn__: how does zavolaj unwrap NativeArray as a parameter to hand off the inner $!unmanaged to NCI? 17:08
17:11 JimmyZ left
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.
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
unless there's magic I don't see
pmichaud_ pass the NativeArray as an argument to the NCI func? I don't think that happens 17:18
plobsing ok
sorear whiteknight: what might I have seen?
whiteknight sorear: deprecation notices on parrot-user 17:19
sorear: sorry about the name-drop. I was just using you as an example
pmichaud_ oh, I could be wrong 17:20
looking
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
if it doesn't exist, that's fine
pmichaud_ I think that values returned from C functions get cast into Rakudo-equivalent types 17:27
I don't know that we ever pass NativeArrays as argument to C functions (I could be very wrong about that) 17:28
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:30
pmichaud_ oh, there must be some way of doing it in order for the sqlite3 example to someday work 17:31
but that's the only example that I see that would want to pass a NativeArray to C func
(and it's listed as "not working") 17:32
17:33 bluescreen left
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.
but for now, I'll just commiserate and bemoan the near death of partcl. ;)
pmichaud_ death of partcl makes me sad. Maybe I should do something about that :) 17:35
Coke_ It's only mostly dead. 17:37
(most of the actual parrotbugs/deprecations/changes have been avoided. Though I haven't tried to run it lately...)
I don't have easy access to a dev box atm but will check when I get home. 17:38
(and, code always appreciated.)
(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
17:39 dodathome joined
benabik Coke++ 17:40
benabik is still running at a tuit shortage, or would help. 17:41
17:41 darbelo_ joined 17:42 smash left 17:45 darbelo left
Coke_ did that NCI change end up in a release? 17:46
(worse, a supported release?)
whiteknight Coke_: no, I think it's recent
cotto_work last few days iirc 17:47
Coke_ April 22, 2011
(from the commit link in jnthn's email.) 17:48
looks like the release was 4/19? excellent. easy peasy.
cotto_work dukeleto: Is it a good time to talk about M0? 17:49
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?
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
"let's fix that immediately and then figure out the upgrade path before we do that again."
dukeleto cotto_work: well, each line of M0 source should map to a binary representation
cotto_work sure 17:52
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
dukeleto cotto_work: perhaps I was misunderstandig if the 3 arguments need to be processed in some way
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
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.
cotto_work dukeleto: the raw offsets go directly into bytecode 17:55
17:55 davidfetter joined
dukeleto cotto_work: yes, after thinking about it some more, I came to that realization after I asked you about it 17:56
cotto_work: good to hear confirmation on that. That makes it a lot easier.
cotto_work dukeleto: glad to hear it
dukeleto cotto_work: the assembler is much closer to done than i thought 17:57
cotto_work pmichaud_: very surprising 17:58
dukeleto has ssh access to the parrot.org vm now 17:59
osuosl++
davidfetter dukeleto, groovy. we're about a week out from the PL summit. got anything to add? 18:00
dukeleto davidfetter: nope 18:05
davidfetter might you have anything to add before then? 18:06
dukeleto davidfetter: nope. i have given you my 2 cents
dalek TT #2111 created by whiteknight++: new_s and new_s_i opcodes 18:07
TT #2111: trac.parrot.org/parrot/ticket/2111
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:08
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
davidfetter: PL/Parrot only mildly imitates the caching in PL/Perl
davidfetter adds this to dukeleto's list of gripes
pmichaud_ Coke++ # message to parrot-dev re: NCI
Coke++ # message to parrot-dev re: NCI, worth two karma 18:13
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."
17:51 <Coke_> "let's fix that immediately and then figure out the upgrade path before we do that again."
davidfetter dukeleto, could you expand that a bit? what would such a framework look like? 18:16
.oO(what does marsellus wallace look like?)
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:17
dukeleto davidfetter: not sure. That is for you and the pl summit people to talk about :) 18:21
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
davidfetter what marsellus wallace looks like?
dukeleto davidfetter: even if it is just good docs about "this is how you harden your PL" 18:22
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
davidfetter ah, excellent point 18:23
so you're thinking there should be APIs designated as "trusted" and "untrusted?"
dukeleto, rather than having people figure out which is which and then implement same, however well?
18:24 rblackwe joined
dukeleto davidfetter: yeps. give people a framework. Throw PL authors a frickin' bone :) 18:24
davidfetter anything else bugging you? 18:25
dukeleto the twitter failwhale 18:26
dukeleto goes afk
18:35 contingencyplan joined
dalek rrot: 9eab52a | Whiteknight++ | / (5 files):
Merge branch 'master' of github.com:parrot/parrot
 18:53
ttbot Parrot 9eab52a1 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/4152 19:02
Coke_ we sure do get a lot more merge commits than I would expect. 19:05
19:07 [hercynium] joined 19:10 darbelo_ left 19:11 hercynium left, [hercynium] is now known as hercynium, darbelo joined 19:13 hercynium left 19:42 ShaneC joined
dalek sella: 05afcda | Whiteknight++ | src/string/String.winxed:
Add in some stub code for a new strings library
 19:44
sella: c9a93a6 | Whiteknight++ | setup.winxed:
Add in a tokenizer class which breaks a series of strings up into tokens based on cclass.
sella: a612b95 | Whiteknight++ | src/ (2 files):
Add in two stub files that I twiddled around with a few months ago, which may turn into new libraries
sella: 51f09df | Whiteknight++ | src/string/CClassTokenizer.winxed:
Add missing tokenizer file
sella: c5c98ce | Whiteknight++ | s (6 files):
fix setup script for merge
dukeleto msg plobsing please take a look at jitterbug.leto.net:3000/api/build/p...rl-v5.10.1 . do you know what is up?
aloha OK. I'll deliver the message.
19:47 ShaneC left
dalek sella/gh-pages: dfa5226 | Whiteknight++ | libraries/future.md:
mention new futures libraries
 19:56
cotto_work 11.25/11.24 20:00
aloha 1.0008896797153
dalek sella: 169f832 | Whiteknight++ | src/winxed/Distutils.winxed:
build winxed files without warnings
sella: 9db3019 | Whiteknight++ | src/winxed/Distutils.bootstrap.pir:
update distutils bootstrap
 20:01
sella: 6a1a973 | Whiteknight++ | VERSION:
add string to VERSION
dukeleto whiteknight: have you seen treehugger.js ? github.com/zefhemel/treehugger 20:04
whiteknight no 20:05
oh, nice
calling all rohit. 20:08
:)
cotto_work that looks familiar
dukeleto could be useful for Javascript on Parrot
20:11 darbelo_ joined
cotto_work That's shiny. 20:11
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:13
if the Javascript standard library isn't too heavy, I hope it will be very useful 20:14
20:16 darbelo left 20:19 darbelo_ left, darbelo joined 20:24 ambs left 20:28 whiteknight left 20:38 mtk left 20:47 dodathome left 20:52 contingencyplan left 21:07 darbelo_ joined 21:12 darbelo left
cotto_work any objections to merging get-entropy? 21:17
dukeleto cotto_work: yes 21:19
pmichaud_ no objection here.
cotto_work dukeleto: ok. What objection? 21:20
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
well, open and net
freebsd also seems to 21:23
pmichaud_ my Nexus One has /dev/urandom. :-) 21:25
dukeleto cotto_work: gonna kick off a test suite on freebsd
cotto_work dukeleto: awesome
21:27 bacek left
dukeleto cotto_work: is smolder working? 21:29
cotto_work dukeleto: looks like no
dukeleto grumbles 21:31
cotto_work: do you see that the get-entropy branch fails under jitterbug?
cotto_work: it looks like some configure.pl junk is messed up
cotto_work: jitterbug.leto.net
cotto_work dukeleto: I missed that
It looks like jitterbug's running three instances of the build concurrently 21:32
dukeleto: it does the same thing with plobsing's branch 21:34
tadzik what kind of machine build Rakudo in 8 seconds? /o\\
cotto_work looks partially like a jitterbug bug
dukeleto tadzik: rakudo on jitterbug is messed up :)
cotto_work I suspect the buildsplosion results from the separate builds stepping on each other's feet 21:35
dukeleto: same for whiteknight's branch
dukeleto cotto_work: yeah, something is going funky 21:36
cotto_work: it is a problem with jitterbug. Parrot seems to find a lot of them :)
cotto_work dukeleto: excellent! 21:37
dukeleto cotto_work: jitterbug seems to test Perl code pretty well, but parrot has many tricks
cotto_work: i am caching the git repo
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?
cotto_work dukeleto: quite sensible
dukeleto: I remember that from your jitterbug talk
dukeleto cotto_work: but when a build explodes, i think i don't clean up properly in jitterbug
21:38 whiteknight joined
dukeleto cotto_work: usually, a "git clean -fdx" happens 21:38
cotto_work: but i think some edgecase prevents that from happening 21:39
cotto_work dukeleto: should I consider merging safe if your FreeBSD tests pass? 21:40
dalek sella/path_refactor: 148e9a9 | Whiteknight++ | / (6 files):
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
sella/path_refactor: 900124e | Whiteknight++ | src/path/Path.winxed:
more path cleanups
dukeleto cotto_work: looks like the parrot build fails on openbsd (get-entropy) branch 21:43
21:43 lucian left, lucian_ joined 21:44 darbelo_ left
cotto_work dukeleto: thanks for catching it then! Can you fix it or nopaste something for me to work with? 21:44
dukeleto++ 21:45
I'm thinking I should add a fallback to /dev/random if urandom is absent
21:46 bluescreen_ left
dukeleto cotto_work: openbsd probably doesn't compile on master either. I doubt it is get-entropy's fault 21:50
cotto_work I was hoping for something to fix. Whose fault is it? 21:51
dukeleto cotto_work: gist.github.com/971378
cotto_work: nobody tests openbsd regularly. Hence the need for a jitterbug instance or smoker on openbsd 21:52
cotto_work: those are the first errors, and then everything bombs
21:52 lucian joined
cotto_work may be an old gcc thing 21:52
dukeleto cotto_work: yeah, it might not understand __attrribute_notnull 21:53
cotto_work: my freebsd box is hosed for now. can't test on it
cotto_work well nuts 21:54
I guess I'll have to merge
21:56 lucian_ left
cotto_work done 21:58
dalek rrot: 658fd0a | cotto++ | / (8 files):
Merge branch 'get-entropy'
dukeleto is starting to daydream in M0 bytecode. Can't decide if that is good or bad. 22:12
davidfetter yes 22:14
cotto_work I guess that'll make it easier to generate. 22:15
ttbot Parrot 658fd0a7 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/4478 22:17
cotto_work same as I see on my windows machine
cotto_work tries to manually rebase again 22:19
C:\\src\\parrot-mingw/src/nci_test.c:416: undefined reference to `_imp__Parrot_str_free_cstring' 22:23
22:41 Coke left, Coke joined
cotto_work 6f0cfa824ff117c6731ab47320e0375402f14e80 is the first bad commit 22:47
msg bacek 6f0cfa824ff117c6731ab47320e0375402f14e80 is what breaks the mingw build for me
aloha OK. I'll deliver the message.
22:48 Coke left, Coke joined 23:01 Anxuiz joined 23:24 davidfetter left
whiteknight Rosella, which has a hell of lot more code, builds faster than Plumage does 23:25
23:25 davidfetter joined
cotto_work winxed is nice like that 23:26
23:38 davidfetter left 23:46 rurban_ joined 23:49 davidfetter joined 23:50 rurban left, rurban_ is now known as rurban

Powered by Cro and the Raku® Programming Language.

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

Thank you!