00:26 Kaiepi left 00:30 Kaiepi joined, patrickb left 01:44 linkable6 left, sourceable6 left, shareable6 left, evalable6 left, coverable6 left, squashable6 left, committable6 left, releasable6 left, notable6 left, statisfiable6 left, nativecallable6 left, bloatable6 left, unicodable6 left, greppable6 left, quotable6 left, bisectable6 left, tellable6 left, benchable6 left 01:45 unicodable6 joined, evalable6 joined, releasable6 joined, committable6 joined, bloatable6 joined, coverable6 joined 01:46 nativecallable6 joined, squashable6 joined, notable6 joined, linkable6 joined, greppable6 joined, benchable6 joined 01:47 sourceable6 joined, quotable6 joined, statisfiable6 joined, bisectable6 joined, shareable6 joined 01:48 tellable6 joined 04:40 frost-lab joined
Geth nqp: e414b55805 | Coke++ | docs/ops.markdown
Document sqrt
 05:08
05:53 evalable6 left, linkable6 left 05:55 linkable6 joined 05:56 evalable6 joined 06:32 djinni` left 06:43 djinni` joined 06:44 sena_kun joined 08:08 Kaiepi left 09:21 Altai-man joined 09:23 sena_kun left 09:48 gfldex left
Geth Blin/master: 6 commits pushed by (Haytham Elganiny)++, Altai-man++ 10:29
nqp/master: 5 commits pushed by (Elizabeth Mattijsen)++ 10:58
Altai-man Doing a Blin run using Pakku. 11:30
446 out of 1507 modules processed 11:32
⏳ 742 out of 1507 modules processed 11:34
El_Che Pakku is a drop in zef replacement? 11:35
Altai-man I think it is an alternative? Don't think it is "drop-in" as it has different commands. 11:36
Still, I am very curious about where this unbelievable speedup comes from. 11:37
El_Che I mean it works the same way and it uses the same infra
Altai-man Yes.
El_Che like cpan and cpan-minus for Perl
Altai-man ⏳ 928 out of 1507 modules processed
11:46 gfldex joined
Altai-man Executed in 50,56 mins 12:17
interesting 12:18
El_Che compared to? 12:20
Altai-man 122 minutes is my top result with zef. 12:21
The problem is I see a range of warnings. :S
So needs some polishing. I still think it is very promising. 12:22
El_Che it's language use is also kind of geared towards the young :) 12:28
ugexe The speed up, from my understanding, is that it does all the module resolution on the server and/or only uses one source of data (so doesn’t need to make as many version comparisons). This method breaks down when there is any ecosystem (like a dark pan) the remote service doesn’t know of. Ultimate after searching for each batch of dependencies a requery is needed such that the distributions found from 12:36
the previous dependency affect what the next lookup will decide to take (and not considering everything at once)
Which is fine for just getting stuff done, but would soon run into consistency issues in any type of environment/ecosystems it isn’t tied heavily to
El_Che thx for the explanation, ugexe 12:37
ugexe tony-o was investigating how to solve some of these issues remotely while accommodating the points I noted, but it’s a bit harder than just store both ecosystems into one dB and query for everything 12:38
Altai-man ugexe++
ugexe zef is really really fast if all dependencies are pinned fwiw 12:40
El_Che ugexe: that could be a good best practice 12:41
12:43 frost-lab left
Geth nqp: 3484acfc3d | Coke++ | docs/ops.markdown
Document coerce closer to opcodes
 13:16
[Coke] lizmat: ^^ that fixes the coerce opcodes. adding some debug output to the test script so we can report out where it thinks something is documented.
er. where it thinks an opcode is declared. 13:17
ugexe its also got some pretty glaring security issues -- github.com/hythm7/Pakku/blob/302ac...kumod#L139 13:18
[Coke] does NQP support ENV or MAIN?
ugexe i can make a dependency that will run any command i want whenever someone runs that code and parses that distribution
perhaps not, but none-the-less spawning a process to parse a dependency is not an ideal thing to do 13:21
13:22 sena_kun joined 13:24 Altai-man left
ugexe (and by perhaps not i mean im too lazy to figure out if its parsing of names allows things like ; or |) 13:24
[Coke] has a hard time getting a dynamic variable working based off a command line arg in nqp. 14:25
Should I even expect dynamic variables to work? 14:30
nqp: my $*A=True; sub debug($a) { nqp::say($a) if $*A; }; debug('a'); 14:31
camelia Assignment ("=") not supported in NQP, use ":=" instead at line 2, near "True; sub
at gen/moar/stage2/NQPHLL.nqp:1053 (/home/camelia/rakudo-m-inst-2/share/nqp/lib/NQPHLL.moarvm:panic)
from <unknown>:1 (/home/camelia/rakudo-m-inst-2/share/nqp/lib/nqp.m…
[Coke] nqp: my $*A:=True; sub debug($a) { nqp::say($a) if $*A; }; debug('a'); 14:32
camelia ( no output )
[Coke] m: my $*A:=True; sub debug($a) { nqp::say($a) if $*A; }; debug('a'); 14:35
camelia 5===SORRY!5=== Error while compiling <tmp>
Could not find nqp::say, did you forget 'use nqp;' ?
at <tmp>:1
------> 3 $*A:=True; sub debug($a) { nqp::say($a)7⏏5 if $*A; }; debug('a');
[Coke] m: use nqp; my $*A:=True; sub debug($a) { nqp::say($a) if $*A; }; debug('a');
camelia a
[Coke] ponders again turning the nqp opcode doc test into Raku. 14:36
nqp: if True { nqp::say('1') } 14:42
camelia ( no output )
[Coke] ah. there's part of my problem. :P
timotimo yeah, True doesn't exist in nqp, and any identifier that doesn't exist just gives NQPMu 14:49
Geth nqp: 0d40a36df8 | Coke++ | t/docs/opcodes.t
Add debug mode to test

For now, hardcoded and off. Enable to see where opcode definitions are being found to help with diagnostics		 14:57
[Coke] so, the test to check for opcodes finds "if_i" because of this: gist.github.com/coke/f87ab505c6cb8...b5cb6a8990 , but if_i doesn't seem to be an opcode. Anyone have a better idea of how to improve the cheating to ignore non-opcodes? 15:03
I'd rather just ask nqp what its opcodes are, but that doesn't seem possible.
cast a wide net and then try to execute the opcode in a try block?
Add a deny list and throw out "opcodes" like if_i? 15:04
deny list is easiest (I think trying to compile an opcode that doesn't have a handler is not catchable.) 15:06
Geth nqp: 98777d8774 | Coke++ | t/docs/opcodes.t
Provide a mechanism to skip non-opcodes
 15:13
nqp: 6a98c3873b | Coke++ | 2 files
Remove some non ops and their docs
 15:19
[Coke] src/vm/moar/QAST/QASTOperationsMAST.nqp has this line: 15:21
1922: %core_op_generators{'takehandlerresult'}($protected_result);
that's not an opcode. Why is it there?
I don't see takehandlerresult anywhere else in the source in nqp or rakudo 15:22
ah. it is defined in MoarVM - so we have some "opcodes" that are not user-visible? 15:24
(and therefore don't require documentation)
ah. lizmat: the missing nqp opcodes *Are* MoarVM opcodes, but aren't exposed. e.g. MVM_OP_if_i
15:33 Kaiepi joined
Geth nqp: 13f4ea3dca | Coke++ | t/docs/opcodes.t
Skip more unexposed opcodes
 15:47
[Coke] back down to 236 failures, and hopefully all the MoarVM ones left are user-exposed. Please pick one from the list and doc it. :) gist.github.com/coke/f87ab505c6cb8...b5cb6a8990 15:51
16:29 Kaiepi left
nwc10 So... the last sparc64 specific test failure is t/04-nativecall/06-struct.t 16:33
you can't even create a new InlinedArrayInStruct 16:34
I can cut the testcase down to:
class InlinedArrayInStruct is repr('CStruct') { has int32 $.a is rw; HAS int32 @.b[1] is CArray;
}
(thank you so much irssi)
what's the difference between `has` and `HAS`
(the SIGBUS is because the layout we have there has a 32 bit value first, and then it's assuming that it can write a pointer at offset 4, which is a bug) 16:35
but I don't understand the difference between has and HAS
dogbert17 "CStructs and CUnions can be in turn referenced by—or embedded into—a surrounding CStruct and CUnion. To say the former we use has as usual, and to do the latter we use the HAS declarator instead:" 17:15
nwc10: ^^ from the docs 17:16
17:21 Altai-man joined 17:22 Kaiepi joined 17:24 sena_kun left
nwc10 thanks 17:41
Geth nqp: a9e06d020b | (Elizabeth Mattijsen)++ | docs/ops.markdown
Document nqp::box_u
 18:28
nqp: 60954ddb89 | (Elizabeth Mattijsen)++ | docs/ops.markdown
Document nqp::with
Xliff Could someone tell me what I am doing wrong, here? 18:57
repl.it/@Xliff/SadPoliticalForce#main.raku
Oh. Wait...
Geth nqp: e769dee128 | (Elizabeth Mattijsen)++ | docs/ops.markdown
Document nqp:: thread related opcodes
 19:48
nqp: 4e1286f503 | (Elizabeth Mattijsen)++ | docs/ops.markdown
Oops, forgot a ]
 19:49
nqp: 4f3bc08c7d | (Elizabeth Mattijsen)++ | docs/ops.markdown
Forgot some closing backticks
 19:51
nqp: ddaa144b12 | (Elizabeth Mattijsen)++ | docs/ops.markdown
Fix header

I guess vim is not the best editor for this type of markdown :-(		 19:52
20:11 travis-ci joined
travis-ci NQP build passed. Elizabeth Mattijsen 'Fix header 20:11
travis-ci.org/Raku/nqp/builds/738787296 github.com/Raku/nqp/compare/4f3bc0...aa144b124f
20:11 travis-ci left
Geth nqp: 6b5a92ee79 | Coke++ | docs/ops.markdown
move thread docs into thread section
 20:52
nqp: 2f1555401a | Coke++ | docs/ops.markdown
Document some opcodes as restricted to vms
[Coke] lizmat++ # down to 229 opcodes needing docs 20:55
225 21:21
21:22 sena_kun joined 21:24 Altai-man left
Geth nqp: 73eed453cd | (Elizabeth Mattijsen)++ | docs/ops.markdown
More logical order in atpos/bindpos docs
 22:33
22:49 Jolbars joined
Jolbars hello 22:49
22:49 Jolbars left 22:56 sena_kun 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!