Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2016-01-26

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:05 leont joined #perl6-toolchain
01:25 lizmat joined #perl6-toolchain
03:39 cognominal joined #perl6-toolchain
06:54 domidumont joined #perl6-toolchain
07:00 domidumont joined #perl6-toolchain
07:24 domidumont joined #perl6-toolchain
07:43 FROGGS joined #perl6-toolchain
09:43 JimmyZ joined #perl6-toolchain
09:59 leont joined #perl6-toolchain
10:51 domidumont joined #perl6-toolchain
10:53 domidumont joined #perl6-toolchain
13:11 Zoffix joined #perl6-toolchain
13:52 Zoffix left #perl6-toolchain
14:49 ugexe joined #perl6-toolchain
14:50 perlpilot joined #perl6-toolchain
14:52 ugexe although im really trying to hunt down why when module A tries to launch a proc that uses same lib/source (think self test) it freezes (unless the directory its testing is moved so as not to be the same path/copy im running it as)
14:54 ugexe i expected a circular loading error or failure due to locks (if i expected it to fail at all) but its just frozen
14:59 ugexe it is def precomp related though. if i run the code that freezes and in another terminal try to manually run `prove` on the test it also freezes. if i kill the frozen process the `prove` command instantly unfreezes (presumably waiting for precomp to do something) and finishes
15:08 ugexe i tried deleting the lib(/.precomp?) folders while its frozen but that does not affect anything
15:08 ugexe only killing the original process
15:11 ugexe i can debug further, but im not sure if i should be looking at the locks or the loading
15:39 nine don't waste your time on this
15:40 nine The issue is that the precomp directory is locked during loading of a precomp file. When this precomp file launches a process from its main line, this new process tries to take the same lock when loading precomp files from the same store.
15:43 nine You're now gonna ask why the hell this is no shared (read) lock. Sad answer is: upgrading a read file lock to a write lock is racy on POSIX (jay!) and there doesn't seem to be a platform independent way to do this. At least none that I could find.
15:44 nine https://github.com/rakudo/rakudo/commit/67f925995086e8d54423a5d275e39d5a577e8e00
16:09 ugexe is there a way i can detect it will happen, or a hack to disable it from happening (preferably only when i know it will happen)?
16:26 nine I presume the best way to work around this would be to not start processes during a modules main line but move the code into some init function that's called at run time
16:37 ugexe heh i found a decent workaround and its related to the -I dir thing i mention above. by invoking the original process with `-Ixxx` it will use xxx/.precomp as its precomp dir, and the spawned child proc uses the default lib/.precomp which is now free
16:38 ugexe `-Ixxx -Ilib`
16:41 nine It's certainly a workaround :)
16:43 ugexe no one will know if it look legits with -Iblib -Ilib
16:54 jdv79 i admit i've only played with file locking a few times for real but i can't believe there isn't a way
16:56 nine jdv79: any idea would be greatly appreciated :)
18:19 Kassandry joined #perl6-toolchain
18:30 FROGGS joined #perl6-toolchain
18:34 domidumont joined #perl6-toolchain
19:04 jdv79 sqlite does a cute little lock dance.  https://github.com/mackyle/sqlite/blob/0f601407890d11f5fd6ffa66b8d3e93a9ae1502c/src/os.h
19:04 jdv79 not sure if that would be a good idea here though
19:05 domidumont joined #perl6-toolchain
19:07 domidumont joined #perl6-toolchain
19:26 [Coke] would be nice if all our core tools used the same bug system so we could transfer tickets from, say, rakudo to moarvm.
19:31 perlpilot [Coke]: +1  (is RT the least-worst?)
19:32 hoelzro I would also prefer MoarVM bugs going into RT
19:33 [Coke] I strongly dislike RT. I'd rather they moved to github.
19:34 hoelzro how easy is it to transfer a ticket from one GH project to another?
19:34 hoelzro I'm not a huge fan of RT; I just happen to strongly dislike GH issues myself =)
19:35 hoelzro either way, I would rather have both issues live in GH than remain separate
19:35 [Coke] mmm, they all suck.
19:36 [Coke] github has an API that might let us do it.
19:36 hoelzro mhmm
19:36 hoelzro andy lester wrote an RT → GH issues porter
19:36 hoelzro for parrot
19:37 hoelzro so that part's easy
19:37 * hoelzro knocks on wood
19:37 [Coke] I think you mean trac -> GH
19:37 hoelzro er, you're absolutely right
19:37 [Coke] because first I transferred them from RT to trac.
19:37 [Coke] which is why I'm never moving tickets between systems again. :)
19:37 hoelzro so we just transfer rakudo RT tickets to trac, then use Andy's script =P
19:37 hoelzro </joke>
19:37 [Coke] I'm just complaining about the imperfect world in which we find ourselves.
19:38 jdv79 trac.  that didn't last long.  lets use bugzilla!
19:38 hoelzro if no one complained, everyone would just stay unhappy =)
19:38 hoelzro silently
19:39 hoelzro does GH support attachments? iirc they only support images as attachments
19:40 jdv79 actually isn't jira the new enterprisey hotness?  lets use that.
19:41 perlpilot joined #perl6-toolchain
19:42 [Coke] I use jira at dayjob. It would be a step up for me compared to the RT interface.
19:42 [Coke] but it ain't free.
19:42 hoelzro I thought it was for OSS?
19:43 * perlpilot uses jira at $work too
19:44 hoelzro I think if we moved from RT → GH, the biggest things I would miss is issue dashboards and attachments
19:44 MadcapJake when installing a module, is the source code kept somewhere?
19:44 perlpilot https://www.atlassian.com/software/views/open-source-license-request/
19:44 perlpilot huh ... never knew that.
19:45 [Coke] RT's issue dashboards don't do much for me. maybe I'm not using them right.
19:48 hoelzro [Coke]: I just have two - issues I've filed (which GH provides), and bookmarked issues
19:48 hoelzro I really like the latter
19:57 nine How well does GH do with > 1000 issues?
19:57 nine _open_ issues that is
19:59 nine Because that's where RT really starts becoming useful despite being a help desk system much more than a development tool.
20:00 [Coke] "maybe we wouldn't have 1000 open tickets if we had a way to organize them to work on them" :)
20:00 [Coke] but, like I said, not really stumping to move existing tickets.
20:03 nine No, the only way to get rid of the 1000 tickets is having more people working to reduce them :)
20:04 perlpilot Better to start with a clean-ish slate at the 6.c release though (IMHO)
20:15 leont joined #perl6-toolchain
21:44 hankache joined #perl6-toolchain
21:59 jdv79 ranguard: around?  where's the eco to cpan code again?

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary