00:57 kjs_ joined 02:37 harrow joined 06:49 avuserow joined 08:14 kjs_ joined 08:24 rurban joined 08:28 FROGGS[mobile] joined 10:32 tgt joined 11:23 kjs_ joined
jnthn So what trains are we all on tomorrow? 11:30
uh, ww
lizmat
.oO( full fart! )
 11:34
12:35 zakharyas joined 12:41 FROGGS joined 12:43 camelia joined 13:02 FROGGS[mobile] joined 14:23 zakharyas joined
FROGGS jnthn: +1 to merge github.com/MoarVM/MoarVM/pull/184 after I tested it? 16:28
jnthn I don't like "myeof" :S
FROGGS yeah
jnthn Doesn't whine on my any of the compilers I've used about this... 16:29
FROGGS but I also know that I was unable to use the name eof on QNX either
jnthn Maybe we should underscore it... :)
FROGGS that's what my patch did :o)
gist.github.com/FROGGS/88b75ce683284babe32d 16:30
jnthn OK, and others in the PR I was happy with
timotimo feel free to beat me to fixing the local ref code gen and or tests. will not have access to a pc until late evening
FROGGS jnthn: okay, so I'll cherry pick the other and will underscore eof and tell 16:31
others*
jnthn Thanks; FROGGS++
timotimo: I may get chance, if not today then sometime in the coming days.
FROGGS ohh, I <3 github... 16:34
just append .diff to a commit url and you get what you expect :o) 16:35
16:42 kjs_ joined
dalek arVM: 668a207 | cygx++ | src/platform/win32/mmap.c:
int* and DWORD* are not compatible types
 16:42
arVM: 4baefd6 | cygx++ | src/io/syncpipe.c:
fix bogus pointer casts
arVM: cea53be | cygx++ | src/io/syncfile.c:
avoid name clashes with libc functions
 16:53
FROGGS jnthn: I'll also merge github.com/MoarVM/MoarVM/pull/185/files 16:56
it will be helpful for fakecutables also 16:57
dalek arVM: a624f2a | cygx++ | src/moar. (2 files):
Add helper functions so embedders won't need to poke into MVMInstance
arVM: 1fdea93 | FROGGS++ | src/moar. (2 files):
Merge pull request #185 from cygx/embed

Add helper functions so embedders won't need to poke into MVMInstance
jnthn FROGGS: Yes, my only qualm with that patch is that main.c really shoulda been updated to use those functions too 18:06
FROGGS: So we don't have to maintain the same code in 2 places. 18:07
FROGGS ahh, good point 18:11
I hopefully wont forget to do that
jnthn mebbe I'll do it 18:13
but dinner first :)
18:23 cygx joined
cygx hi 18:24
thank for applying the pr
but by doing so, you broke the code as MinGW also comes with a declaration _CRTIMP int __cdecl _eof(int _FileHandle)
jnthn wtf 18:27
*sigh*
Is it just a warning? 18:29
Or actually an error?
cygx an actual error at the given warning levels (prototypes don't match)
to be fair, in C, names with leading underscores are reserved
jnthn wonders why we don't hit this anywhere else
Yeah, well, I was fine with it as it was. It's a *static*. It's not even getting made visible under the name. 18:30
cygx apparently, the MinGW winapi headers are organized a bit differently than the Microsoft ones
jnthn And, apparently, the POSIX ones too :)
Guess we can go with something like mvm_eof and mvm_tell 18:33
Still irritating to have to rename stuff because of weird header organization and a bogus warning. :/ 18:34
cygx on a related note, both jit and spesh need to be disabled for CORE.setting to compile on MinGW 18:35
with jitting enabled, it dies in stage parse with "Internal error: zeroed target thread ID in work pass" 18:39
jnthn Hm, interesting question then being if that hides the real bug...GC is usually fairly orthogonal 18:44
I think FROGGS mentioned getting that error recently in a different context 18:45
dalek arVM: ce8d59e | jnthn++ | src/io/syncfile.c:
Rename to fix the build on MinGW; cygx++.
 18:46
jnthn Hopefully that helps.
(the build issue)
FROGGS *sigh* # _tell/_eof 18:48
cygx: I've no cygwin atm so I did not check :/
cygx FROGGS: not Cygwin - MinGW (in particular, Strawberry Perl) 18:49
I've been thinking about a combined Strawberry Perl/Rakudo Star distribution 18:50
the name Starberry Perl came to mind ;)
jnthn ooh :) 18:51
(to the idea...the name is...lol :))
I had to read it three times to see it didn't say Strawberry
Would the idea be to include Inline::Perl5 etc, so you can use the two together? 18:52
cygx jnthn: yes, that was the idea
18:53 kjs_ joined
jnthn Sounds great. 18:53
cygx++ 18:54
19:02 vendethiel joined 19:20 zakharyas joined
FROGGS it seems like I can install the blackberry IDE this time... which means that I can try again to compile for QNX 19:24
timotimo whats that?
jnthn The successor to PNX... :P 19:26
FROGGS it's UNIXoid 19:27
timotimo: de.wikipedia.org/wiki/QNX 19:28
timotimo no the IDE
cygx MVM_ext_load() calls MVM_gc_root_add_permanent(), whereas the filenames in loaded_compunits get added in MVM_gc_root_add_instance_roots_to_worklist() 19:32
what's the preferred way to register a hash I want to add to instance with the gc? 19:33
jnthn What's its lifetime?
cygx (said hash containing the names of modules that reside in-memory instead of on-disk)
jnthn: permanent 19:34
jnthn MVM_gc_root_add_permanent is fine if the object should live as long as the instance
(Since there's no way to unregister it)
It's the ended mechanism if you're extending the VM through embedding also 19:35
s/ended/intended/
cygx is working on fakecutables 19:36
jnthn aha :) 19:37
Are you aware of the proof-of-concept work on that at groups.google.com/forum/#!searchin...UT1YL2grIJ ?
19:39 zakharyas joined
cygx jnthn: no, but I basically had it working already 19:40
but the approach I took (preloading the modules) ran into issues because the deserialization frame gets called before any other frame, so I'd have to sneak in some initialization
I decided the more proper approach would be to just register such modules somewhere and make load_bytecode memory-aware 19:41
jnthn Sounds like you're trying to solve a different problem too, which is how to bundle something with its dependencies into a single executable.
cygx yes - just embedding the nqp.moarvm already worked 19:42
jnthn aye
And I think that's as far as the pathces I linked go 19:43
cygx anyway, I think loading modules as requested is the better approach than just loading them in an essentialy arbitrary order beforehand 19:45
jnthn Yes, indeed. More of an in memory file system appraoch I guess 19:47
timotimo i like the sound of that; and having that work for CompUnitRepo, too 19:56
FROGGS timotimo: it is called momentics, which is an eclipse with the qcc (gcc for qnx) compiler and other blackberry specific bits
timotimo ah, i see
20:23 japhb joined
cygx so, I've got a working nqp fakecutable: gist.github.com/cygx/f7eb20d6c73294f72245 20:46
20:55 japhb joined
timotimo cool! :) 21:02
so nothing is stopping you from getting rakudo to work, too? 21:04
cygx timotimo: as far as I know, it should work equally well with rakudo 21:09
timotimo great :) 21:14
timotimo heads off to bed to get rid of the cold or whatever he got
take care! :)
cygx good night and get well 21:16
jnthn timotimo: Get well! o/ 21:23
cygx pushed and example code updated: github.com/MoarVM/MoarVM/compare/m...akecutable gist.github.com/cygx/f7eb20d6c73294f72245 21:40
dalek arVM/spesh-value-prop: aa0cc26 | jnthn++ | src/spesh/graph.c:
Factor dominance info computation out a little.
 22:47
arVM/spesh-value-prop: fac3c22 | jnthn++ | src/spesh/graph. (2 files):
Add a function for re-computing dominance info.
arVM/spesh-value-prop: d5baf85 | jnthn++ | src/spesh/graph. (2 files):
Expose graph.c's unreachable BB elimination.

This is the first step to eliminating the duplication of this logic with a very similar but incomplete version in optimize.c.		 22:54
23:10 Ven joined
dalek arVM/spesh-value-prop: d515ea9 | jnthn++ | src/spesh/graph. (2 files):
Provide a callback on basic block elimination.

This will be used by the optimizer to do any fixup operations needed if we remove a block.		 23:15
arVM/spesh-value-prop: f1b8c16 | jnthn++ | src/spesh/graph.c:
Fix a couple of bugs in basic block elimination.

We accidentally failed to eliminate some blocks we should have in one case, and as efficiently as we could in another.		 23:37
jnthn Bah, I played fast and loose with fixing the succ/pred stuff when implementing inlining. 23:56
What a succer..
eh well, tomorrow...

Powered by Cro and the Raku® Programming Language.

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

Thank you!