MasterDuke why does nqp have dyncall in its 3rdparty directory? i can't find any evidence it's being used 03:41
JimmyZ MasterDuke: was for parrot 04:48
timotimo changing attributes of Attribute from int to int8 can cause segfaults :( 07:06
[TuxCM] This is Rakudo version 2016.11-44-gf928a20 built on MoarVM version 2016.11-20-g0f7277a 07:09
csv-ip5xs 3.198
test 14.249
test-t 6.505
csv-parser 14.560
timotimo it's probably not worth a lot, but it seems quite wasteful to put 5 flags into one 64bit integer each ... 07:11
er, wrong
just four flags
arnsholt MasterDuke: Was used for NativeCall for a long time 08:13
(Well into the Moar days) 08:19
lizmat Files=1154, Tests=53780, 208 wallclock secs (12.77 usr 3.77 sys + 1272.79 cusr 122.29 csys = 1411.62 CPU) 09:31
jnthn If there's a 3rdparty dyncall still in NQP, it can go, I think. 10:39
moritz so what are we using now? 11:08
dyncall in MoarVM?
jnthn Yes 11:12
Which is pulled in as a submodule
Or libffi
As a system package 11:13
MoarVM can be configured with either
MasterDuke without NativeCall support in NQP, what would be the simples/easiest way to get it to write profile data as a sqlite db? 12:02
arnsholt Open a subprocess running the sqlite3 client perhaps? 12:08
dalek p: eca290b | MasterDuke17++ | 3rdparty/dyncall/ (611 files):
Remove dyncall, it's no longer used.

  See some comments here:
  irclog.perlgeek.de/perl6-dev/2016-...i_13621312		 12:09
p: 94cb3dc | jnthn++ | 3rdparty/dyncall/ (611 files):
Merge pull request #321 from MasterDuke17/remove_dyncall

Remove dyncall, it's no longer used.
MasterDuke arnsholt: hmm, that would require the user to have it installed, correct? or bundle it in nqp? 12:11
jnthn lunch & 12:12
arnsholt Yeah, then it'd have to be installed
MasterDuke hmm. i'd prefer a way to create the db even if sqlite3 isn't installed, but maybe requiring the user to have it is good enough 12:16
dalek kudo/nom: 1a6be18 | MasterDuke17++ | tools/build/Makefile-Moar.in:
Rename gen/moar/m-CORE.setting

The 'moar' in the path already differentiates it from the JVM or JS settings, this way the filename will be consistent. Some comments from
  psch here: irclog.perlgeek.de/perl6-dev/2016-...i_13595693		 12:17
kudo/nom: 6e77823 | niner++ | tools/build/Makefile-Moar.in:
Merge pull request #928 from MasterDuke17/rename_m-CORE.setting

Rename gen/moar/m-CORE.setting
arnsholt MasterDuke: Then you'd either have to bundle SQLite with MoarVM and expose it via ops and stuff, or bind the library using NativeCall (which still requires the library to be installed of course) 12:27
The only thing that NQP doesn't have for NativeCall stuff is a user-friendly library though 12:28
All the functionality is exposed through nqp::ops
MasterDuke well, i suspect the subprocess route will be the quickest to implement (for me at least, i don't do much C), think it would be accepted? 12:30
viki For the MAIN enum thing.... I think if we have an EnumStr *just* for sub MAIN and not as a general construct that <...> would also produce EnumStr, then it'd be OK, as the potential to produce an unwanted EnumStr is minimized... 12:35
lizmat sh: gen/moar/m-ModuleLoader.nqp: No such file or directory 12:40
nine MasterDuke: rakudo doesn't build anymore (at least not for me)
MasterDuke lizmat: odd, parsing for me right now 12:42
lizmat hmmm... what creates the gen/ and gen/moar dirs ?
I had nuked my gen dir
it didn't get re-created 12:43
MasterDuke they're in the repo i believe
lizmat aha, ok, my fail :-)
indeed, with .gitignore in them 12:44
sorry for the noise
MasterDuke heh, glad i didn't kill the build for everyone 12:46
hmm, should probably do it for the rest of the files in gen/moar/ also. didn't even think of them, probably because i never opened any 12:47
lizmat MasterDuke: yeah, that would make sense :-) 12:48
nine step by step :) 12:52
MasterDuke does anybody use rakudo_test_run.tar.gz? 13:02
it looks like it was used by make spectest_smolder, but that's commented out
PR for that submitted, now to experiment with profiles and sqlite. just need to remember where in nqp they are created... 14:28
dalek kudo/nom: b63c44c | MasterDuke17++ | tools/build/Makefile- (2 files):
Remove backend specific prefixes

The backend is specified in the path, so it doesn't need to be in the filenames.		 14:31
kudo/nom: 4415ed9 | lizmat++ | tools/build/Makefile- (2 files):
Merge pull request #929 from MasterDuke17/remove_all_backend_specific_prefixes

Remove backend specific prefixes
lizmat MasterDuke++ # getting rid of prefixes 14:38
japhb m: my $fast = Supply.interval(.001).tap: -> $i { say $i; $fast.close if $i > 4; }; sleep 1; my $faster = Supply.interval(.0001).tap: -> $i { say $i; $faster.close if $i > 4; }; sleep 1; # interval supplies < 1 ms can stop progressing ... known? 14:41
camelia rakudo-moar 6e7782: OUTPUTĀ«0ā¤1ā¤2ā¤3ā¤4ā¤5ā¤0ā¤Ā»
jnthn japhb: You're probabl jsut exhausing the thread pool with the sleep clogging things up 14:45
*just 14:46
japhb jnthn: Oh interesting, hadn't thought of that.
jnthn Which in part means "our pool ain't smart enough"
japhb I was about to say, it seems like that oughtn't to cause deadlock. 14:47
jnthn Well, the eventual answer will be `await Promise.in(1)` in place of your sleep
dalek kudo/nom: 1b840f1 | lizmat++ | src/core/ (2 files):
Make native shaped array creation about 1.5x faster
japhb Wait ... I only have two explicit sleep calls there. I thought you were saying that 'interval' was doing a sleep internally, and lots of those were piling up. 14:48
jnthn Hm, maybe I misread it...
timotimo i think you hvae, yeah
jnthn yeah, I did 14:49
fwiw, you've got a race condition
It's likely but not certain $tap will be assigned before the $tap.close call 14:50
japhb jnthn: racing to stop?
jnthn uh, $fast
japhb Oh, I thought that was semantically guaranteed.
OK, good to know!
jnthn No, an assignment is jsut an assignment 14:51
lizmat jnthn: so how *could* you be sure you can close on $fast ?
jnthn You can't. 14:52
lizmat hmmm....
jnthn I'd write it as: supply { whenever Supply.interval(.001) -> $i { say $i; done if $i > 4 } }
It's rather smelly for a supply to turn itself off from the outside. :P
lizmat ok, that's what I meant :-)
japhb OK, that's really useful info. 14:53
jnthn As for the original question though
Yes, something looks wrong there.
m: react { whenever Supply.interval(.001) { .say; done if $_ == 5 } } 14:54
camelia rakudo-moar 1b840f: OUTPUTĀ«0ā¤1ā¤2ā¤3ā¤4ā¤5ā¤Ā»
jnthn m: react { whenever Supply.interval(.0001) { .say; done if $_ == 5 } }
camelia rakudo-moar 1b840f: OUTPUTĀ«(timeout)0ā¤Ā»
jnthn Yup, that's decidedly wrong.
Sorry, I read the sleep as being inside of the tap callback the first time 14:55
japhb np
jnthn Please RT it; I'll take a look when I get chance
japhb Will do
lizmat m: react { whenever Supply.interval(.0001) { done if $_ == 5 } } 14:57
camelia rakudo-moar 1b840f: OUTPUTĀ«(timeout)Ā» 14:58
lizmat ok, my idea was that the .say caused so much delay that too many jobs got added before $_==5
but I guess the condition check in itself is enough already 14:59
jnthn Yeah, I struggle to guess this one. 15:00
japhb bug report sent 15:01
jnthn Thanks
MasterDuke is the profiler output schema documented anywhere? 15:17
timotimo the json stuff? not reall
MasterDuke well, i don't think i care about the schema of the *json* per se, but the underlying data 15:19
to create a sql schema
jnthn MasterDuke: The C data structures would give you a good hint but...it's recursive data, so "enjoy" :) 15:20
MasterDuke jnthn: "thanks" :) 15:21
before i go too far down this path, do people think this would be useful? to have a sqlite output option for profiling? 15:28
timotimo it would probably make the qt profiler easier to extend with the functionality the html profiler already has 15:29
also, it could finally cope with files bigger than the arbitrary limit qt or json-qt or whatever imposes upon us 15:30
MasterDuke yeah, that's what i'm thinking. just want to make sure i'm not the only person who sees a need/use 15:31
timotimo somehow, some files that contribute to the core setting make vim's syntax highlighter go supercritical 15:32
MasterDuke yeah, that's one of the reasons i don't like opening the core setting if i don't have to (partly inspired the line directive support i added) 15:54
any idea for a short script to profile that would trigger all the different kinds of info collected? to force OSR, full GC runs, etc 15:55
timotimo oh, oof 15:58
parse json with json_fast ;)
FROGGS o/ 16:00
dalek rakudo/nom: 61a18c0 | (Zoffix Znet)++ | src/core/Iterable.pm: 18:48
rakudo/nom: Fix Iterator.flat occasionally skipping inner iterables
rakudo/nom:
rakudo/nom: Fixes RT#130160: #rt.perl.org/Ticket/Display.html?id=130160
rakudo/nom: lucasb++ for golfing the bug.
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130160
dalek rakudo/nom:
rakudo/nom: The issue observed in the ticket occurs when a combination of .pull-one
rakudo/nom: and .push-all method is called on the iterator of the Seq's returned by
rakudo/nom: .flat(). Current implementation of .push-all on that iterator does not
rakudo/nom: anticipate that we *already* may be inside a nested iterable, so when
rakudo/nom: .pull-one stops instead a nested iterable, the .push-all call will
rakudo/nom: continue with whatever is *after* that iterable.
rakudo/nom:
viki Fix by deleting the push-all implementation and using the default one
provided by Iterator. I've done rough performance check by running
this a few times: `for ^1000 { ^10_000 .flat.eager }; say now - INIT now;`
and the results point to a the new way being 1.0000019387x faster, so
there's no apparent performance loss.
github.com/rakudo/rakudo/commit/61...1fe4e2cb5e
dalek ast: 10f3943 | (Zoffix Znet)++ | S02-types/list.t:
Test .flat() does not skip inner iterables

RT#130160: #rt.perl.org/Ticket/Display.html?id=130160		 18:56
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130160
viki ".pull-one stops instead a nested iterable" s/instead/inside/; # ... I should really start proofreading these things /o\ 19:23
lizmat viki++ # fixing and proofreading in the future :-) 19:30
dalek kudo/nom: b6de5e8 | lizmat++ | / (2 files):
Make native 1dimmed init and copying much faster

  - provide separate .STORE candidates for native 1dimmed
  - initialization from an iterator: at least 11x faster
  - copying from one array to another: at least 25x faster		 19:45
kudo/nom: 172898e | lizmat++ | / (2 files):
Make using native 2dimmed arrays faster

  - AT-POS 4x faster
  - ASSIGN-POS 4x faster
  - EXISTS-POS 2.5x faster		 20:34
kudo/nom: 64343d7 | lizmat++ | / (2 files):
Make using native 3dimmed arrays faster

  - AT-POS 4x faster
  - ASSIGN-POS 4x faster
  - EXISTS-POS 2.5x faster		 21:49
lizmat good night, #perl6-dev! 21:52
timotimo gnite lizmat! 21:57
dalek ast: d09072c | usev6++ | S (3 files):
Fudge some newly added tests for JVM
 22:23
kudo/Routine_consolidate_flag_fields: dd0ae9b | timotimo++ | src/ (4 files):
store rw and yada flags in single attribute in Routine

unfortunately there's a bug here that causes "Stub code executed" while compiling the core setting, so something's getting mixed signals here.		 22:56

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!