github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 7 June 2013.
Tene I'm sure someday MS will release a C11 update to msvc ;) 00:02
timotimo_ yeah, by the time C22 is the current standard ... 00:18
flussence MS follows the 80/20 rule: 80% of the standards they support are 20 years out of date 00:48
timotimo_ "80% of the standard is good enough, if it's 20 years later" 00:51
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:53
timotimo_ yeah, nobody wants C if there's ASP server pages 00:55
flussence
.oO( if we used that line of reasoning, this channel wouldn't exist today )
 01:02
01:06 FROGGS_ joined 01:39 mrallen1 joined 01:50 cognominal joined 02:02 benabik joined 02:04 harrow joined 03:29 cognominal joined
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:36
04:52 birdwindupbird joined 06:16 tomyan joined
Tene It took me quite a while to realize that clang was c-language, not just a loud noise. 06:20
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
*a 'flang'
[Fortran LANGuage Engine]
06:49 FROGGS_ joined 08:18 tomyan joined 08:26 tgt joined
dalek arVM/container: 4170819 | jimmy++ | / (3 files):
add more container code
 08:35
arVM/container: dea231c | jimmy++ | src/6model/containers.c:
fix wrong message
 08:40
08:51 jlaire joined 09:42 tgt joined 09:44 Jimmy joined
Jimmy hello jnthn 09:44
jnthn o/ 09:50
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:53
jnthn Jimmy: Yes, you can't. 09:54
Jimmy: Such things have to be transformed CPS-like.
(for the invoke, that is) 09:55
Jimmy jnthn: I guess that's the scope of my ability
jnthn Yeah, I expected to need to do that bit. :)
It's a bit fiddly. 09:56
Jimmy out the scope of my ability
jnthn: So I will leave the hard works to others :P
jnthn On the MVMContainerConfigurer, probably those just want to go in a raw hash 09:57
Rather than in a VMHash :)
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 :)
MVMString *fetch = MVM_string_ascii_decode_nt(tc, tc->instance->VMString, "fetch"); 09:58
MVMString *store = MVM_string_ascii_decode_nt(tc, tc->instance->VMString, "store");
Here, for example, you are doing an allocation of a string, which is a GC-able object
Jimmy yes, with raw hash, can do it
jnthn Any allocation may trigger GC
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
There's an MVMROOT macro that takes care of this
Jimmy MVMROOT is tha part that I don't know when I need it 10:00
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:01
Example: 10:02
void foo(MVMThreadContext *tc, MVMObject *a) {
...something that allocates...
...use a...
}
This is wrong
Needs to be more like
void foo(MVMThreadContext *tc, MVMObject *a) {
MVMROOT(tc, a, {
...something that allocates...
...use a... 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
jnthn Looking
um. 'cus P6str is wrong. 10:04
Jimmy goes home... 10:05
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:07
jnthn nwc10: Yes 10:08
nwc10: Well, kinda.
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 arVM: 2420cbd | jnthn++ | src/6model/reprs/P6int.c:
Missing MVMROOT; JimmyZ++.
jnthn Yeah
Well, in the nursery you can always just reallocate rather than re-using semispaces
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
er, terribly hard to have it not consume all the swap, that is
still not a totally *S*MOP
although I'm not sure if the pre-nursery is ever allowed to be freed 10:19
anyway, this seems to be a bit of a distraction. I'll shut up. As I'm very unlikely to write this 10:20
jnthn aww, dang :P 10:21
nwc10 sorry
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:07
11:09 JimmyZ joined
JimmyZ speak of CPS, I had a work one for code_pair_fetch, I was not sure whether it's right or not 11:10
11:11 dalek joined
JimmyZ jnthn: gist.github.com/zhuomingliang/5773002 Is it right? 11:28
jnthn No.
JimmyZ jnthn: thanks :P 11:29
jnthn The best example is probably in loadbytecode.c
coerce.c also has some
Actually the coerce.c ones are probably closer 11:30
JimmyZ I had taken a look at it. it creates a callsite, but I don't know how to create args 11:31
dalek arVM: 26a227c | (Chris 'BinGOs' Williams)++ | build/Config/BuildEnvironment.pm:
Make the build environment detection more generic
 11:39
arVM: 199a0d3 | (Chris 'BinGOs' Williams)++ | / (2 files):
Add --clang option to Configure.pl

This forces usage of clang compiler over gcc if clang is found
JimmyZ jnthn: gist.github.com/zhuomingliang/5773227 right? I'm sorry if it's wrong, GC is hard 12:17
jnthn JimmyZ: Close. Also fetch needs an MVMROOT before the decode call for store. 12:18
Otherwise that may trigger GC.
But config is rooted correctly now.
airport &
[Coke] JimmyZ++ # commits 12:26
dalek arVM/container: eeb9989 | jimmy++ | src/6model/containers.c:
fix a GC fail, jnthn++
 12:38
12:53 JimmyZ joined
dalek arVM/container: 5ca108d | jimmy++ | src/ (3 files):
some small fixes
 12:58
13:13 JimmyZ joined 13:26 JimmyZ joined 13:33 JimmyZ joined
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
just have to work to the GCD of all distributions. 5.6, maybe even 5.005.
PerlJam chipdude: you scare me :) 14:13
chipdude PerlJam: having worked with autoconf, metaconfig, and cmake, I find Perl config fairly non-scary :) 14:15
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
Topsy uses cmake almost universally and it's fine. 14:16
14:37 JimmyZ joined
JimmyZ chipdude: since here is the perl community, I think most pepole here want perl instead of cmake 14:38
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
so WIn must be special-cased in a Perl system.
but we can work with it, that's fine.
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:37
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:38
17:39 lizmat joined
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
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
(as evidenced by the enormous dependence on it in the open-source released version of .NET, SSCLI 17:40
)
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:41
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:43
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:45
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 17:58
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:05
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
..assuming we can get moarvm to build with the gcc in strawberry, which I don't think anyone's even attempted
chipdude: *also* building libuv currently has a dependency on Gyp (uses Python 2.x), the build system/language Google created to build chrome/v8: code.google.com/p/gyp/wiki/GypVsCMake 18:12
so....
someone would probably need to port that eventually, or just not worry about the Python dependency for building. 18:13
labster '^'..('^' x 20) -- looks like someone needs to write a blog post 18:52
18:57 tomyan joined
diakopter heh. 18:58
[Coke] information about the super secret project? crazy. 18:59
19:19 tgt joined, tomyan joined
Tene Which super-secret project? 20:34
[Coke] (this one. shhhhh) 20:35
diakopter [Coke]: I can't tell whether you're serious..? 20:37
(or teasing)
bbiab
[Coke] was this not, at one point, a super secret project?
diakopter yes
[Coke] your 20 sends there are more information than I'd seen in one chunk since I found out about it. 20:38
so, kind of teasing, kind of serious.
20:45 lizmat joined
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 :) 20:47
21:07 d4l3k_ joined 21:09 tgt joined
tokuhirom I got warning in current Configure.pl nopaste.64p.org/entry/F9EE77CC-D474...C23A9B6EE1 22:02
<censored> 22:03
Use of uninitialized value within %config in substitution iterator at build/Config/Generate.pm lone 14, <$fh_s> lone 14.
Tene Why put that in a notice instead of a normal message? 22:04
sorear o/ tokuhirom 22:05
tokuhirom there is no reason but this irc client use notice when using copy-and-paste 22:08
diakopter wait what? 22:11
oh
I've never seen that before
22:16 donaldh joined 22:26 benabik joined 22:49 tomyan joined
dalek arVM: 49cd270 | tokuhirom++ | src/strings/utf8. (2 files):
MVM_string_utf8_decode takes `const char*`.
 23:47
arVM: f14589f | (Matthew Wilson)++ | src/strings/utf8. (2 files):
Merge pull request #29 from tokuhirom/fix/const-modifier-for-MVM_string_utf8_decode

MVM_string_utf8_decode takes `const char*`.
arVM: 80fb993 | tokuhirom++ | src/core/frame.h:
FIxed '/*' within block comment
 23:48
arVM: 1ccd948 | (Matthew Wilson)++ | src/core/frame.h:
Merge pull request #28 from tokuhirom/patch-01

FIxed '/*' within block comment

Powered by Cro and the Raku® Programming Language.

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

Thank you!