00:21
vendethiel joined
04:25
llfourn joined
04:54
vendethiel joined
09:05
domidumont joined
09:07
patrickz joined
09:10
domidumont joined
09:55
virtualsue joined
10:31
dalek joined
11:06
vendethiel joined
12:13
virtualsue joined
12:26
leont joined
12:43
dalek joined
13:21
colomon joined
13:25
colomon joined
14:03
geekosaur joined
|
|||
flussence | has anyone here ever successfully built rakudo+moar with --has-libffi? | 14:39 | |
15:23
kjs_ joined
16:11
zakharyas joined
16:23
vendethiel joined
|
|||
hoelzro | o/ #moarvm | 16:30 | |
flussence: I have | |||
flussence | I can't get it to work on gentoo :( both moar and rakudo assume ffi.h is /usr/include/ffi.h | 16:32 | |
hoelzro | flussence: have you tried CFLAGS=-I/lib/ffi/location perl Configure.pl --has-ffi ? | ||
it probably won't compile the probe if -lffi isn't in your compiler's default search path, though | 16:33 | ||
sadly, Configure.pl's probe doesn't respect LDFLAGS (although it may now) | |||
flussence | I've put a makefile patch for that on moarvm's github issues, can't find anywhere appropriate to do the same for rakudo though. | ||
(anywhere in Makefile-Moar*.in, that is) | 16:34 | ||
16:53
mohij joined
17:34
TimToady joined
18:41
brrt joined
|
|||
brrt | ping konobi | 18:46 | |
19:10
mojca joined
|
|||
mojca | does moarvm with jit work on 32-bit platforms at all? | 19:11 | |
flussence | nope | 19:13 | |
brrt | no | 19:20 | |
what kind of platform are you looking for? | |||
ugh, my designed tile thingy is 152 bytes large even when leaving out the list pointers :-( | 19:29 | ||
19:38
llfourn joined
|
|||
mojca | i386-darwin | 19:38 | |
in Configure.pl I see "if ($Config{archname} =~ m/^x86_64|^amd64|^darwin(-thread)?(-multi)?-2level/) { ... then enable jit" | |||
but for darwin there doesn't seem to be any distinction between 32-bit and 64-bit | |||
timotimo | brrt: too big for a cache line or what's the matter? | 19:39 | |
brrt | just big and ugly | ||
timotimo | hmm | ||
brrt | mojca, oh, wow | ||
yes, that piece of code is Stupid, and my fault too | |||
i didn't know any better way to detect the architecture in perl | 19:40 | ||
i still don't, for that matter | |||
mojca | but I checked the configure parameters and there is no really straightforward variable that I could see | ||
leont | archname is not a very portable concept | ||
brrt | no, it isn't | ||
mojca | I have some very complex code to detect whether a mac is 64-bit capable | 19:41 | |
brrt | mojca, the JIT works on amd64 posix and windows architectures, and nothing else | ||
mojca | ok, moderately complex | ||
leont | perl5's configure takes it from uname (at least on Unixy systems) | ||
brrt | hmmm | ||
that's something, yes | |||
but, not correct either | |||
because it disregards architecture | 19:42 | ||
mojca | no problem, I don't think the user who was hit by this really cares about JIT, it would only be helpful if it didn't throw a bus error | ||
brrt | eh, wait, let me restate that | ||
well, it's something that has to be reworked one day or another | |||
mojca | on OS X probably the most reliable way would be to check for compiler flags | ||
sorry, not flags, defines | |||
brrt | leont: we shouldn't assume target and host architecture are equal, and we do | 19:43 | |
python setuputils also makes that mistake | |||
mojca | what's the best quick solution to disable jit before the configure "bug" gets fixed? | ||
leont | True | ||
brrt | --no-jit | ||
mojca | ok | ||
oh, wait, one more thing | |||
brrt | ask away :-) | 19:44 | |
mojca | what if a user builds universal binaries? | ||
brrt | hahahahaha | ||
no | |||
mojca | also --no-jit just to be on the safe side? | ||
brrt | probably yes | ||
mojca | I can certainly build universal binaries | ||
brrt | i can't and never tried... | ||
mojca | but I'm not sure if I can run them :) | ||
brrt | if you make a universal binary, does it include two architecture shared objects | 19:45 | |
leont | Basically, yes | ||
brrt | hmm | ||
leont | In theory, ELF supports that too, just no one implemented it much beyond proof of concept, because why would you? | 19:46 | |
geekosaur | arch i386 somecommandhere | ||
er | |||
brrt | then basically, architecture-dependent compiler definitions could be made to do config, and we'd never care about a Configure.pl script at all | ||
geekosaur | arch -32 or arch -64 | ||
brrt | because it'd then be the job of the compiler to get the configuration right | 19:47 | |
well, with some exceptions like cgoto support | |||
stuff that would have to be probed for | |||
mojca | I opened a new ticket: github.com/MoarVM/MoarVM/issues/324 | 19:50 | |
Just curious, is powerpc supported? | 19:51 | ||
I'm not asking about JIT of course | |||
flussence | people have built on arm, so I don't see why not... | 19:52 | |
mojca | Just for information: LuaJIT works on i386-darwin, but I believe there is specific code that has to be written for perl | ||
Maybe I'll try the ppc just for fun | |||
nwc10 | Power 8 worked last I tested it, 32 and 64 bit, but some tests failed | 19:53 | |
brrt | i think powerpc is supported in principle | ||
nwc10 | IIRC jnthn fixed what he thought might have been the cause of those | ||
mojca | ok, thank you | ||
nwc10 | but I've not had a chance | ||
to retest | |||
brrt | luajits support for powerpc or not is basically separate from moarvm :-) | ||
we don't actually share any luajit code beyond the build process | |||
and couldn't, even if we wanted | |||
mojca | luajit on powerpc-darwin is broken | ||
I can compile luajit with some patches, but then random code crashes | 19:54 | ||
(even though most of it works; but those crashes make it useless) | |||
also, isn't it slightly wrong to use $Config{archname} or $Config{anyotherthing} to determine the architecture of the binary we are building? | 19:59 | ||
I can imagine that one could easily use x86_64 perl to build MoarVM for PPC for example | 20:00 | ||
[Coke] | hey, we got a failure report for moarvm on os x 10.6 | 20:14 | |
nwc10 | and it wasn't from me :-) | ||
[Coke] | mojca++ again. :) | 20:15 | |
nwc10 | also, apologies in advance. My client might be here, but I'm not hugely around currently. | 20:16 | |
brrt | mojca, yes, it is terribly wrong; but the question is, what would be a better strategy | 20:21 | |
i do know the answer, by the way | |||
compile a binary that invokes the compiler with the correct flags, based on what your compiler thinks is the right thing... except that doesn't work for cross-builds either | 20:22 | ||
aargh | |||
mojca | in a way one should probably treat every Mac OS X compilation as "cross-compilation" just in case | ||
brrt | probably, yes | ||
mojca | not in the sense that one should expect --host and --target flags | ||
I'm not sure what your compilation chain does | 20:24 | ||
but in my opinion the proper way to determine the architecture on OS X would be to actually run the compiler and grep for some defines; something similar that autoconf does (I'm not saying I like autoconf) | 20:25 | ||
brrt | Configure.pl builds a Makefile from build/Makefile.in, based on probing and args from the environment, and the makefile than builds all the things | 20:26 | |
mojca | then again ... if this is just for JIT, running the compiler would be a bit of an overkill | ||
brrt | nah, we already probe for other stuff | ||
it's a completely valid approach | |||
mojca | on mac one could theoretically set "export CXX=powerpc-apple-darwin10-g++-4.0" | 20:27 | |
I didn't check whether that name exactly is a valid compiler name | 20:28 | ||
but one would get powerpc binaries by calling that compiler | |||
and most things would work out of the box | |||
though usually one would use export CXXFLAGS="-arch ppc" to achieve the same | |||
brrt | any binary name is valid, i think | ||
mojca | valid in the sense of "actually existing in the wild" | 20:29 | |
(shipped by Apple) | |||
anyway, the name itself doesn't actually matter | |||
20:29
virtualsue joined
|
|||
brrt | no.. you can always do make CC=powerpc-apple-darwin10-g++-4.0 | 20:30 | |
mojca | the problem is that 10.6 would return "i386" when asked for uname, but it would build x86_64 binaries by default | ||
brrt | hmm | ||
that's ugly | |||
mojca | well, on ARM I don't know how to distinguish between armhf and armel; and on MIPS I don't know how to distinguish between mips and mipsel either | 20:31 | |
without actually running the compiler | |||
the uname output is equal on both variants, but binaries are incompatible | |||
and I'm still fighting with that problem in our distribution of some other binaries; the only luck we have is that there are practically no users of those archs | 20:32 | ||
brrt should do an experiment probably with that | |||
mojca | what's the best place to ask a few simple questions about panda? #perl6? | 20:34 | |
[Coke] | sdtimes.com/christmas-perl-arrives/ - that article seems confused. | 20:36 | |
ww | |||
20:39
llfourn joined
|
|||
brrt | mojca, yes, that's the right place | 20:51 | |
you should ask tadzik | |||
20:55
vendethiel joined
|
|||
tadzik | hm? | 21:02 | |
oh, panda, yes | |||
mojca | tadzik, I tried to create a package for panda for macports, but failed because I don't quite understand how it's supposed to work | 21:04 | |
by default it installs files to a completely weird location | |||
and if I move it, it breaks with "/opt/local/bin/panda: line 2: syntax error near unexpected token `('" | 21:05 | ||
"/opt/local/bin/panda: line 2: `sub MAIN(:$name is copy, :$auth, :$ver, *@, *%) {'" | |||
but I should probably move the discussion to #perl6? | |||
maybe that error is because perl6 in shebang doesn't work | 21:06 | ||
tadzik | oh? | 21:07 | |
timotimo | src/6model/reprs/NFA.c:442:17: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 6 has type ‘MVMint64’ [-Wformat=] | 21:09 | |
fprintf(stderr,"%c with %ds target %lx offset %lld\n",cp,(int)numcur, (long)target, offset); | |||
^- what could cause this? a "strange" platform? | |||
tadzik | overexcited compiler, imho :) | 21:10 | |
well, or a platform where long long int is not a 64bit int | |||
timotimo | well, it's only a debug statement | 21:12 | |
21:38
llfourn joined
22:24
colomon joined
22:39
llfourn joined
22:50
zakharyas joined
23:17
colomon joined
23:29
virtualsue joined
23:41
llfourn joined
|