github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 21 August 2013.
00:21 jnap joined 00:31 FROGGS joined 00:59 Ben_Goldberg joined
dalek arVM: c66a644 | diakopter++ | src/gc/orchestrate.c:
note to self
 01:45
segomos note to self 01:47
diakopter ? :) 01:48
segomos: ok..? 02:19
02:20 benabik joined
JimmyZ Good morning 02:26
TimToady o/ 02:27
diakopter TimToady: well.. 02:28
TimToady: I disable closing of stdout
and ..\\moarvm.exe nqp.moarvm -e 1 ... eats 8GB ram in 1 second
probably that's not what was intended, and probably won't work, except in the very long term 02:29
TimToady: at least it's .. fast.... or something 02:31
*sigh* now I have to add some form of tracing
.tell jnthn yes I'm kinda married to outputting the opname and which instruction it is; it can be very helpful; but I'm glad to make it a command-line flag (--verbose-stack-traces or something) 02:37
yoleaux diakopter: I'll pass your message to jnthn.
JimmyZ \\o 02:39
diakopter JimmyZ: g'morning 02:40
JimmyZ morning 02:42
dalek arVM: 83bca4d | diakopter++ | src/ (3 files):
don't close std streams... for now...
 02:43
arVM: 2bb0d04 | diakopter++ | src/core/exceptions. (2 files):
make MVM_exception_backtrace_line non-static and free what it returns... :/
arVM: 5bb825e | diakopter++ | / (6 files):
add very naive every-instruction tracing.... <lol>
 03:41
diakopter TimToady: lololol gist.github.com/diakopter/b3b85ed4b6c7df7779ac 03:42
JimmyZ: ^
JimmyZ lol
diakopter the twenty null instrunctions in a row are curious 03:43
lolol instr 53857808
.oO( stop instructing me so much.. )
.oO( 53 million instructions in one routine is .. a lot )
 03:44
JimmyZ :-)
we need break point :)
could be added into nqp though 03:45
diakopter well the end betrays the infinite loop 03:48
erm. 03:49
actually not.
diakopter lets it run a while longer
HAHAHAHAHA 03:51
JimmyZ: it's looping in the interactive prompt b/c the readline prompt and ensuing eval is commented out :) 03:54
(yay, nqp is "running", fsdo running) 03:55
it has to execute around 250k interpreter runloop instructions to get to that readline prompt 03:56
JimmyZ wat, that's too much instr
TimToady "This file has been truncated" tee hee
perhaps it's really calling into a PRNG
wasn't someone threatening to throw in a Mersenne Twistor?
diakopter no that's including loading the whole nqp setting and compiler code 03:57
and doing all the deserialization required
I'd paste it, but it's a quarter million lines...
well, I'd probably nopaste it instead of pasting it 03:58
JimmyZ FYI, m0 has a break point/step debuger, and this gist.github.com/zhuomingliang/2706999
diakopter "loading" the nqp setting involves running a lot of coe. 04:00
code, even
brb; dinner
actually. 04:02
.ask jnthn how much of *Moar.nqp can we wrap in BEGIN { }.. hopefully lots? also, plz read scrollback in moar
yoleaux diakopter: I'll pass your message to jnthn.
04:04 FROGGS joined
diakopter FROGGS: read the clogs for here... brb 04:04
04:23 FROGGS joined
diakopter JimmyZ: I could fake up a quick and dirty readline 04:23
JimmyZ diakopter: not based lineniose? 04:46
diakopter JimmyZ: well I could but I thought your branch depended on libuv 04:49
04:51 dalek joined
JimmyZ diakopter: I couldn't got it 04:52
diakopter ?
JimmyZ my branch depended on libuv? 04:53
diakopter libuv is not in your branch?
linenoise branch
JimmyZ yeah, linenoise doesn't depend on libuv 04:54
but linenoise doesn't depend on libuv
diakopter okay; could you merge master into your linenoise branch?
JimmyZ diakopter: ok
diakopter JimmyZ: also into libuv?: ) 04:59
:)
libuv5 branch, I mean 05:00
dalek Heuristic branch merge: pushed 102 commits to MoarVM/readlineintfh2 by zhuomingliang 05:01
diakopter it merged cleanly!@?! 05:02
JimmyZ no :) 05:04
diakopter oh; you didn't merge the tracing commit 05:06
dalek Heuristic branch merge: pushed 35 commits to MoarVM/libuv5 by zhuomingliang
05:07 FROGGS joined
diakopter JimmyZ++ 05:11
dalek arVM/readlineintfh2: 2fb237f | jimmy++ | build/ (2 files):
fixed build
 05:14
JimmyZ all build now :-) 05:19
JimmyZ would like to merge these branches to master to avoids merge conflict :P
05:35 crab2313 joined 05:52 not_gerd joined
not_gerd o/ 05:52
diakopter: I can probably make the tracing/no-tracing a make-time instead of configure-time decision 05:53
JimmyZ good
not_gerd ie so you can use `nmake tracing` and `nmake no-tracing` without having to re-configure
diakopter: should I go ahead? 05:54
JimmyZ I'd +1
re-configure means almost re-build
not_gerd we really only need to rebuild main.obj and core/interp.obj 05:55
JimmyZ but nmake re-build almost anything after perl configure.pl 05:56
not_gerd getting it work with nmake and gmake both could be a bit tricky though
it'l probably look like `nmake tracing TRACING=0` and `nmake tracing TRACING=1`
JimmyZ how about steal ideas from m0-debug branch :) 05:57
06:21 grondilu joined
not_gerd [x] done 06:25
should I push to master?
(or branch for now?)
JimmyZ nmake tracing? 06:27
dalek arVM: 9298332 | (Gerhard R)++ | / (6 files):
Make tracing a build-time instead of configuration-time decision.

Instead of a configuration flag --tracing, there are now build targets 'tracing' and 'no-tracing'.		 06:28
not_gerd forgiveness > permission
JimmyZ not_gerd: it's nice 06:29
what's the new api for repalce apr atomic? 06:31
not_gerd none yet 06:34
the MVM_cas() macro isn't implemented yet 06:35
I did do the work to rip out the GPL stuff from libatomic_ops, though
JimmyZ e.
not_gerd see github.com/gerdr/libatomic_ops/commits/moarvm
JimmyZ I did see this branch :-) 06:36
not_gerd I can import that into MoarVM
I don't know how up-to-date the cygwin autotools are, though
might de better if someone on a recent linux does this 06:37
* be
JimmyZ note: four of us are on windows
;) 06:38
but jnthn++ said libatomic_ops should be in github.com/MoarVM/libatomic_ops ?
not_gerd as I understand it, he wants to use packaged versions of 3rdparty libs as much as possible 06:41
and I don't have permission to create forks on MoarVM anyway ;) 06:42
JimmyZ not_gerd: how about creating branch to implement MVM_cas() 06:46
like libuv
not_gerd JimmyZ: doesn't really need a branch - just libatomic_ops to be imported 06:58
JimmyZ oh
so only blocker: sockect \\o/ 06:59
not_gerd JimmyZ: as far as I can see, yes 07:00
07:00 FROGGS joined
JimmyZ the libuv is using callback, so it's hard to me 07:00
*libuv sockect api 07:01
not_gerd async io really wants to be integrated with the scheduler to provide a blocking API on top of it 07:02
that needs some design work
JimmyZ yeah 07:15
and async tty :(
07:19 donaldh joined 07:25 donaldh joined
diakopter JimmyZ: no, jnthn meant to bundle it inside the MoarVM/MoarVM, as I understood it 08:09
so you can't nmake without doing no-tracing?
not_gerd diakopter: you'll only use that information after modifying main.c or core/interp.c 08:10
plain `nmake` doesn't trace
diakopter not_gerd: I don't think any of us uses cygwin
(to build moar anyway) 08:11
JimmyZ diakopter: not_gerd uses :P
diakopter ok well that'll be a problem for libuv
not_gerd diakopter: shouldn't really matter where autog
* gen.sh gets called
diakopter: I only use cagwin for the shell environment and cross-compiler packages 08:12
diakopter I wasn't thinking of that
not_gerd * cygwin
diakopter I wasn't thinking of autogen
I was thinking of the library's code and how it doesn't support cygwin
not_gerd diakopter: sure, but I'm targeting MinGW64, not Cygwin
diakopter oh 08:13
JimmyZ sometimes I think we could implement our atomic for both windows and linux
and others cpu could be patches welcome :-) 08:14
not_gerd diakopter: I laready mentioned this before - what I'm going for is --os=win32 --shell=posix --toolchain=gnu --compiler=clang
our Configure.pl supports it, just not APR
JimmyZ we're removing APR 08:15
diakopter okay; I don't know enough to know what that means
not_gerd diakopter: just that I've got a frankenstein setup going
I tried to keep orthogonal decisions orthogonal whenrefactoring Configure.pl 08:16
JimmyZ not_gerd: you want --shell=rc ? the plan9 shell
;)
not_gerd JimmyZ: well, right now we only need rm and cat 08:17
I believe those are in rc?
JimmyZ hehe
not_gerd diakopter: I believe I can do the libatomic_ops import now
diakopter sounds good 08:18
does the new version support 32-bit cas?
not_gerd diakopter: I don't believe so 08:19
diakopter aww
not_gerd all values we want to access atomically need to be pointer-sized
diakopter oh well
apr claims to do it
08:19 FROGGS joined
not_gerd there's AO_HAVE_int_compare_and_swap(), but that wasn't available on windows last we checked 08:20
* AO_int_compare_and_swap() 08:21
which can be checked via AO_HAVE_int_compare_and_swap
diakopter does it have AO_int_fetch_compare_and_swap
er, wherever the fetch goes 08:22
JimmyZ on windows we can use windows api :)
diakopter right, I'm sure the guy would take a pull request to add it to lao
not_gerd: if you get the new lao in and the atomics all switched over, then maybe get dyncall..? 08:23
JimmyZ well, the apr one doesn't do anything except call windwows api
diakopter see my dyncall branch if you want, or don't. ;)
not_gerd ;)
diakopter another feature request: default --no-noisy-build but option --noisy-build where command echoing is hidden (prefix @ on cmd.exe, no clue on sh) 08:25
much easier to read warnings & errors when the command echoing is off, imho
and also easier on the eyes in normal build
thoughts? 08:26
not_gerd might by able to get it to work as `nmake NOISY=1`
need to test if it works in nmake/gmake both
diakopter I did something like that in the dyncall branch, but probably badly
also the realclean target needs to remove the makefiles of all the 3rdparty things too 08:27
and other config stuff 08:28
imho 08:29
JimmyZ: did jnthn have any specific objections to linenoise? or just he hadn't looked into it yet?
not_gerd diakopter: I think it was a general objection against bundling 3rdparty libs to make packagers life easier 08:30
I thinke linenoise is small enough to make an exception, though
also, JimmyZ added windows support 08:31
diakopter this is strange to me since originally he didn't want any external dependencies
I thought he meant to put our fork of lao directly into MoarVM/MoarVM
not_gerd irclog.perlgeek.de/moarvm/2013-08-21#i_7482708
diakopter oh, the line above, you mean 08:32
that's the one I missed
(read too quickly)
I did read the line you highlighted
it's just that last I checked there wasn't a system package for libatomic_ops 08:33
that was anywhere close to up-to-date, maybe
not_gerd: I can create repos in /MoarVM 08:35
I think you can too
not_gerd I just tried to transfer the repo 08:37
no dice
(You don't have admin rights to MoarVM)
diakopter I think you have to create it first through the web interface
you don't have access to that?
oh, neither do I... nm 08:38
JimmyZ diakopter: he hadn't looked into it 08:45
diakopter not_gerd: any ideas on where I should put .markdown documentation for source code?
in the same dir tree as the source code?
maybe one README.markdown per directory so it shows up in github browser?
ok I sold myself on that idea; I'll start with that 08:46
dalek arVM/atomic: 03ecaa1 | (Gerhard R)++ | / (140 files):
Import modified f38b2904 of ivmai/libatomic_ops
 08:47
JimmyZ .md is ok too
not_gerd ^ needs testing, in particular non-windows where the configuratio n actually gets triggered
diakopter shouldn't include the gpl license if we're not redistributing gpl code 08:50
not_gerd diakopter: some of the scripts are GPL 08:51
diakopter what scripts 08:52
not_gerd the testing code that used to be included is as well
decomp, missing
it's a non-issue
diakopter do we need those?
not_gerd we even could have distributed the GPL source files
as long as we don't link libatomic_ops_gpl.a, we're fine
diakopter the problem is that if the license or anything like that is present in the repo, it scares off a huge number of people 08:53
it's viewed as very dangerous
huge stigma
in US companies
not_gerd well, then say goodby to autotools 08:54
diakopter I didn't think we needed it necessairly
not_gerd config.sub and config.guess are GPL as well
JimmyZ so re-imported to make sure GPL is not in the repo history :P 08:55
diakopter well, it's probably okay to include them as long as there's very large notices in LICENSE that even though there's gpl source in the repo, none of it actually goes into what's built 08:56
not_gerd or just not distribute the generated scripts 08:57
would force the user to have autotools available, though
diakopter oh, I think that's definitely okay
it's highly unlikely those aren't there on everything but cmd.exe 08:58
not_gerd errands& 08:59
diakopter not_gerd++ # thanks for importing the lao :) 09:00
JimmyZ not_gerd++ indeed 09:02
diakopter JimmyZ++ not_gerd++ # really taking the bull by the horns! 09:03
JimmyZ :) 09:04
not_gerd should I remove the generated files + COPYING from the branch? 09:19
diakopter no I think let's leave them, but list the GPL files at the bottom of the root LICENSE, and state clearly that they aren't included in any build; they are just there for configure/build/test time 09:21
JimmyZ I'd like +1 to re-import
diakopter JimmyZ: why? 09:22
I think it's fine how it is... but jnthn may disagree, of course, and not want the build-time gpl stuff at all
JimmyZ if removing
because git clone is slow here 09:23
diakopter heh. 09:24
09:24 FROGGS[mobile] joined
dalek arVM: 5fee6da | diakopter++ | / (10 files):
beginnings of source code/repo documentation.. designed to be visible when browsing the source tree in github.
 10:05
10:06 crab2313 joined 10:10 donaldh joined
dalek arVM: 5aa78f8 | diakopter++ | src/ (4 files):
stub in serialization
 10:29
not_gerd should I merge atomic into master? 10:57
jnthn not_gerd: With the updates to the lib, yes? 11:00
not_gerd jnthn: yes
jnthn +1
not_gerd the only concern was that autotools-generated config scripts are GPL
jnthn huh...
not_gerd it's not an issues as long as you don't link against GPL code 11:01
ie we could have distributed the GPL stuff as well without problem
jnthn Generated code can be under GPL too...teh oddness :)
not_gerd ;)
jnthn Guess it counts as derived work or something...
not_gerd diakopter was just concerned about corporate GPL-aversion 11:02
jnthn *nod*
not_gerd his conclusion was just to clearly note the license in a README.md and move along
diakopter (already pushed)
not_gerd alternatively, we'd have to rely on autotools-availability on used-side
jnthn Yes, I find the GPL's freedom-enforcing approach tends to give me less freedom to build stuff. :) 11:03
not_gerd according to their readme, the libatomic_ops authors don't really are about the freedom-granting part of the GPL, but rather their patent clause 11:04
in that case, Apache2 probably would have been more appropriate 11:05
*care
so, merge away? 11:07
jnthn aye
dalek arVM: 03ecaa1 | (Gerhard R)++ | / (140 files):
Import modified f38b2904 of ivmai/libatomic_ops
 11:08
arVM: c6dc357 | (Gerhard R)++ | / (140 files):
Merge branch 'atomic'
not_gerd jnthn: if we want to keep a fork of libatomic_ops, you'll have to do the honours 11:09
jnthn Which honours in particular? :) 11:10
I would overall rather that the MoarVM repo itself just contains MoarVM, not all the things we depend on, and we keep those in separate repos under the MoarVM account.
not_gerd creating a fork of ivmai/libatomic_ops in MoarVM
jnthn ah, ok 11:11
JimmyZ and libuv
and linenoise?
diakopter .. and dyncall 11:14
.. and the bignumber thing 11:15
jnthn When MongoDB adopted linenoise, there were no shortage of complaints. e.g. jira.mongodb.org/browse/SERVER-3914 and many others linked from jira.mongodb.org/browse/SERVER-4312 11:17
JimmyZ can't open it 11:21
so what's real problem? 11:22
jnthn JimmyZ: When they switched to it from readline, they lost lots of features and people were unhappy.
JimmyZ jnthn: I added a lot of feature to linenoise 11:23
and works on windows
jnthn: I added readline aslo, just need configure code . i.e: if on readline, then use linenoise by default 11:25
s/on/no/
diakopter jnthn: *code_sc = Parrot_pmc_getprop(tc, code, Parrot_str_new_constant(tc, "SC")); 11:27
in write_code_ref 11:28
JimmyZ jnthn: I added most ctrl+key features,included ctrl+r, a, e, u l
diakopter jnthn: do we we the SC attribute?
JimmyZ and ctrl+c aslo
jnthn diakopter: Yes, on Parrot not everything is a 6model object so we use that to make Parrot Subs with an SC. In MoarVM, everything is a 6model object so we always have an ->sc :) 11:29
diakopter k
jnthn diakopter: So that code gets simpler :)
JimmyZ and home end:)
jnthn diakopter: You should be able to find the corresponding read code
JimmyZ: OK, so we essentially have our own fork of linenoise by now? :)
diakopter jnthn: haha closure_to_static_code_ref can be vastly simplified 11:31
jnthn oh hell yes :)
JimmyZ jnthn: I'm with this: Larger programs may use this little library or just checking with configure if readline/libedit is available and resorting to linenoise if not. 11:33
:P 11:34
jnthn JimmyZ: Sure, but what you're saying is you've extended linenoise we use to the point that there's not going to be a system version of it that we can use? 11:37
diakopter jnthn: I think I can do all the serialization stuff in serialization.sc.. but I think you're gonna have to do the serialize repr ops 11:39
JimmyZ jnthn: nope ,I'm with :checking with configure if readline/libedit is available and resorting to linenoise if not.
jnthn: my branch contains realdline api actullay 11:40
diakopter jnthn: we don't need to track contexts separately, since they have their own repr
right?
JimmyZ so do we need a fork? or in MoarVM? 11:41
I'd like +1 to fork though 11:42
diakopter jnthn: hm, nm, I see we do
JimmyZ not_gerd: how about adding libreadline configure? 11:55
11:56 JimmyZ_ joined
JimmyZ_ oh, I understand what jnthn++ said 11:58
nwc10 possibly stupid question - does linenoise have a single upstream? and if so, is it happily taking patches? 12:00
JimmyZ_ jnthn: either use system version readline or use our patched linenoise, I think. I'm not mind to use system one linenoise :-)
nwc10: it's not taking patches 12:01
nwc10 why not?
JimmyZ_ they have redis
tadzik how is that related?
nwc10 that's what I thought. Given "Redis is an open source, BSD licensed, advanced key-value store." 12:02
there's a missing step here :-)
JimmyZ_ Maybe then don't want to take much care of linenoise, because they want to keep linenoise under 1000 lines
they don't want it to be another readline :)
tadzik not this shit again :| 12:03
in a year they'll be saying "yeah, we really meant 2000 loc", like dwm
dalek arVM: fe3c159 | (Gerhard R)++ | / (4 files):
Support noiseless building.

Pass NOISY=1 to make to see actual commands.		 12:04
not_gerd diakopter: ^^
*hopefully* didn't break gmake ;)
nwc10 my (hearsay) understanding of the genesis of linenoise was that "readline is way too large for what it's doing. Pretty much all terminals support VT100, so if we assume that we can write something a lot smaller"
and everything seems to demonstrate that "more than VT100" was *not* the reason for the size. 12:05
it was the features
JimmyZ_ not_gerd: feture request :)
not_gerd ...and there's something wrong with it :(
nwc10 and, here we go, strangely enough, users were using a chunk of the features
JimmyZ_ feature
nwc10 had this at ex-work (sort of) with something completely different
one (very useful) developer (also) had the view that "X" is way too complex
and started on "Y"
did 80%, and then left it to others to finish up 12:06
problem was at the end of finishing, "Y" was about as complex as "X"
becase, what a surprise, the necessary tricky bits add complexity
JimmyZ_ maybe, I just want linenoise works as well as well on linux
nwc10 My frustration here is *not* linenoise, but that everyone has a fork 12:07
JimmyZ_ so I patched it, and add ctrl+r and ctrl+l
works on windows as well as on linux :)
nwc10 cool. Does MongoDB have a fork too? Isn't anyone interested in being the linenoisier upstream? :-/
diakopter not_gerd: thanks!
jnthn Given the last commit was 7 months ago... 12:08
nwc10 if that was CPAN, by now someone would have put a comment on cpanrantings claiming that it was dead :-)
JimmyZ_ jnthn: so how about fork linenoise :)
jnthn JimmyZ_: um, I thought if you'd added extra things to it you basically have already :) 12:09
JimmyZ_ jnthn: no :-) 12:10
dalek arVM: 4dc5c54 | (Gerhard R)++ | build/Makefile.in:
Fix build messages on GNU make
 12:11
not_gerd now, does anyone build using BSD make ;)
JimmyZ_ not_gerd: how about adding readline detection: 12:12
nwc10: I guess it's that feel free if someone thinks our patching linenoise one is more awesome? 12:14
diakopter jnthn: see question 36 min ago 12:15
not_gerd if it were up to me, I'd just add a --no-readline option to Configure.pl that's default on win32 (and possibly darwin/bsd?)
diakopter hasn't heard from TPF yet
jnthn diakopter: The "track contexts separately"? 12:16
diakopter: I didn't really understand
JimmyZ_ not_gerd: oh, by defalut moarvm use linenoise... just need detect whether have readline , and then use it if have one 12:17
not_gerd: github.com/MoarVM/MoarVM/blob/read...ops.c#L349 12:18
jnthn: could you fork/create linenoise later? :P 12:22
12:27 BenGoldberg joined
not_gerd JimmyZ_: you never include readline.h? 12:29
JimmyZ_ not_gerd: not yet, I'm on windows
12:37 jnap joined 13:02 benabik joined
not_gerd benabik: ping 13:03
benabik not_gerd: pong
not_gerd benabik: I might have broken darwin again ;)
could you check if it builds?
benabik tisk, tisk
make clean ; and perl Configure.pl ; and make ... Well, it's compiling things so it's not totally broken. 13:05
not_gerd you see the compiling messages instead of actual commands? 13:06
benabik compiling foo.o... 13:07
linking moarvm
not_gerd \\o/
for bonus points, try `make NOISY=1 tracing`
BenGoldberg .tell diakopter in MoarVM, that fake_crash() function isn't exactly a clean, guaranteed, way to force a program to core dump / seg fault. Shurely abort() or raise(SIGABRT) or raise(SIGSEGV) would be better? 13:10
yoleaux BenGoldberg: I'll pass your message to diakopter.
BenGoldberg .tell diakopter nevermind
yoleaux BenGoldberg: I'll pass your message to diakopter.
13:33 FROGGS joined 13:39 colomon_ joined 13:49 jnap joined
not_gerd ok, I just hacked together some basic readline detection 13:50
note that distributing a binary package linked against readline will make it GPL
FROGGS linenoise was under the MIT license, right? 13:51
not_gerd FROGGS: BSD 13:52
2-clause
FROGGS would that be preferable?
did I mention that I hate licensing issues? 13:53
tadzik don't we all 14:01
14:02 Ben_Goldberg joined
nwc10 www.thrysoee.dk/editline/ is BSD licensed, but it's not at all obvious how widespread it is 14:07
not_gerd nwc10: it's fine as-is (link against readline if available or falls back to linenoise) 14:09
nwc10 cool
FROGGS k 14:10
not_gerd it just has to be made clear to people who want to create derivative work that they can't link against readline if they don't want to license their own work under the GPL as well
Artistic2 licensed code can always be relicensed under the GPL 14:11
it's just that linking against readline necessarily does so
14:11 benabik joined
not_gerd (on re-distribution) 14:11
dalek arVM/readline: ea7a0ab | (Gerhard R)++ | build/auto.pm:
Auto-detect readline
 14:17
14:23 crab2313 joined
dalek Heuristic branch merge: pushed 23 commits to MoarVM/readline by gerdr 14:25
arVM/readline: 5862284 | (Gerhard R)++ | / (4 files):
Wire up MVM_HAS_READLINE and --no-readline
 14:55
JimmyZ_ not_gerd++
not_gerd: Is there a good way to disable compiling linenoise when linked to readline? 15:06
not_gerd JimmyZ_: should already work 15:07
JimmyZ_ oh
dalek arVM/readline: 3d8c656 | (Gerhard R)++ | Configure.pl:
Clarified implications of not using --no-readline
 15:11
arVM/readline: c5e1504 | (Gerhard R)++ | build/ (2 files):
Add /nologo to nmake invocation
 15:30
arVM: 569b23f | (Gerhard R)++ | build/ (2 files):
Add /nologo to nmake invocation
JimmyZ_ not_gerd: src/gen/config.h:43:6: error: #error "Failed to detect endianness"
not_gerd: I'm on CentOS
not_gerd gcc?
JimmyZ_ gcc version 4.4.7 20120313 (Red Hat 4.4.7-3)
not_gerd could you gist `gcc -dM -E - </dev/null` 15:31
JimmyZ_ not_gerd: gist.github.com/zhuomingliang/6308766 15:33
not_gerd hm...
I don't see any endian-specific macros at all :(
JimmyZ_ :( 15:34
not_gerd could you do `find /usr/include/ | grep endian` or something equivalent? 15:37
15:38 benabik joined
JimmyZ_ /usr/include/linux/byteorder/big_endian.h 15:48
/usr/include/linux/byteorder/little_endian.h
/usr/include/bits/endian.h
/usr/include/endian.h
not_gerd: ^^
not_gerd I've got endian.h and bits/endian.h on cygwin as well 15:50
JimmyZ not_gerd: how about adding libreadline configure?2q
JimmyZ_ what? 15:51
bad connection
not_gerd JimmyZ_: you need libreadline-dev (or whatever your package manager calls it)
JimmyZ_ not_gerd: I'm not asking it 15:52
not_gerd ok
JimmyZ_: could you gist bits/endian.h
JimmyZ_ I have a bad connection to centos
not_gerd: gist.github.com/zhuomingliang/6309101 15:55
not_gerd thanks
JimmyZ_ not_gerd: it said x86_64 is little-endian. 15:56
not_gerd: and gcc -dM -E - </dev/null has x86_64 define
not_gerd JimmyZ_: sure, but than we'd have to keep a whitelist 15:57
JimmyZ_ how about? #define __BYTE_ORDER __LITTLE_ENDIAN
not_gerd can I see endian.h as well ;)
JimmyZ_ ;) 15:58
Good night 15:59
not_gerd o/
benabik has i386/endian.h and machine/endian.h 16:01
not_gerd it's a mess 16:03
on some ancient Redhat system with gcc 3.3 I got access to, _LITTLE_ENDIAN was used to denote the architecture directly, whereas with endian.h, you need to test _BYTE_ORDER == _LITTLE_ENDIAN 16:04
I wanted to avoid compiling test programs for endian detection because that does not work with cross-compilation 16:05
benabik BYTE_ORDER == LITTLE_ENDIAN 16:30
16:33 jnap joined
dalek arVM: 7bd2129 | (Gerhard R)++ | / (3 files):
Take byte order from Perl's %Config.

In case of cross builds, use explicit --big-endian.
Conditional compilation now also consistently checkes for definedness of MVM_BIGENDIAN.		 17:08
not_gerd benabik: I took inspiration from Parrot and just queried %Config 17:09
~~ 17:10
17:10 not_gerd left 17:24 jnap joined
jnthn arrgh 17:36
We weren't meant to be making the build system depend on Perl 5 config :/
TimToady Feel the hatred! :) 17:39
so we're going to be linking in a P5, but we can't use P5 to figure out how to do that? :)
and cross-compiling would be really easy just by coping a config back from the other machine 17:43
*copying
it just feels to me more like a remnant of parrot's perl antipathy than a reasoned design decision 17:45
but maybe that's just me :) 17:46
I would agree that 'use Config;' is assuming no cross-compilation, so probably one would want some way to interrogate a config file more directly, so you could slip a different one in there 17:48
Config_heavy.pl contains all the info in one package, so a copy of that would probably work for cross-compile purposes 17:54
though you'd probably want to put stuff into %Cross::Config rather than %Config, so you don't clobber your local configuration 17:56
well, anyway, maybe I should do something productive... 17:57
nwc10 brew coffee; drink coffee; ? :-) 18:02
FROGGS my problem with P5's config was that some modules query it to know what CC an XS module should use, but nobody guarantees that the user really has this CC installed 18:09
in most cases this CC isnt even the default
TimToady well, we're probably not compiling a lot of XS modules to produce moarvm... 18:10
(I hope) 18:11
FROGGS true
*g*
so maybe one an trust P5 about endianess, but definitely about CC 18:12
but I think we already have a proper CC detection
TimToady the nice thing about information is that one can pick and choose what to believe
as I recall, p5 can even tell you about mixed-endian architectures 18:13
byteorder='12345678'
some of the DEC machines turned out mixed-endian, iirc 18:14
jnthn aye, though trusting bits of one thing and bits of another risks weird inconsistency 18:15
FROGGS well, we wont detect CC on our own and take the CFLAGS from P5
TimToady jnthn: you've just characterized cross-compilation in general :)
it's called that because it makes you cross, or at least cross-eyed 18:16
jnthn diakopter: I backlug the bit I think you meant. 18:22
FROGGS baccklug? hehe 18:23
jnthn diakopter: I suspect much work goes on in QASTMoar.nqp building up the instruction processing stuff. That almost certainly can be done at BEGIN time.
diakopter: Not sure if we have all the pieces in place to do it yet, but it should be possible.
diakopter: The stuff that goes on in loading NQPCORE should be comparatively small... 18:24
If anybody fancies applying some patches, Andy Dougherty has sent some MoarVM patches to perl6-compiler for Solaris building :) 18:26
If not I'll get to 'em in a bit 18:27
nwc10 TimToady: I removed a chunk of the mixed endian code about a month ago. I infer that some of it had had to have been broken for a decade or more 18:35
but that part might have been the fallbacks if system routines were missing 18:36
18:36 not_gerd joined
not_gerd o/ 18:36
18:36 benabik joined
not_gerd jnthn: I found querying P5 %Config the least evil way 18:36
compiler defines are inconsistent
keeping whitelists is bad
standard header may be endian.h sys/endian.h or sys/param.h
jnthn not_gerd: I guess those are greater evils... 18:37
:)
Leave it for now. There's almost certainly more worthwhile things to be doing.
not_gerd the only portable way is building a program that determines endianness at runtime
I try to avoid that as much as possible
nwc10 yes, totally. Correct triaging (I feel) is "get things building" for now, and clean it up later. (But not *never*) 18:38
but I'm likely cranky and biased, and this isn't my lawn.
not_gerd ona related note, shoudl feature macros be defined with values 0 or 1 and checked via #if or conditionally defined and checked via #ifdef ? 18:40
FROGGS I like #ifdefs fwiw 18:42
diakopter not_gerd: is there an effective difference? 18:49
yoleaux 13:10Z <BenGoldberg> diakopter: in MoarVM, that fake_crash() function isn't exactly a clean, guaranteed, way to force a program to core dump / seg fault. Shurely abort() or raise(SIGABRT) or raise(SIGSEGV) would be better?
13:11Z <BenGoldberg> diakopter: nevermind
not_gerd diakopter: not really 18:50
mixing conventions can get confusing, though
diakopter not for those of us who don't notice conventions
not_gerd ;)
FROGGS hehe
diakopter++
not_gerd you can get away with quite some sloppyness as an #if will happily accept un defined value 18:51
the preprocessor considers those 0
using #ifdef with a value defined to 0, though...
diakopter I did it with 0/1 because it seemed fastest to implement 18:52
I was having trouble estimating how long it would take to make it conditionally define using the config.h.in
FROGGS so we go with #if no matter what?
not_gerd no, that would break for positive values that are merely defined and not defined to non-zero 18:53
diakopter if with random magic values, yes
:)
not_gerd think -DFOO vs -DFOO=1
dalek arVM: 4e0ed79 | (Gerhard R)++ | build/config.h.in:
Make MVMint8 a signed char - signedness of plain char is implementation-defined
 18:54
diakopter not_gerd: should short be signed short? 19:03
and int.. and longong
not_gerd diakopter: no
benabik I think short/int/long are signed by standard, but char is 'whatever' 19:04
diakopter k
not_gerd for hysterical raisons, that's only true for char
diakopter TimToady: is it cargo culting to talk about cargo culting? 19:05
benabik C89 3.1.2.5: There are four signed integer types, designated as signed char, short int, int, and long int
diakopter cries at the hundreds of gcc warnings 19:06
FROGGS diakopter: np, somebody will care :o) 19:07
diakopter well last time I reconciled them all (more than ayear ago) I found genuine bugs
not_gerd clang -Weverything -Werror 19:08
add stuff like -Wno-padded to remove false positives and keep fixing errors until your code compiles
FROGGS diakopter: true
clang is really cool for these kind of things
diakopter not_gerd: another configure/build request :) 19:09
not_gerd GNU make is nice in that regard as you can add -Wno-* options on a per-file basis
diakopter need dynamic libraries of every .o/.obj, so we can build a dynamic libmoarvm 19:10
(and also a static one)
need to make a custom .c inference rule (or 5) 19:11
(I presume)
arnsholt Mmmm. Implicit rules 19:13
diakopter TimToady: but we won't actually be linking to libperl all the time - it'll fallback to not do it if it doesn't find a libperl (unless someone makes a magic perlbrew thing that reproduces the build environment of the non-libperl perl installation)
or if someone does --no-embedp5 19:14
arnsholt I've written quite a few of those for gmake, but I've no idea how nmake works for those
diakopter arnsholt: I know how to do it
see the dyncall branch Makefile.in
er, the Makefile it generates rather
not_gerd arnsholt: old-style syntax .c.o
works in GNU, BSD and MS
arnsholt Yeah, it's not hard. But they have bitten me on the ass repeatedly =)
Right, old-style is usually good for portability I guess 19:15
not_gerd conditionals use different syntax, though - !if, .if, ifeq
also, portable special variables are rare 19:16
among those are $@ and $* though, which was enough to get the inference rules going
diakopter not_gerd: do you want to tackle the building of the libraries? 19:17
not_gerd anyone knows which architectures need -fPIC off-hand? 19:18
diakopter all windows I thought 19:19
not_gerd: I'll take that as a yes... :)
not_gerd diakopter: at least gcc/mingw can build DLLs from ordinary object files 19:21
moritz "man gcc" says about -fPIC: This option makes a difference on the m68k, PowerPC and SPARC.
19:24 jnap joined
diakopter reads www.symantec.com/connect/articles/d...s-part-one 19:27
jnthn: I fuzzed a segfault out of moarvm nqp.moarvm :D 19:34
mwilson@host07:~/src/MoarVM/nqp-cc$ ../moarvm nqp.moarvm -s -- foo.nqp
Unknown compilation stage 'classname'
frame_name_949Segmentation fault
.oO( what do you mean by 'classname'? )
 19:35
jnthn Copied from JVM and not needed for MoarVM 19:36
...what is -s? :) 19:37
diakopter yeah but what in the world called it
just me figuring out that it's ignoring that arg
mwilson@host07:~/src/MoarVM/nqp-cc$ ../moarvm nqp.moarvm '' -e '1'
Illegal option --.
This compiler is based on HLL::Compiler.
...
Segmentation fault
jnthn It means you ade it into compile
*made 19:38
and it's iterating thorugh the compilation stages
diakopter \\o/
19:39 donaldh joined
diakopter mwilson@host07:~/src/MoarVM/nqp-cc$ ../moarvm nqp.moarvm '' -e '' 19:39
Error encoding UTF-8 string near grapheme position 17 with codepoint 920684456
line 1224 in nqp-src/NQPHLL.nqp (op <unknown>, instr 0<unknown>, frame frame_name_896, compunit ./NQPHLLMoar.moarvm)
(*sigh*)
position 17 ?!? 19:40
not_gerd: I think something's still wonky with the clargs stuff
^ should not be happening
jnthn diakopter: That's happening quite a way in, fwiw.
May be clargs related, but maybe not too... 19:41
diakopter oh
mwilson@host07:~/src/MoarVM/nqp-cc$ ../moarvm nqp.moarvm 'foo.nqp' 19:42
Failed to tell position of filehandle: Illegal seek
*sigh*
masak: when I find brokenness with *every* attempt... what does that say about the fuzziness vs. readiness? 19:43
(note: I think it's far more likely that it's my code that's causing most of these problems than otherwise) 19:45
TimToady well, it's either somebody's code, or lack thereof... 19:52
19:57 jnap joined
masak diakopter: just note it all down, so that it can all be trawled through in due time. 20:02
diakopter: journeys consisting of small steps, etc.
diakopter masak: I think these issues are the pebbles at the top of the dam that are threatening to fall over 20:14
hopefully the rest of the dam surrenders to the flow quickly 20:15
jnthn suspects nobody but him was really hacking on NQP JVM selfhost and so has been through this before :)
masak pebbles, dams. they all need to be packaged and submitted. :) 20:16
20:16 jnap joined
jnthn Anyway, this is all at least a bit familiar. At first, it falls in a big heap before really doing anything. :) 20:16
diakopter I'm very sure the string impl are algorithmically sound.. if anything there are tiny errors in implementation 20:17
the things at the top of ops.c need tackled soon-ish
not_gerd ~~ 21:38
21:38 not_gerd left 21:59 jnap joined
masak hehe, "need tackled". :) 22:04
diakopter need tackled? 22:10
[to be] 22:11
22:13 yoleaux joined 22:14 yoleaux joined 22:29 benabik joined 22:32 yoleaux joined
dalek MoarVM: c512e1b | doughera++ | build/Makefile.in: 22:40
MoarVM: Remove nonportable conditional commands from Makefile.in
MoarVM:
MoarVM: Not all makes support conditional IF/ELSE/ENDIF statements.
MoarVM: Specifically, the /usr/bin/make supplied with Solaris 11 does not.
22:41 dalek joined
jnthn 4 patches from doughera++ 22:41

Powered by Cro and the Raku® Programming Language.

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

Thank you!