Camelia, the Perl 6 bug

IRC log for #moarvm, 2013-08-22

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

All times shown according to UTC.

Time Nick Message
00:21 jnap joined #moarvm
00:31 FROGGS joined #moarvm
00:59 Ben_Goldberg joined #moarvm
01:45 dalek MoarVM: c66a644 | diakopter++ | src/gc/orchestrate.c:
01:45 dalek MoarVM: note to self
01:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c66a644085
01:47 segomos note to self
01:48 diakopter ? :)
02:19 diakopter segomos: ok..?
02:20 benabik joined #moarvm
02:26 JimmyZ Good morning
02:27 TimToady o/
02:28 diakopter TimToady: well..
02:28 diakopter TimToady: I disable closing of stdout
02:28 diakopter and ..\moarvm.exe nqp.moarvm -e 1   ... eats 8GB ram in 1 second
02:29 diakopter probably that's not what was intended, and probably won't work, except in the very long term
02:31 diakopter TimToady: at least it's .. fast.... or something
02:31 diakopter *sigh* now I have to add some form of tracing
02:37 diakopter .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.
02:39 JimmyZ \o
02:40 diakopter JimmyZ: g'morning
02:42 JimmyZ morning
02:43 dalek MoarVM: 83bca4d | diakopter++ | src/ (3 files):
02:43 dalek MoarVM: don't close std streams... for now...
02:43 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/83bca4d544
02:43 dalek MoarVM: 2bb0d04 | diakopter++ | src/core/exceptions. (2 files):
02:43 dalek MoarVM: make MVM_exception_backtrace_line non-static and free what it returns... :/
02:43 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2bb0d048cc
03:41 dalek MoarVM: 5bb825e | diakopter++ | / (6 files):
03:41 dalek MoarVM: add very naive every-instruction tracing.... <lol>
03:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5bb825e292
03:42 diakopter TimToady: lololol https://gist.github.com/dia​kopter/b3b85ed4b6c7df7779ac
03:42 diakopter JimmyZ: ^
03:42 JimmyZ lol
03:43 diakopter the twenty null instrunctions in a row are curious
03:43 diakopter lolol instr 53857808
03:43 diakopter .oO( stop instructing me so much.. )
03:44 diakopter .oO( 53 million instructions in one routine is .. a lot )
03:44 JimmyZ :-)
03:44 JimmyZ we need break point :)
03:45 JimmyZ could be added into nqp though
03:48 diakopter well the end betrays the infinite loop
03:49 diakopter erm.
03:49 diakopter actually not.
03:49 * diakopter lets it run a while longer
03:51 diakopter HAHAHAHAHA
03:54 diakopter JimmyZ: it's looping in the interactive prompt b/c the readline prompt and ensuing eval is commented out :)
03:55 diakopter (yay, nqp is "running", fsdo running)
03:56 diakopter it has to execute around 250k interpreter runloop instructions to get to that readline prompt
03:56 JimmyZ wat, that's too much instr
03:56 TimToady "This file has been truncated" tee hee
03:56 TimToady perhaps it's really calling into a PRNG
03:56 TimToady wasn't someone threatening to throw in a Mersenne Twistor?
03:57 diakopter no that's including loading the whole nqp setting and compiler code
03:57 diakopter and doing all the deserialization required
03:57 diakopter I'd paste it, but it's a quarter million lines...
03:58 diakopter well, I'd probably nopaste it instead of pasting it
03:58 JimmyZ FYI, m0 has a break point/step debuger, and this https://gist.github.com/zhuomingliang/2706999
04:00 diakopter "loading" the nqp setting involves running a lot of coe.
04:00 diakopter code, even
04:00 diakopter brb; dinner
04:02 diakopter actually.
04:02 diakopter .ask jnthn how much of *Moar.nqp can we wrap in BEGIN { }.. hopefully lots?   also, plz read scrollback in moar
04:02 yoleaux diakopter: I'll pass your message to jnthn.
04:04 FROGGS joined #moarvm
04:04 diakopter FROGGS: read the clogs for here... brb
04:23 FROGGS joined #moarvm
04:23 diakopter JimmyZ: I could fake up a quick and dirty readline
04:46 JimmyZ diakopter: not based lineniose?
04:49 diakopter JimmyZ: well I could but I thought your branch depended on libuv
04:51 dalek joined #moarvm
04:52 JimmyZ diakopter: I couldn't got it
04:52 diakopter ?
04:53 JimmyZ my branch depended on libuv?
04:53 diakopter libuv is not in your branch?
04:53 diakopter linenoise branch
04:54 JimmyZ yeah, linenoise doesn't depend on libuv
04:54 JimmyZ but linenoise doesn't depend on libuv
04:54 diakopter okay; could you merge master into your linenoise branch?
04:54 JimmyZ diakopter: ok
04:59 diakopter JimmyZ: also into libuv?: )
04:59 diakopter :)
05:00 diakopter libuv5 branch, I mean
05:01 dalek Heuristic branch merge: pushed 102 commits to MoarVM/readlineintfh2 by zhuomingliang
05:02 diakopter it merged cleanly!@?!
05:04 JimmyZ no :)
05:06 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 #moarvm
05:11 diakopter JimmyZ++
05:14 dalek MoarVM/readlineintfh2: 2fb237f | jimmy++ | build/ (2 files):
05:14 dalek MoarVM/readlineintfh2: fixed build
05:14 dalek MoarVM/readlineintfh2: review: https://github.com/MoarVM/MoarVM/commit/2fb237f0bd
05:19 JimmyZ all build now :-)
05:19 * JimmyZ would like to merge these branches to master to avoids merge conflict :P
05:35 crab2313 joined #moarvm
05:52 not_gerd joined #moarvm
05:52 not_gerd o/
05:53 not_gerd diakopter: I can probably make the tracing/no-tracing a make-time instead of configure-time decision
05:53 JimmyZ good
05:53 not_gerd ie so you can use `nmake tracing` and `nmake no-tracing` without having to re-configure
05:54 not_gerd diakopter: should I go ahead?
05:54 JimmyZ I'd +1
05:54 JimmyZ re-configure means almost re-build
05:55 not_gerd we really only need to rebuild main.obj and core/interp.obj
05:56 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
05:56 not_gerd it'l probably look like `nmake tracing TRACING=0` and `nmake tracing TRACING=1`
05:57 JimmyZ how about steal ideas from  m0-debug branch :)
06:21 grondilu joined #moarvm
06:25 not_gerd [x] done
06:25 not_gerd should I push to master?
06:25 not_gerd (or branch for now?)
06:27 JimmyZ nmake tracing?
06:28 dalek MoarVM: 9298332 | (Gerhard R)++ | / (6 files):
06:28 dalek MoarVM: Make tracing a build-time instead of configuration-time decision.
06:28 dalek MoarVM:
06:28 dalek MoarVM: Instead of a configuration flag --tracing, there are now
06:28 dalek MoarVM: build targets 'tracing' and 'no-tracing'.
06:28 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9298332b05
06:28 not_gerd forgiveness > permission
06:29 JimmyZ not_gerd: it's nice
06:31 JimmyZ what's the new api for repalce apr atomic?
06:34 not_gerd none yet
06:35 not_gerd the MVM_cas() macro isn't implemented yet
06:35 not_gerd I did do the work to rip out the GPL stuff from libatomic_ops, though
06:35 JimmyZ e.
06:35 not_gerd see https://github.com/gerdr/li​batomic_ops/commits/moarvm
06:36 JimmyZ I did see this branch :-)
06:36 not_gerd I can import that into MoarVM
06:36 not_gerd I don't know how up-to-date the cygwin autotools are, though
06:37 not_gerd might de better if someone on a recent linux does this
06:37 not_gerd * be
06:37 JimmyZ note: four of us are on windows
06:38 JimmyZ ;)
06:38 JimmyZ but jnthn++ said libatomic_ops should be in github.com/MoarVM/libatomic_ops ?
06:41 not_gerd as I understand it, he wants to use packaged versions of 3rdparty libs as much as possible
06:42 not_gerd and I don't have permission to create forks on MoarVM anyway ;)
06:46 JimmyZ not_gerd: how about creating branch to implement MVM_cas()
06:46 JimmyZ like libuv
06:58 not_gerd JimmyZ: doesn't really need a branch - just libatomic_ops to be imported
06:58 JimmyZ oh
06:59 JimmyZ so only blocker: sockect \o/
07:00 not_gerd JimmyZ: as far as I can see, yes
07:00 FROGGS joined #moarvm
07:00 JimmyZ the libuv is using callback, so it's hard to me
07:01 JimmyZ *libuv sockect api
07:02 not_gerd async io really wants to be integrated with the scheduler to provide a blocking API on top of it
07:02 not_gerd that needs some design work
07:15 JimmyZ yeah
07:15 JimmyZ and async tty :(
07:19 donaldh joined #moarvm
07:25 donaldh joined #moarvm
08:09 diakopter JimmyZ: no, jnthn meant to bundle it inside the MoarVM/MoarVM, as I understood it
08:09 diakopter so you can't nmake without doing no-tracing?
08:10 not_gerd diakopter: you'll only use that information after modifying main.c or core/interp.c
08:10 not_gerd plain `nmake` doesn't trace
08:10 diakopter not_gerd: I don't think any of us uses cygwin
08:11 diakopter (to build moar anyway)
08:11 JimmyZ diakopter: not_gerd uses :P
08:11 diakopter ok well that'll be a problem for libuv
08:11 not_gerd diakopter: shouldn't really matter where autog
08:11 not_gerd * gen.sh gets called
08:12 not_gerd diakopter: I only use cagwin for the shell environment and cross-compiler packages
08:12 diakopter I wasn't thinking of that
08:12 not_gerd * cygwin
08:12 diakopter I wasn't thinking of autogen
08:12 diakopter I was thinking of the library's code and how it doesn't support cygwin
08:12 not_gerd diakopter: sure, but I'm targeting MinGW64, not Cygwin
08:13 diakopter oh
08:13 JimmyZ sometimes I think we could implement our atomic for both windows and linux
08:14 JimmyZ 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
08:14 not_gerd our Configure.pl supports it, just not APR
08:15 JimmyZ we're removing APR
08:15 diakopter okay; I don't know enough to know what that means
08:15 not_gerd diakopter: just that I've got a frankenstein setup going
08:16 not_gerd I tried to keep orthogonal decisions orthogonal whenrefactoring Configure.pl
08:16 JimmyZ not_gerd: you want  --shell=rc ? the plan9 shell
08:16 JimmyZ ;)
08:17 not_gerd JimmyZ: well, right now we only need rm and cat
08:17 not_gerd I believe those are in rc?
08:17 JimmyZ hehe
08:17 not_gerd diakopter: I believe I can do the libatomic_ops import now
08:18 diakopter sounds good
08:18 diakopter does the new version support 32-bit cas?
08:19 not_gerd diakopter: I don't believe so
08:19 diakopter aww
08:19 not_gerd all values we want to access atomically need to be pointer-sized
08:19 diakopter oh well
08:19 diakopter apr claims to do it
08:19 FROGGS joined #moarvm
08:20 not_gerd there's AO_HAVE_int_compare_and_swap(), but that wasn't available on windows last we checked
08:21 not_gerd * AO_int_compare_and_swap()
08:21 not_gerd which can be checked via AO_HAVE_int_compare_and_swap
08:21 diakopter does it have AO_int_fetch_compare_and_swap
08:22 diakopter er, wherever the fetch goes
08:22 JimmyZ on windows we can use windows api :)
08:22 diakopter right, I'm sure the guy would take a pull request to add it to lao
08:23 diakopter 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
08:23 diakopter see my dyncall branch if you want, or don't. ;)
08:23 not_gerd ;)
08:25 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 diakopter much easier to read warnings & errors when the command echoing is off, imho
08:25 diakopter and also easier on the eyes in normal build
08:26 diakopter thoughts?
08:26 not_gerd might by able to get it to work as `nmake NOISY=1`
08:26 not_gerd need to test if it works in nmake/gmake both
08:26 diakopter I did something like that in the dyncall branch, but probably badly
08:27 diakopter also the realclean target needs to remove the makefiles of all the 3rdparty things too
08:28 diakopter and other config stuff
08:29 diakopter imho
08:29 diakopter JimmyZ: did jnthn have any specific objections to linenoise? or just he hadn't looked into it yet?
08:30 not_gerd diakopter: I think it was a general objection against bundling 3rdparty libs to make packagers life easier
08:30 not_gerd I thinke linenoise is small enough to make an exception, though
08:31 not_gerd also, JimmyZ added windows support
08:31 diakopter this is strange to me since originally he didn't want any external dependencies
08:31 diakopter I thought he meant to put our fork of lao directly into MoarVM/MoarVM
08:31 not_gerd http://irclog.perlgeek.de/m​oarvm/2013-08-21#i_7482708
08:32 diakopter oh, the line above, you mean
08:32 diakopter that's the one I missed
08:32 diakopter (read too quickly)
08:32 diakopter I did read the line you highlighted
08:33 diakopter it's just that last I checked there wasn't a system package for libatomic_ops
08:33 diakopter that was anywhere close to up-to-date, maybe
08:35 diakopter not_gerd: I can create repos in /MoarVM
08:35 diakopter I think you can too
08:37 not_gerd I just tried to transfer the repo
08:37 not_gerd no dice
08:37 not_gerd (You don't have admin rights to MoarVM)
08:37 diakopter I think you have to create it first through the web interface
08:37 diakopter you don't have access to that?
08:38 diakopter oh, neither do I... nm
08:45 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?
08:45 diakopter in the same dir tree as the source code?
08:45 diakopter maybe one README.markdown per directory so it shows up in github browser?
08:46 diakopter ok I sold myself on that idea; I'll start with that
08:47 dalek MoarVM/atomic: 03ecaa1 | (Gerhard R)++ | / (140 files):
08:47 dalek MoarVM/atomic: Import modified f38b2904 of ivmai/libatomic_ops
08:47 dalek MoarVM/atomic: review: https://github.com/MoarVM/MoarVM/commit/03ecaa1e55
08:47 JimmyZ .md is ok too
08:47 not_gerd ^ needs testing, in particular non-windows where the configuratio n actually gets triggered
08:50 diakopter shouldn't include the gpl license if we're not redistributing gpl code
08:51 not_gerd diakopter: some of the scripts are GPL
08:52 diakopter what scripts
08:52 not_gerd the testing code that used to be included is as well
08:52 not_gerd decomp, missing
08:52 not_gerd it's  a non-issue
08:52 diakopter do we need those?
08:52 not_gerd we even could have distributed the GPL source files
08:52 not_gerd as long as we don't link libatomic_ops_gpl.a, we're fine
08:53 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 diakopter it's viewed as very dangerous
08:53 diakopter huge stigma
08:53 diakopter in US companies
08:54 not_gerd well, then say goodby to autotools
08:54 diakopter I didn't think we needed it necessairly
08:54 not_gerd config.sub and config.guess are GPL as well
08:55 JimmyZ so re-imported to make sure GPL is not in the repo history :P
08:56 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:57 not_gerd or just not distribute the generated scripts
08:57 not_gerd would force the user to have autotools available, though
08:57 diakopter oh, I think that's definitely okay
08:58 diakopter it's highly unlikely those aren't there on everything but cmd.exe
08:59 not_gerd errands&
09:00 diakopter not_gerd++ # thanks for importing the lao :)
09:02 JimmyZ not_gerd++ indeed
09:03 diakopter JimmyZ++ not_gerd++ # really taking the bull by the horns!
09:04 JimmyZ :)
09:19 not_gerd should I remove the generated files + COPYING from the branch?
09:21 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
09:22 diakopter JimmyZ: why?
09:22 diakopter I think it's fine how it is... but jnthn may disagree, of course, and not want the build-time gpl stuff at all
09:22 JimmyZ if removing
09:23 JimmyZ because git clone is slow here
09:24 diakopter heh.
09:24 FROGGS[mobile] joined #moarvm
10:05 dalek MoarVM: 5fee6da | diakopter++ | / (10 files):
10:05 dalek MoarVM: beginnings of source code/repo documentation.. designed to be visible when browsing the source tree in github.
10:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5fee6da99d
10:06 crab2313 joined #moarvm
10:10 donaldh joined #moarvm
10:29 dalek MoarVM: 5aa78f8 | diakopter++ | src/ (4 files):
10:29 dalek MoarVM: stub in serialization
10:29 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5aa78f8617
10:57 not_gerd should I merge atomic into master?
11:00 jnthn not_gerd: With the updates to the lib, yes?
11:00 not_gerd jnthn: yes
11:00 jnthn +1
11:00 not_gerd the only concern was that autotools-generated config scripts are GPL
11:00 jnthn huh...
11:01 not_gerd it's not an issues as long as you don't link against GPL code
11:01 not_gerd ie we could have distributed the GPL stuff as well without problem
11:01 jnthn Generated code can be under GPL too...teh oddness :)
11:01 not_gerd ;)
11:01 jnthn Guess it counts as derived work or something...
11:02 not_gerd diakopter was just concerned about corporate GPL-aversion
11:02 jnthn *nod*
11:02 not_gerd his conclusion was just to clearly note the license in a README.md and move along
11:02 diakopter (already pushed)
11:02 not_gerd alternatively, we'd have to rely on autotools-availability on used-side
11:03 jnthn Yes, I find the GPL's freedom-enforcing approach tends to give me less freedom to build stuff. :)
11:04 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:05 not_gerd in that case, Apache2 probably would have been more appropriate
11:05 not_gerd *care
11:07 not_gerd so, merge away?
11:07 jnthn aye
11:08 dalek MoarVM: 03ecaa1 | (Gerhard R)++ | / (140 files):
11:08 dalek MoarVM: Import modified f38b2904 of ivmai/libatomic_ops
11:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/03ecaa1e55
11:08 dalek MoarVM: c6dc357 | (Gerhard R)++ | / (140 files):
11:08 dalek MoarVM: Merge branch 'atomic'
11:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c6dc35742a
11:09 not_gerd jnthn: if we want to keep a fork of libatomic_ops, you'll have to do the honours
11:10 jnthn Which honours in particular? :)
11:10 jnthn 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.
11:10 not_gerd creating a fork of ivmai/libatomic_ops in MoarVM
11:11 jnthn ah, ok
11:11 JimmyZ and libuv
11:11 JimmyZ and linenoise?
11:14 diakopter .. and dyncall
11:15 diakopter .. and the bignumber thing
11:17 jnthn When MongoDB adopted linenoise, there were no shortage of complaints. e.g. https://jira.mongodb.org/browse/SERVER-3914 and many others linked from https://jira.mongodb.org/browse/SERVER-4312
11:21 * JimmyZ can't open it
11:22 JimmyZ 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.
11:23 JimmyZ jnthn: I added a lot of feature to linenoise
11:23 JimmyZ and works on windows
11:25 JimmyZ jnthn: I added readline aslo, just need configure code . i.e: if on readline, then use linenoise by default
11:25 JimmyZ s/on/no/
11:27 diakopter jnthn: *code_sc = Parrot_pmc_getprop(tc, code, Parrot_str_new_constant(tc, "SC"));
11:28 diakopter in write_code_ref
11:28 JimmyZ jnthn: I added most ctrl+key features,included ctrl+r, a, e, u l
11:28 diakopter jnthn: do we we the SC attribute?
11:28 JimmyZ and ctrl+c aslo
11:29 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
11:29 jnthn diakopter: So that code gets simpler :)
11:29 JimmyZ and home end:)
11:29 jnthn diakopter: You should be able to find the corresponding read code
11:29 jnthn JimmyZ: OK, so we essentially have our own fork of linenoise by now? :)
11:31 diakopter jnthn: haha closure_to_static_code_ref can be vastly simplified
11:31 jnthn oh hell yes :)
11:33 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:34 JimmyZ :P
11:37 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:39 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.
11:40 JimmyZ 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
11:40 diakopter right?
11:41 JimmyZ so do we need a fork? or in MoarVM?
11:42 JimmyZ I'd like +1 to fork though
11:42 diakopter jnthn: hm, nm, I see we do
11:55 JimmyZ not_gerd: how about adding libreadline configure?
11:56 JimmyZ_ joined #moarvm
11:58 JimmyZ_ oh, I understand what jnthn++ said
12:00 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 :-)
12:01 JimmyZ_ nwc10: it's not taking patches
12:01 nwc10 why not?
12:01 JimmyZ_ they have redis
12:01 tadzik how is that related?
12:02 nwc10 that's what I thought. Given "Redis is an open source, BSD licensed, advanced key-value store."
12:02 nwc10 there's a missing step here :-)
12:02 JimmyZ_ Maybe then don't want to take much care of linenoise, because they want to keep linenoise under 1000 lines
12:02 JimmyZ_ they don't want it to be another readline :)
12:03 tadzik not this shit again :|
12:03 tadzik in a year they'll be saying "yeah, we really meant 2000 loc", like dwm
12:04 dalek MoarVM: fe3c159 | (Gerhard R)++ | / (4 files):
12:04 dalek MoarVM: Support noiseless building.
12:04 dalek MoarVM:
12:04 dalek MoarVM: Pass NOISY=1 to make to see actual commands.
12:04 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fe3c159f5c
12:04 not_gerd diakopter: ^^
12:04 not_gerd *hopefully* didn't break gmake ;)
12:04 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"
12:05 nwc10 and everything seems to demonstrate that "more than VT100" was *not* the reason for the size.
12:05 nwc10 it was the features
12:05 JimmyZ_ not_gerd: feture request :)
12:05 not_gerd ...and there's something wrong with it :(
12:05 nwc10 and, here we go, strangely enough, users were using a chunk of the features
12:05 JimmyZ_ feature
12:05 nwc10 had this at ex-work (sort of) with something completely different
12:05 nwc10 one (very useful) developer (also) had the view that "X" is way too complex
12:05 nwc10 and started on "Y"
12:06 nwc10 did 80%, and then left it to others to finish up
12:06 nwc10 problem was at the end of finishing, "Y" was about as complex as "X"
12:06 nwc10 becase, what a surprise, the necessary tricky bits add complexity
12:06 JimmyZ_ maybe, I just want linenoise works as well as well on linux
12:07 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
12:07 JimmyZ_ works on windows as well as on linux :)
12:07 nwc10 cool. Does MongoDB have a fork too? Isn't anyone interested in being the linenoisier upstream? :-/
12:07 diakopter not_gerd: thanks!
12:08 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 :-)
12:08 JimmyZ_ jnthn: so how about fork linenoise :)
12:09 jnthn JimmyZ_: um, I thought if you'd added extra things to it you basically have already :)
12:10 JimmyZ_ jnthn: no :-)
12:11 dalek MoarVM: 4dc5c54 | (Gerhard R)++ | build/Makefile.in:
12:11 dalek MoarVM: Fix build messages on GNU make
12:11 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4dc5c54e03
12:11 not_gerd now, does anyone build using BSD make ;)
12:12 JimmyZ_ not_gerd: how about adding readline detection:
12:14 JimmyZ_ nwc10: I guess it's that feel free if someone thinks our patching linenoise one is more awesome?
12:15 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?)
12:15 * diakopter hasn't heard from TPF yet
12:16 jnthn diakopter: The "track contexts separately"?
12:16 jnthn diakopter: I didn't really understand
12:17 JimmyZ_ not_gerd: oh, by defalut moarvm use linenoise... just need detect whether have readline , and then use it if have one
12:18 JimmyZ_ not_gerd: https://github.com/MoarVM/MoarVM/blob​/readlineintfh2/src/io/fileops.c#L349
12:22 JimmyZ_ jnthn: could you fork/create linenoise later? :P
12:27 BenGoldberg joined #moarvm
12:29 not_gerd JimmyZ_: you never include readline.h?
12:29 JimmyZ_ not_gerd: not yet, I'm on windows
12:37 jnap joined #moarvm
13:02 benabik joined #moarvm
13:03 not_gerd benabik: ping
13:03 benabik not_gerd: pong
13:03 not_gerd benabik: I might have broken darwin again ;)
13:03 not_gerd could you check if it builds?
13:03 benabik tisk, tisk
13:05 benabik make clean ; and perl Configure.pl ; and make ...  Well, it's compiling things so it's not totally broken.
13:06 not_gerd you see the compiling messages instead of actual commands?
13:07 benabik compiling foo.o...
13:07 benabik linking moarvm
13:07 not_gerd \o/
13:07 not_gerd for bonus points, try `make NOISY=1 tracing`
13:10 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.
13:10 BenGoldberg .tell diakopter nevermind
13:10 yoleaux BenGoldberg: I'll pass your message to diakopter.
13:33 FROGGS joined #moarvm
13:39 colomon_ joined #moarvm
13:49 jnap joined #moarvm
13:50 not_gerd ok, I just hacked together some basic readline detection
13:50 not_gerd note that distributing a binary package linked against readline will make it GPL
13:51 FROGGS linenoise was under the MIT license, right?
13:52 not_gerd FROGGS: BSD
13:52 not_gerd 2-clause
13:52 FROGGS would that be preferable?
13:53 FROGGS did I mention that I hate licensing issues?
14:01 tadzik don't we all
14:02 Ben_Goldberg joined #moarvm
14:07 nwc10 http://www.thrysoee.dk/editline/ is BSD licensed, but it's not at all obvious how widespread it is
14:09 not_gerd nwc10: it's fine as-is (link against readline if available or falls back to linenoise)
14:09 nwc10 cool
14:10 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
14:11 not_gerd Artistic2 licensed code can always be relicensed under the GPL
14:11 not_gerd it's just that linking against readline necessarily does so
14:11 benabik joined #moarvm
14:11 not_gerd (on re-distribution)
14:17 dalek MoarVM/readline: ea7a0ab | (Gerhard R)++ | build/auto.pm:
14:17 dalek MoarVM/readline: Auto-detect readline
14:17 dalek MoarVM/readline: review: https://github.com/MoarVM/MoarVM/commit/ea7a0abe68
14:23 crab2313 joined #moarvm
14:25 dalek Heuristic branch merge: pushed 23 commits to MoarVM/readline by gerdr
14:55 dalek MoarVM/readline: 5862284 | (Gerhard R)++ | / (4 files):
14:55 dalek MoarVM/readline: Wire up MVM_HAS_READLINE and --no-readline
14:55 dalek MoarVM/readline: review: https://github.com/MoarVM/MoarVM/commit/5862284d7c
14:55 JimmyZ_ not_gerd++
15:06 JimmyZ_ not_gerd: Is there a good way to disable compiling linenoise when linked to readline?
15:07 not_gerd JimmyZ_: should already work
15:07 JimmyZ_ oh
15:11 dalek MoarVM/readline: 3d8c656 | (Gerhard R)++ | Configure.pl:
15:11 dalek MoarVM/readline: Clarified implications of not using --no-readline
15:11 dalek MoarVM/readline: review: https://github.com/MoarVM/MoarVM/commit/3d8c656d1f
15:30 dalek MoarVM/readline: c5e1504 | (Gerhard R)++ | build/ (2 files):
15:30 dalek MoarVM/readline: Add /nologo to nmake invocation
15:30 dalek MoarVM/readline: review: https://github.com/MoarVM/MoarVM/commit/c5e1504e38
15:30 dalek MoarVM: 569b23f | (Gerhard R)++ | build/ (2 files):
15:30 dalek MoarVM: Add /nologo to nmake invocation
15:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/569b23fdaa
15:30 JimmyZ_ not_gerd: src/gen/config.h:43:6: error: #error "Failed to detect endianness"
15:30 JimmyZ_ not_gerd: I'm on CentOS
15:30 not_gerd gcc?
15:30 JimmyZ_ gcc version 4.4.7 20120313 (Red Hat 4.4.7-3)
15:31 not_gerd could you gist `gcc -dM -E - </dev/null`
15:33 JimmyZ_ not_gerd: https://gist.github.com/zhuomingliang/6308766
15:33 not_gerd hm...
15:33 not_gerd I don't see any endian-specific macros at all :(
15:34 JimmyZ_ :(
15:37 not_gerd could you do `find /usr/include/ | grep endian` or something equivalent?
15:38 benabik joined #moarvm
15:48 JimmyZ_ /usr/include/linux/byteorder/big_endian.h
15:48 JimmyZ_ /usr/include/linux/byteorder/little_endian.h
15:48 JimmyZ_ /usr/include/bits/endian.h
15:48 JimmyZ_ /usr/include/endian.h
15:48 JimmyZ_ not_gerd: ^^
15:50 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
15:51 JimmyZ_ what?
15:51 JimmyZ_ bad connection
15:51 not_gerd JimmyZ_: you need libreadline-dev (or whatever your package manager calls it)
15:52 JimmyZ_ not_gerd: I'm not asking it
15:52 not_gerd ok
15:52 not_gerd JimmyZ_: could you gist bits/endian.h
15:52 JimmyZ_ I have a bad connection to centos
15:55 JimmyZ_ not_gerd: https://gist.github.com/zhuomingliang/6309101
15:55 not_gerd thanks
15:56 JimmyZ_ not_gerd: it said  x86_64 is little-endian.
15:56 JimmyZ_ not_gerd: and gcc -dM -E - </dev/null has x86_64 define
15:57 not_gerd JimmyZ_: sure, but than we'd have to keep a whitelist
15:57 JimmyZ_ how about? #define __BYTE_ORDER __LITTLE_ENDIAN
15:57 not_gerd can I see endian.h as well ;)
15:58 JimmyZ_ ;)
15:59 JimmyZ_ Good night
15:59 not_gerd o/
16:01 * benabik has i386/endian.h and machine/endian.h
16:03 not_gerd it's a mess
16:04 not_gerd 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:05 not_gerd I wanted to avoid compiling test programs for endian detection because that does not work with cross-compilation
16:30 benabik BYTE_ORDER == LITTLE_ENDIAN
16:33 jnap joined #moarvm
17:08 dalek MoarVM: 7bd2129 | (Gerhard R)++ | / (3 files):
17:08 dalek MoarVM: Take byte order from Perl's %Config.
17:08 dalek MoarVM:
17:08 dalek MoarVM: In case of cross builds, use explicit --big-endian.
17:08 dalek MoarVM:
17:08 dalek MoarVM: Conditional compilation now also consistently checkes for
17:08 dalek MoarVM: definedness of MVM_BIGENDIAN.
17:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7bd2129ad5
17:09 not_gerd benabik: I took inspiration from Parrot and just queried %Config
17:10 not_gerd ~~
17:10 not_gerd left #moarvm
17:24 jnap joined #moarvm
17:36 jnthn arrgh
17:36 jnthn We weren't meant to be making the build system depend on Perl 5 config :/
17:39 TimToady Feel the hatred!  :)
17:39 TimToady so we're going to be linking in a P5, but we can't use P5 to figure out how to do that? :)
17:43 TimToady and cross-compiling would be really easy just by coping a config back from the other machine
17:43 TimToady *copying
17:45 TimToady it just feels to me more like a remnant of parrot's perl antipathy than a reasoned design decision
17:46 TimToady but maybe that's just me :)
17:48 TimToady 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:54 TimToady Config_heavy.pl contains all the info in one package, so a copy of that would probably work for cross-compile purposes
17:56 TimToady though you'd probably want to put stuff into %Cross::Config rather than %Config, so you don't clobber your local configuration
17:57 TimToady well, anyway, maybe I should do something productive...
18:02 nwc10 brew coffee; drink coffee; ? :-)
18:09 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 FROGGS in most cases this CC isnt even the default
18:10 TimToady well, we're probably not compiling a lot of XS modules to produce moarvm...
18:11 TimToady (I hope)
18:11 FROGGS true
18:11 FROGGS *g*
18:12 FROGGS so maybe one an trust P5 about endianess, but definitely about CC
18:12 FROGGS but I think we already have a proper CC detection
18:12 TimToady the nice thing about information is that one can pick and choose what to believe
18:13 TimToady as I recall, p5 can even tell you about mixed-endian architectures
18:13 TimToady byteorder='12345678'
18:14 TimToady some of the DEC machines turned out mixed-endian, iirc
18:15 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
18:15 TimToady jnthn: you've just characterized cross-compilation in general :)
18:16 TimToady it's called that because it makes you cross, or at least cross-eyed
18:22 jnthn diakopter: I backlug the bit I think you meant.
18:23 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.
18:23 jnthn diakopter: Not sure if we have all the pieces in place to do it yet, but it should be possible.
18:24 jnthn diakopter: The stuff that goes on in loading NQPCORE should be comparatively small...
18:26 jnthn If anybody fancies applying some patches, Andy Dougherty has sent some MoarVM patches to perl6-compiler for Solaris building :)
18:27 jnthn If not I'll get to 'em in a bit
18:35 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:36 nwc10 but that part might have been the fallbacks if system routines were missing
18:36 not_gerd joined #moarvm
18:36 not_gerd o/
18:36 benabik joined #moarvm
18:36 not_gerd jnthn: I found querying P5 %Config the least evil way
18:36 not_gerd compiler defines are inconsistent
18:36 not_gerd keeping whitelists is bad
18:36 not_gerd standard header may be endian.h sys/endian.h or sys/param.h
18:37 jnthn not_gerd: I guess those are greater evils...
18:37 jnthn :)
18:37 jnthn Leave it for now. There's almost certainly more worthwhile things to be doing.
18:37 not_gerd the only portable way is building a program that determines endianness at runtime
18:37 not_gerd I try to avoid that as much as possible
18:38 nwc10 yes, totally. Correct triaging (I feel) is "get things building" for now, and clean it up later. (But not *never*)
18:38 nwc10 but I'm likely cranky and biased, and this isn't my lawn.
18:40 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:42 FROGGS I like #ifdefs fwiw
18:49 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?
18:49 yoleaux 13:11Z <BenGoldberg> diakopter: nevermind
18:50 not_gerd diakopter: not really
18:50 not_gerd mixing conventions can get confusing, though
18:50 diakopter not for those of us who don't notice conventions
18:50 not_gerd ;)
18:50 FROGGS hehe
18:50 FROGGS diakopter++
18:51 not_gerd you can get away with quite some sloppyness as an #if will happily accept un defined value
18:51 not_gerd the preprocessor considers those 0
18:51 not_gerd using #ifdef with a value defined to 0, though...
18:52 diakopter I did it with 0/1 because it seemed fastest to implement
18:52 diakopter I was having trouble estimating how long it would take to make it conditionally define using the config.h.in
18:52 FROGGS so we go with #if no matter what?
18:53 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
18:53 diakopter :)
18:53 not_gerd think -DFOO vs -DFOO=1
18:54 dalek MoarVM: 4e0ed79 | (Gerhard R)++ | build/config.h.in:
18:54 dalek MoarVM: Make MVMint8 a signed char - signedness of plain char is implementation-defined
18:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4e0ed79c78
19:03 diakopter not_gerd: should short be signed short?
19:03 diakopter and int.. and longong
19:03 not_gerd diakopter: no
19:04 benabik I think short/int/long are signed by standard, but char is 'whatever'
19:04 diakopter k
19:04 not_gerd for hysterical raisons, that's only true for char
19:05 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
19:06 * diakopter cries at the hundreds of gcc warnings
19:07 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
19:08 not_gerd clang -Weverything -Werror
19:08 not_gerd add stuff like -Wno-padded to remove false positives and keep fixing errors until your code compiles
19:08 FROGGS diakopter: true
19:08 FROGGS clang is really cool for these kind of things
19:09 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
19:10 diakopter need dynamic libraries of every .o/.obj, so we can build a dynamic libmoarvm
19:10 diakopter (and also a static one)
19:11 diakopter need to make a custom .c inference rule (or 5)
19:11 diakopter (I presume)
19:13 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)
19:14 diakopter 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
19:14 diakopter arnsholt: I know how to do it
19:14 diakopter see the dyncall branch Makefile.in
19:14 diakopter er, the Makefile it generates rather
19:14 not_gerd arnsholt: old-style syntax .c.o
19:14 not_gerd works in GNU, BSD and MS
19:14 arnsholt Yeah, it's not hard. But they have bitten me on the ass repeatedly =)
19:15 arnsholt Right, old-style is usually good for portability I guess
19:15 not_gerd conditionals use different syntax, though - !if, .if, ifeq
19:16 not_gerd also, portable special variables are rare
19:16 not_gerd among those are $@ and $* though, which was enough to get the inference rules going
19:17 diakopter not_gerd: do you want to tackle the building of the libraries?
19:18 not_gerd anyone knows which architectures need -fPIC off-hand?
19:19 diakopter all windows I thought
19:19 diakopter not_gerd: I'll take that as a yes... :)
19:21 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 #moarvm
19:27 * diakopter reads http://www.symantec.com/connect/articles/d​ynamic-linking-linux-and-windows-part-one
19:34 diakopter jnthn: I fuzzed a segfault out of moarvm nqp.moarvm :D
19:34 diakopter mwilson@host07:~/src/MoarVM/nqp-cc$ ../moarvm nqp.moarvm -s -- foo.nqp
19:34 diakopter Unknown compilation stage 'classname'
19:34 diakopter frame_name_949Segmentation fault
19:35 diakopter .oO( what do you mean by 'classname'? )
19:36 jnthn Copied from JVM and not needed for MoarVM
19:37 jnthn ...what is -s? :)
19:37 diakopter yeah but what in the world called it
19:37 diakopter just me figuring out that it's ignoring that arg
19:37 diakopter mwilson@host07:~/src/MoarVM/nqp-cc$ ../moarvm nqp.moarvm '' -e '1'
19:37 diakopter Illegal option --.
19:37 diakopter This compiler is based on HLL::Compiler.
19:37 diakopter ...
19:37 diakopter Segmentation fault
19:37 jnthn It means you ade it into compile
19:38 jnthn *made
19:38 jnthn and it's iterating thorugh the compilation stages
19:38 diakopter \o/
19:39 donaldh joined #moarvm
19:39 diakopter mwilson@host07:~/src/MoarVM/nqp-cc$ ../moarvm nqp.moarvm '' -e ''
19:39 diakopter Error encoding UTF-8 string near grapheme position 17 with codepoint 920684456
19:39 diakopter line 1224 in nqp-src/NQPHLL.nqp  (op <unknown>, instr 0<unknown>, frame frame_name_896, compunit ./NQPHLLMoar.moarvm)
19:39 diakopter (*sigh*)
19:40 diakopter position 17 ?!?
19:40 diakopter not_gerd: I think something's still wonky with the clargs stuff
19:40 diakopter ^ should not be happening
19:40 jnthn diakopter: That's happening quite a way in, fwiw.
19:41 jnthn May be clargs related, but maybe not too...
19:41 diakopter oh
19:42 diakopter mwilson@host07:~/src/MoarVM/nqp-cc$ ../moarvm nqp.moarvm 'foo.nqp'
19:42 diakopter Failed to tell position of filehandle: Illegal seek
19:42 diakopter *sigh*
19:43 diakopter masak: when I find brokenness with *every* attempt... what does that say about the fuzziness vs. readiness?
19:45 diakopter (note: I think it's far more likely that it's my code that's causing most of these problems than otherwise)
19:52 TimToady well, it's either somebody's code, or lack thereof...
19:57 jnap joined #moarvm
20:02 masak diakopter: just note it all down, so that it can all be trawled through in due time.
20:02 masak diakopter: journeys consisting of small steps, etc.
20:14 diakopter masak: I think these issues are the pebbles at the top of the dam that are threatening to fall over
20:15 diakopter 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 :)
20:16 masak pebbles, dams. they all need to be packaged and submitted. :)
20:16 jnap joined #moarvm
20:16 jnthn Anyway, this is all at least a bit familiar. At first, it falls in a big heap before really doing anything. :)
20:17 diakopter I'm very sure the string impl are algorithmically sound.. if anything there are tiny errors in implementation
20:17 diakopter the things at the top of ops.c need tackled soon-ish
21:38 not_gerd ~~
21:38 not_gerd left #moarvm
21:59 jnap joined #moarvm
22:04 masak hehe, "need tackled". :)
22:10 diakopter need tackled?
22:11 diakopter [to be]
22:13 yoleaux joined #moarvm
22:14 yoleaux joined #moarvm
22:29 benabik joined #moarvm
22:32 yoleaux joined #moarvm
22:32 yoleaux joined #moarvm
22:40 dalek MoarVM: c512e1b | doughera++ | build/Makefile.in:
22:40 dalek MoarVM: Remove nonportable conditional commands from Makefile.in
22:40 dalek MoarVM:
22:40 dalek MoarVM: Not all makes support conditional IF/ELSE/ENDIF statements.
22:40 dalek MoarVM: Specifically, the /usr/bin/make supplied with Solaris 11 does not.
22:41 dalek joined #moarvm
22:41 jnthn 4 patches from doughera++

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