Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec
Set by moderator on 25 January 2016.
00:05 leont joined 01:25 lizmat joined 03:39 cognominal joined 06:54 domidumont joined 07:00 domidumont joined 07:24 domidumont joined 07:43 FROGGS joined 09:43 JimmyZ joined 09:59 leont joined 10:51 domidumont joined 10:53 domidumont joined 13:11 Zoffix joined 13:52 Zoffix left 14:49 ugexe joined 14:50 perlpilot joined
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:52
i expected a circular loading error or failure due to locks (if i expected it to fail at all) but its just frozen 14:54
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 14:59
i tried deleting the lib(/.precomp?) folders while its frozen but that does not affect anything 15:08
only killing the original process
i can debug further, but im not sure if i should be looking at the locks or the loading 15:11
nine don't waste your time on this 15:39
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:40
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:43
github.com/rakudo/rakudo/commit/67...5a577e8e00 15:44
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:09
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:26
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:37
`-Ixxx -Ilib` 16:38
nine It's certainly a workaround :) 16:41
ugexe no one will know if it look legits with -Iblib -Ilib 16:43
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:54
nine jdv79: any idea would be greatly appreciated :) 16:56
18:19 Kassandry joined 18:30 FROGGS joined 18:34 domidumont joined
jdv79 sqlite does a cute little lock dance. github.com/mackyle/sqlite/blob/0f6...c/src/os.h 19:04
not sure if that would be a good idea here though
19:05 domidumont joined 19:07 domidumont joined
[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:26
perlpilot [Coke]: +1 (is RT the least-worst?) 19:31
hoelzro I would also prefer MoarVM bugs going into RT 19:32
[Coke] I strongly dislike RT. I'd rather they moved to github. 19:33
hoelzro how easy is it to transfer a ticket from one GH project to another? 19:34
I'm not a huge fan of RT; I just happen to strongly dislike GH issues myself =)
either way, I would rather have both issues live in GH than remain separate 19:35
[Coke] mmm, they all suck.
github has an API that might let us do it. 19:36
hoelzro mhmm
andy lester wrote an RT → GH issues porter
for parrot
so that part's easy 19:37
hoelzro knocks on wood
[Coke] I think you mean trac -> GH
hoelzro er, you're absolutely right
[Coke] because first I transferred them from RT to trac.
which is why I'm never moving tickets between systems again. :)
hoelzro so we just transfer rakudo RT tickets to trac, then use Andy's script =P
</joke>
[Coke] I'm just complaining about the imperfect world in which we find ourselves.
jdv79 trac. that didn't last long. lets use bugzilla! 19:38
hoelzro if no one complained, everyone would just stay unhappy =)
silently
does GH support attachments? iirc they only support images as attachments 19:39
jdv79 actually isn't jira the new enterprisey hotness? lets use that. 19:40
19:41 perlpilot joined
[Coke] I use jira at dayjob. It would be a step up for me compared to the RT interface. 19:42
but it ain't free.
hoelzro I thought it was for OSS?
perlpilot uses jira at $work too 19:43
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?
perlpilot www.atlassian.com/software/views/o...e-request/
huh ... never knew that.
[Coke] RT's issue dashboards don't do much for me. maybe I'm not using them right. 19:45
hoelzro [Coke]: I just have two - issues I've filed (which GH provides), and bookmarked issues 19:48
I really like the latter
nine How well does GH do with > 1000 issues? 19:57
_open_ issues that is
Because that's where RT really starts becoming useful despite being a help desk system much more than a development tool. 19:59
[Coke] "maybe we wouldn't have 1000 open tickets if we had a way to organize them to work on them" :) 20:00
but, like I said, not really stumping to move existing tickets.
nine No, the only way to get rid of the 1000 tickets is having more people working to reduce them :) 20:03
perlpilot Better to start with a clean-ish slate at the 6.c release though (IMHO) 20:04
20:15 leont joined 21:44 hankache joined
jdv79 ranguard: around? where's the eco to cpan code again? 21:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!