Camelia, the Perl 6 bug

IRC log for #moarvm, 2013-06-13

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

All times shown according to UTC.

Time Nick Message
00:02 Tene I'm sure someday MS will release a C11 update to msvc ;)
00:18 timotimo_ yeah, by the time C22 is the current standard ...
00:48 flussence MS follows the 80/20 rule: 80% of the standards they support are 20 years out of date
00:51 timotimo_ "80% of the standard is good enough, if it's 20 years later"
00:53 Tene They've said a few times that they just don't care about C, won't support C, their customers don't want C, etc.
00:55 timotimo_ yeah, nobody wants C if there's ASP server pages
01:02 flussence .oO( if we used that line of reasoning, this channel wouldn't exist today )
01:06 FROGGS_ joined #moarvm
01:39 mrallen1 joined #moarvm
01:50 cognominal joined #moarvm
02:02 benabik joined #moarvm
02:04 harrow joined #moarvm
03:29 cognominal joined #moarvm
04:36 eternaleye Sometimes, when I compile things, I imagine that seeing 'clang' scroll by in the make output is an onomatopoea for a Microsoft employee thunking their head against their computer at their rate of progress.
04:52 birdwindupbird joined #moarvm
06:16 tomyan joined #moarvm
06:20 Tene It took me quite a while to realize that clang was c-language, not just a loud noise.
06:22 eternaleye There's an flang now too, although I think they should have called it flange - 'engine' is meaningless on the end, but it makes the name stick out more :P
06:22 eternaleye *a 'flang'
06:22 eternaleye [Fortran LANGuage Engine]
06:49 FROGGS_ joined #moarvm
08:18 tomyan joined #moarvm
08:26 tgt joined #moarvm
08:35 dalek MoarVM/container: 4170819 | jimmy++ | / (3 files):
08:35 dalek MoarVM/container: add more container code
08:35 dalek MoarVM/container: review: https://github.com/MoarVM/MoarVM/commit/41708192ca
08:40 dalek MoarVM/container: dea231c | jimmy++ | src/6model/containers.c:
08:40 dalek MoarVM/container: fix wrong message
08:40 dalek MoarVM/container: review: https://github.com/MoarVM/MoarVM/commit/dea231c8b7
08:51 jlaire joined #moarvm
09:42 tgt joined #moarvm
09:44 Jimmy joined #moarvm
09:44 Jimmy hello jnthn
09:50 jnthn o/
09:53 Jimmy jnthn: I'm block on cantainer branch, because I don't know how to call invoke in code_pair_fetch, and I don't know store MVMContainerConfigurer * data and func pointer to VMHash
09:54 jnthn Jimmy: Yes, you can't.
09:54 jnthn Jimmy: Such things have to be transformed CPS-like.
09:55 jnthn (for the invoke, that is)
09:55 Jimmy jnthn: I guess that's the scope of my ability
09:55 jnthn Yeah, I expected to need to do that bit. :)
09:56 jnthn It's a bit fiddly.
09:56 Jimmy out the scope of my ability
09:56 Jimmy jnthn: So I will leave the hard works to others :P
09:57 jnthn On the MVMContainerConfigurer, probably those just want to go in a raw hash
09:57 jnthn Rather than in a VMHash :)
09:57 jnthn Well, I'm appreciative of the bits of the work you've done so far. It's certainly in the right direction. Though there's a GC fail :)
09:58 jnthn MVMString *fetch = MVM_string_ascii_decode_nt(tc, tc->instance->VMString, "fetch");
09:58 jnthn MVMString *store = MVM_string_ascii_decode_nt(tc, tc->instance->VMString, "store");
09:58 jnthn Here, for example, you are doing an allocation of a string, which is a GC-able object
09:58 Jimmy yes, with raw hash, can do it
09:58 jnthn Any allocation may trigger GC
09:59 jnthn And if you're going to do that, you need to tell the GC about what's ont he C stack (because we don't walk it, like on Parrot...can't do that, as we have to be precise)
09:59 jnthn There's an MVMROOT macro that takes care of this
10:00 Jimmy MVMROOT is tha part that I don't know when I need it
10:01 jnthn If you have a C parameter or local that is an MVMObject *, MVMSTable*, or MVMString * that you are going to use later in the current function, and you are going to do an allocation, you need to make sure the thing(s) are MVMROOT'd before the allocation happens.
10:02 jnthn Example:
10:02 jnthn void foo(MVMThreadContext *tc, MVMObject *a) {
10:02 jnthn ...something that allocates...
10:02 jnthn ...use a...
10:02 jnthn }
10:02 jnthn This is wrong
10:02 jnthn Needs to be more like
10:02 jnthn void foo(MVMThreadContext *tc, MVMObject *a) {
10:02 jnthn MVMROOT(tc, a, {
10:02 jnthn ...something that allocates...
10:03 jnthn ...use a...
10:03 jnthn });
10:03 jnthn }
10:03 Jimmy for exmaple: type_object_for int P6str.c and MVMString.c, I'm confused why one uses MVMROOT and one doesn't
10:03 jnthn Looking
10:04 jnthn um. 'cus P6str is wrong.
10:05 * Jimmy goes home...
10:07 nwc10 jnthn: I assume that it would be very slow to run, but presumably a "debugging" mode which forced a nursery sweep for every allocation, and a flag for "I'm a dead pointer now" would flush out a lot of these?
10:08 jnthn nwc10: Yes
10:08 jnthn nwc10: Well, kinda.
10:09 nwc10 you have to keep the dead things around for a long time, as it might be a while before something looks at the them again
10:09 dalek MoarVM: 2420cbd | jnthn++ | src/6model/reprs/P6int.c:
10:09 dalek MoarVM: Missing MVMROOT; JimmyZ++.
10:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2420cbd748
10:09 jnthn Yeah
10:09 jnthn Well, in the nursery you can always just reallocate rather than re-using semispaces
10:18 nwc10 Actually, it might not be *terribly* hard. You'd sort of cheat with a "pre-nursery", and forcibly move everything out of that on each potential GC location into the real location
10:18 nwc10 er, terribly hard to have it not consume all the swap, that is
10:18 nwc10 still not a totally *S*MOP
10:19 nwc10 although I'm not sure if the pre-nursery is ever allowed to be freed
10:20 nwc10 anyway, this seems to be a bit of a distraction. I'll shut up. As I'm very unlikely to write this
10:21 jnthn aww, dang :P
10:21 nwc10 sorry
11:07 BinGOs I did manage to refactor Config::BuildEnvironment last night, but I ended up having to fix my FreeBSD ports after blowing it up with a perl upgrade.
11:09 JimmyZ joined #moarvm
11:10 JimmyZ speak of CPS, I had a work one for code_pair_fetch, I was not sure whether it's right or not
11:11 dalek joined #moarvm
11:28 JimmyZ jnthn: https://gist.github.com/zhuomingliang/5773002 Is it right?
11:28 jnthn No.
11:29 JimmyZ jnthn: thanks :P
11:29 jnthn The best example is probably in loadbytecode.c
11:29 jnthn coerce.c also has some
11:30 jnthn Actually the coerce.c ones are probably closer
11:31 JimmyZ I had taken a look at it. it creates a callsite, but I don't know how to create args
11:39 dalek MoarVM: 26a227c | (Chris 'BinGOs' Williams)++ | build/Config/BuildEnvironment.pm:
11:39 dalek MoarVM: Make the build environment detection more generic
11:39 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/26a227c822
11:39 dalek MoarVM: 199a0d3 | (Chris 'BinGOs' Williams)++ | / (2 files):
11:39 dalek MoarVM: Add --clang option to Configure.pl
11:39 dalek MoarVM:
11:39 dalek MoarVM: This forces usage of clang compiler over gcc if clang is found
11:39 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/199a0d331f
12:17 JimmyZ jnthn: https://gist.github.com/zhuomingliang/5773227 right? I'm sorry if it's wrong, GC is hard
12:18 jnthn JimmyZ: Close. Also fetch needs an MVMROOT before the decode call for store.
12:18 jnthn Otherwise that may trigger GC.
12:18 jnthn But config is rooted correctly now.
12:18 jnthn airport &
12:26 [Coke] JimmyZ++ # commits
12:38 dalek MoarVM/container: eeb9989 | jimmy++ | src/6model/containers.c:
12:38 dalek MoarVM/container: fix a GC fail, jnthn++
12:38 dalek MoarVM/container: review: https://github.com/MoarVM/MoarVM/commit/eeb9989d3c
12:53 JimmyZ joined #moarvm
12:58 dalek MoarVM/container: 5ca108d | jimmy++ | src/ (3 files):
12:58 dalek MoarVM/container: some small fixes
12:58 dalek MoarVM/container: review: https://github.com/MoarVM/MoarVM/commit/5ca108da8d
13:13 JimmyZ joined #moarvm
13:26 JimmyZ joined #moarvm
13:33 JimmyZ joined #moarvm
14:12 chipdude I was going to suggest that configuration in Perl might be a limiting strategy, but for anything non-Windows it actually should work fine
14:12 chipdude just have to work to the GCD of all distributions.  5.6, maybe even 5.005.
14:13 PerlJam chipdude: you scare me  :)
14:15 chipdude PerlJam: having worked with autoconf, metaconfig, and cmake, I find Perl config fairly non-scary :)
14:15 chipdude cmake would actually work for cross-platform to Win, though, which might be worth it if you're willing to ask people to install cmake to build mvm
14:16 chipdude Topsy uses cmake almost universally and it's fine.
14:37 JimmyZ joined #moarvm
14:38 JimmyZ chipdude: since here is the perl community, I think most pepole here want perl instead of cmake
15:54 chipdude not so much my point; do we want Moar to build where there is no Perl?  Obviously yes if Win is a target, and it is.
15:54 chipdude so WIn must be special-cased in a Perl system.
15:54 chipdude but we can work with it, that's fine.
17:37 diakopter chipdude: not everyone agrees with me on this, but I firmly assert the answer to "do we want Moar to build where there is no Perl" is no
17:38 diakopter my main argument for that is that Perl 6 won't be very usable or useful at all without Perl 5's CPAN also available. Plus, if you're okay with asking people to install cmake, what's wrong with asking them to install Perl?
17:39 lizmat joined #moarvm
17:39 diakopter The other part of my argument is that it's highly unlikely [somewhat inconceivable actually] someone who already has Visual Studio and wants to build moarvm using msvc is going to balk at installing activeperl
17:39 diakopter case in point: the Microsoft folks who built .Net used Perl heavily in some code generation/compiling stages of building that for many many years
17:40 diakopter (as evidenced by the enormous dependence on it in the open-source released version of .NET, SSCLI
17:40 diakopter )
17:41 diakopter cygwin of course has the same argument as yours for unix; it's trivial to install if it's not installed by default, which it likely is
17:43 diakopter so, I guess the 2nd part of the 1st argument is that I'd *really* like to encourage folks to build moarvm with libperl embedding enabled [which will certainly be the default if available], just so the software is at least useful for something other than.. toying
17:45 diakopter long term [many years from now] it won't be as important, but if Perl 6 is to get any substantial number of users in the first few years since general availability of a stable/productized release, they're almost certainly going to come from the Perl 5 community
17:58 diakopter Perl 6's negative stigma of super-late, super-bloated/engineered, and in general pie-in-the-sky/pipe-dream toy language spec/implementations won't be easily changed, even with a completely new VM in C and JVM backends
18:05 diakopter chipdude: in addition, activeperl could be downloaded and installed by our configure program, given a tiny C program compiled that uses windows apis to download the installer and launch it in unattended/silent/headless mode:  msiexec /q /i msi_file.msi TARGETDIR="c:\ActivePerl64" PERL_PATH="Yes"
18:07 diakopter chipdude: also, for those without cygwin or msvc or activeperl or strawberry perl, it would be great to offer an option to automatically install/download an appropriate strawberry perl. might need to include an .exe in the distibution (and repo?) to download it.
18:07 diakopter ..assuming we can get moarvm to build with the gcc in strawberry, which I don't think anyone's even attempted
18:12 diakopter chipdude: *also* building libuv currently has a dependency on Gyp (uses Python 2.x), the build system/language Google created to build chrome/v8: https://code.google.com/p/gyp/wiki/GypVsCMake
18:12 diakopter so....
18:13 diakopter someone would probably need to port that eventually, or just not worry about the Python dependency for building.
18:52 labster '^'..('^' x 20) -- looks like someone needs to write a blog post
18:57 tomyan joined #moarvm
18:58 diakopter heh.
18:59 [Coke] information about the super secret project? crazy.
19:19 tgt joined #moarvm
19:19 tomyan joined #moarvm
20:34 Tene Which super-secret project?
20:35 [Coke] (this one. shhhhh)
20:37 diakopter [Coke]: I can't tell whether you're serious..?
20:37 diakopter (or teasing)
20:37 diakopter bbiab
20:37 [Coke] was this not, at one point, a super secret project?
20:37 diakopter yes
20:38 [Coke] your 20 sends there are more information than I'd seen in one chunk since I found out about it.
20:38 [Coke] so, kind of teasing, kind of serious.
20:45 lizmat joined #moarvm
20:47 PerlJam [Coke]: yeah, but diakopter's text were more design considerations and not really something for public consumption.  So ... the cabal needs to communicate about the ex-super-secret project, but only amongst themselves  :)
21:07 d4l3k_ joined #moarvm
21:09 tgt joined #moarvm
22:02 tokuhirom I got warning in current Configure.pl http://nopaste.64p.org/entry/F9EE​77CC-D474-11E2-8DDE-3AC23A9B6EE1
22:03 tokuhirom <censored>
22:03 tokuhirom Use of uninitialized value within %config in substitution iterator at build/Config/Generate.pm lone 14, <$fh_s> lone 14.
22:04 Tene Why put that in a notice instead of a normal message?
22:05 sorear o/ tokuhirom
22:08 tokuhirom there is no reason but this irc client use notice when using copy-and-paste
22:11 diakopter wait what?
22:11 diakopter oh
22:11 diakopter I've never seen that before
22:16 donaldh joined #moarvm
22:26 benabik joined #moarvm
22:49 tomyan joined #moarvm
23:47 dalek MoarVM: 49cd270 | tokuhirom++ | src/strings/utf8. (2 files):
23:47 dalek MoarVM: MVM_string_utf8_decode takes `const char*`.
23:47 dalek MoarVM: This change helps to integrate with C++.
23:47 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/49cd27097f
23:47 dalek MoarVM: f14589f | (Matthew Wilson)++ | src/strings/utf8. (2 files):
23:47 dalek MoarVM: Merge pull request #29 from tokuhirom/fix/const-modifier​-for-MVM_string_utf8_decode
23:47 dalek MoarVM:
23:47 dalek MoarVM: MVM_string_utf8_decode takes `const char*`.
23:47 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f14589fc0d
23:48 dalek MoarVM: 80fb993 | tokuhirom++ | src/core/frame.h:
23:48 dalek MoarVM: FIxed '/*' within block comment
23:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/80fb993b70
23:48 dalek MoarVM: 1ccd948 | (Matthew Wilson)++ | src/core/frame.h:
23:48 dalek MoarVM: Merge pull request #28 from tokuhirom/patch-01
23:48 dalek MoarVM:
23:48 dalek MoarVM: FIxed '/*' within block comment
23:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1ccd948467

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