00:29 colomon joined 00:34 woolfy joined, woolfy left 02:08 btyler joined 06:17 lizmat joined 06:43 woolfy joined 07:01 zakharyas joined 07:05 woosley joined 07:22 woolfy left 07:23 brrt joined 07:31 brrt left 09:03 lue joined 09:34 donaldh joined 09:39 brrt joined 09:52 FROGGS joined 10:19 brrt joined 10:25 donaldh joined 12:04 colomon joined 12:10 FROGGS joined
sergot_ I have a question. 12:12
I'm working on Bug #121273 12:13
synopsebot Link: rt.perl.org/rt3//Public/Bug/Displa...?id=121273
sergot_ I'm at point, where nqp::mul_n returns wrong value (it's 3.40282366920938e+2), when the value of GET_REG(cur_op, 0).n64 contains (after multiplication) good value (it's 340282366920938029056.000000). 12:17
in OP(mul_n):
340282366920938029056.000000 == 3.402824e+20 (using %e) 12:20
Do you know maybe where can I look for a bug now? 12:21
the OP(mul_n) is defined like this: GET_REG(cur_op, 0).n64 = GET_REG(cur_op, 2).n64 * GET_REG(cur_op, 4).n64; 12:22
any ideas? :) 12:25
12:34 harrow joined
FROGGS sergot_: I'd think that the code that does the scientific notation is off 12:37
sergot_ What do you mean? 13:06
FROGGS: :)
FROGGS something converts it to a string to be printed with '...e+2...' 13:07
and that might be faulty when the numeric value stays intact
sergot_ Do you know maybe where should I look for it? 13:08
FROGGS I'd guess that nqp::sprintf is involved
but I'm not sure
sergot_ ok, I'll try 13:09
13:10 colomon joined 13:37 btyler joined 14:04 john3213 joined 14:09 john3213 left
sergot_ FROGGS++, thank you! 15:00
FROGGS sergot_: did you run the nqp-m tests and the rakudo spectests for moarvm? 15:02
I think we should do that to make sure nothing breaks 15:03
and I also guess we can unfudge tests
sergot_ I ran nqp-m tests, I should do the same with spectests - give me a sec. 15:08
We can unfudge them after merging my pull request I think. 15:22
FROGGS sure
I just want to know what we can unfudge and that nothing breaks 15:23
15:26 lizmat joined 15:39 woolfy joined 15:42 camelia joined 15:45 camelia joined 15:52 raiph joined 16:35 woolfy left 16:52 FROGGS joined
FROGGS sergot_: the spedctests are fine? 17:13
sergot_ FROGGS: yes, they are 18:02
FROGGS awesome :o) 18:03
dalek arVM: 651bf11 | sergot++ | src/core/coerce.c:
Bug #121273 fixed - losing a 0 from end of exponent

it was removing zeros from the end of a num. FROGGS++
synopsebot Link: rt.perl.org/rt3//Public/Bug/Displa...?id=121273
dalek arVM: d84b1dd | sergot++ | src/core/coerce.c:
NewLine removed
arVM: 3818135 | (Tobias Leich)++ | src/core/coerce.c:
Merge pull request #99 from sergot/master

Bug #121273 fixed - losing a 0 from end of exponent
synopsebot Link: rt.perl.org/rt3//Public/Bug/Displa...?id=121273
sergot_ You can check too :) 18:04
\o/ yay
FROGGS also please respond to that RT ticket 18:05
sergot_ Ok :)
FROGGS: that's weitd, I can't do that: oi57.tinypic.com/33p360j.jpg 18:09
the same with "Comment" 18:10
FROGGS works for me...
are you signed in?
sergot_ If I am, it always redirects me to rt.perl.org/SelfService/ - I cannot even open this bug. 18:12
FROGGS weird 18:13
sergot_ If I use "Goto Ticket..." it shows: No permission to display that ticket
FROGGS rt.perl.org/Ticket/Display.html?id=121273
sergot_ The same, no permission
18:14 btyler joined
FROGGS I closed that ticket 18:41
sergot++
nwc10 MVMint64 is_not_scientific = !strstr(buf, "e"); 18:43
wouldn't that be more efficient as !strchr(buf, 'e'); ?
(not tested)
FROGGS I dunno 18:44
same goes for the check of the dot I guess
18:47 brrt joined
brrt \o #moarvm 18:48
FROGGS hi brrt 18:50
[Coke] sergot_: what is your login id on rt? 18:51
(it'll show in the "logged in as..."
FROGGS: get him the public link. 18:52
brrt today is start-of-coding, isn't it? :-)
tadzik I think so :)
brrt then i should've gotten to work 18:59
jnthn, timotimo, you here? 19:03
sergot_ [Coke]: [email@hidden.address] 19:04
brrt: yes. that's right
brrt :-) i'm as excited as i'm tired
[Coke] sergot_: ok, you're not listed as a perl 6 bugadmin. 19:06
... and now you are. 19:07
sergot_ \o/ [Coke]++ thanks
It works :)
[Coke] non bugadmins must use the "public" urls. 19:09
so urls shared by us here probably won't work.
19:51 lizmat joined, cognominal joined 19:52 dalek joined 19:56 Util joined
timotimo brrt: i'm here 20:14
brrt hi :-)
briefly, i'm wondering where to begin 20:15
oh, i've put myself up for 'research weeks' 20:16
but i've already done some of that
hmm
the first 1,5 month is just spesh, it seems
timotimo are scientific number renderings proper now? 20:17
brrt i have no idea, i haven't looked at that
i'd just like to start at something :-) 20:27
lizmat brrt: there are a number of segfaults in the rakudo spectest 20:29
brrt fair enough
lizmat that go away if MVM_SPESH_DISABLE=1 is specified
brrt hmm
ok
i'll take a look
(somewhere later today)
lizmat the faiing tests are: t/spec/S05-transliteration/with-closure 20:30
t/spec/S05-transliteration/trans.t
nwc10 t/spec/S05-transliteration/with-closure.rakudo.moar t/spec/S05-transliteration/trans.rakudo.moar t/spec/integration/advent2009-day09.t t/spec/integration/real-strings.t
lizmat nwc10++
jnthn evening, #moarvm 20:49
FROGGS hi jnthn
jnthn Did we bump MOAR_REVISION enough so anybody building with that sees the segvs?
FROGGS we are at HEAD right now 20:50
jnthn Anyway, I can look at them tomorrow. I saw the conf has tables and white power strips to plug into. :)
FROGGS tables++ :o)
jnthn Saw the backtrace somebody posted. I suspect it'll be something silly in the end... 20:52
brrt hi jnthn :-) 20:53
haven't seen the backtrace
jnthn paste.scsys.co.uk/377252 20:54
Anyway, if anybody else wants to look at it, feel free... 20:56
brrt hmm 20:57
seems to be happening during spesh, no?
jnthn right 20:59
lizmat nwc10: were you contacted about using hardware for testing? 21:02
21:06 colomon joined 21:21 donaldh joined
dalek arVM: 845bb6f | (Tobias Leich)++ | src/6model/reprs/P6opaque.c:
don't try to get slot of an NULL attribute name
 21:22
21:24 vendethiel joined
FROGGS jnthn: I dunno if that is correct or not, but it helps right now at least 21:24
spesh_attr_name returns NULL in one case, so I think it is not too bad what I did 21:25
jnthn FROGGS: uh, no, I thought name was checked in all the branches 21:27
If not it was just a fail
FROGGS ohh lol, now I see that the other branches do what I did *g* 21:28
hehe
looks like There Is Only One Way To Do It :o)
Stage parse : 46.257 21:29
still 26.2s to go :P
damn, I love that
:o)
jnthn On my box it's already at around 35s :) 21:35
FROGGS yeah, your box + MSVC is a nice combination 21:37
ahh, and I always build with --debug=3 21:38
jnthn Have you tried building with CGOTO?
FROGGS no
jnthn Worth a try. If it helps (especially in combination with optimization flags) we may want to make it the default
FROGGS ahh, will try now
btw, spectests are clean (except S17 and a test that lizmat++ touched in the last hour) 21:39
lizmat which one?
FROGGS <FROGGS> t/spec/S02-types/deprecations.rakudo.moar ..................... Dubious, test returned 1 (wstat 256, 0x100)
<FROGGS> Failed 6/39 subtests
lizmat hmmmm 21:40
willl look in a mo 21:41
FROGGS -O2 with CGOTO and without -g feels very fast at least 21:42
Stage parse : 41.706 21:44
nice -----------^
brrt is going to sleep :-) FROGGS++ for fixing 21:45
although i wonder why name was null
FROGGS dunno, but the function returns NULL in on case so... we better check anyway
gnight brrt :o)
21:47 brrt left
jnthn NULL is used to indicate "we don't know the attribute name at compile time" 21:48
21:52 tadzik joined 22:04 cognominal joined
timotimo how does i builds with cgoto? 22:06
jnthn make CGOTO=1 maybe 22:09
see Makefile
22:41 woolfy joined 23:28 woolfy left

Powered by Cro and the Raku® Programming Language.

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

Thank you!