Parrot 6.9.0 "Rosy-faced Lovebird" | parrot.org/ | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Fridays 13:30 UTC
Set by moderator on 12 November 2014.
00:50 particle joined 05:36 Reini joined 06:59 Reini joined 07:07 Reini1 joined 08:06 Reini1 left 08:10 rurban joined
rurban Froggs: parrot_old only? I'll have to revert the parrot_old rule change then. Did it just for debugging 08:11
09:33 FROGGS joined
FROGGS Reini: yes, seems to be parrot_old only, aye 09:34
Reini: can you fix that quickly? I need to implement openpipe until Thursday 09:35
rurban Ok 10:07
10:14 Reini joined
dalek rrot/smoke-me/o_files-gh1138: aac5ee2 | rurban++ | config/gen/makefiles/root.in:
[build] revert parrot_old linking regression in windows

Fixes GH #1138
Several non-exported symbols appeared when linking the pure O_FILES in parrot_old, and not as library. This exposes typical visibility problems, which should be fixed later. For now just revert to the old library linking and just use O_FILES when needed: i.e. darwin and debugging. See GH #1096		 10:17
rurban1 can you check —gen-parrot=smoke-me/o_files-gh1138 ? 10:21
I have no msvc right now
10:29 travis-ci joined
travis-ci parrot/parrot#1293 (smoke-me/o_files-gh1138 - aac5ee2 : Reini Urban): The build passed. 10:29
Change view : github.com/parrot/parrot/commit/aac5ee26135e
Build details : travis-ci.org/parrot/parrot/builds/41146715
10:29 travis-ci left
dalek rrot: aac5ee2 | rurban++ | config/gen/makefiles/root.in:
[build] revert parrot_old linking regression in windows

Fixes GH #1138
Several non-exported symbols appeared when linking the pure O_FILES in parrot_old, and not as library. This exposes typical visibility problems, which should be fixed later. For now just revert to the old library linking and just use O_FILES when needed: i.e. darwin and debugging. See GH #1096		 10:33
FROGGS will check, gimme a second 10:39
10:43 FROGGS joined
rurban1 now also in master 10:44
10:44 travis-ci joined
travis-ci parrot/parrot#1294 (master - aac5ee2 : Reini Urban): The build has errored. 10:44
Change view : github.com/parrot/parrot/compare/9...c5ee26135e
Build details : travis-ci.org/parrot/parrot/builds/41147254
10:44 travis-ci left
rurban1 should be good 10:44
FROGGS k, will test master instead
rurban1 just travis has some dns hickups to connect to github.com lately 10:45
FROGGS yeah, I've noticed that too on friday 10:46
Creating library src\\vm\\parrot\\pmc\\nqp_group.lib and object src\\vm\\parrot\\pmc\\nqp_group.exp 11:00
nqplexpad.obj : error LNK2001: unresolved external symbol __imp_Parrot_ex_throw_from_c_noargs
src\\vm\\parrot\\pmc\\nqp_group.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\VC\\BIN\\x86_amd64\\link.EXE"' : return code '0x460'
rurban1: one symbol to go :o)
hmmm 11:18
ohh, I probably have to manually delete nqp\\install\\bin\\libparrot.lib 11:24
rurban1: parrot does not seem to overwrite an existing PREFIX\\bin\\libparrot.lib when doing nmake install 11:27
ohh, it does not seem to install it at all... 11:32
and I think I tried to fix that a while ago without luck... the problem is that there are two files called libparrot.lib
one is a static lib (27MB) which goes in PREFIX\\lib, the other one is the import library for the dll 11:33
okay, problem is this: 11:40
C:\\nqp\\parrot\\config\\init\\hints\\mswin32.pm (2 hits)
Line 123: $conf->data->set( inst_libparrot_ldflags => "\\"$bindir\\\\libparrot.lib\\"" );
but that lib file does not get installed
--disable-static is broken too: makefile(1139) : fatal error U1083: target macro 'à(LIBPARROT_STATIC)' expands to nothing 11:58
Stop.
12:41 autark joined 12:42 kid51 joined
FROGGS rurban1: github.com/parrot/parrot/pull/1139 13:36
rurban1: --disable-static also fixes the problem that the import lib does not get installed
IIRC the problem is that both libs have the same name, and there are scripts that use the filename as a key in a hash 13:37
"NQP has been built and installed." - that's parrot HEAD, my PR and a patch to nqp that passes --disable-static along 13:43
rurban1 on windows the importlib should be libparrot.lib and there cannot be a static lib. in cygwin we have .dll.a 14:04
FROGGS rurban: why can't there be a static lib? 14:09
it builds a .dll, and two .libs by default
one libparrot.lib in parrot/ and the other one in parrot/blib/lib/libparrot.lib
rurban1 windows doesn't support really the concept of static libs 14:10
FROGGS the former is the import library, the latter is the static lib
but it gets build
the former is about 389KB the latter 27MB
rurban1 interesting. we should really test parrot with static libs then. I doubt that it will work
FROGGS then --diable-static could be the default on windows perhaps?
rurban1 for single-file application delivery (pbc_to_exe) it is useful 14:11
FROGGS but anyway, I can build parrot + nqp in the combination I said earlier
rurban1 imho yes
I'll check when I got my windows machines back.
FROGGS rurban1: can you take a look at the PR? can't imagine that it can cause trouble 14:12
rurban1 I'm just testing it 14:13
and yes, windows should default to the equivalent of —disable-static 14:14
we have some dll init code which influences how HLL's work 14:15
dynext and dynoplibs do not work with static libs, yet. 14:16
dalek rrot: 66b1f69 | rurban++ | config/gen/makefiles/root.in:
[build] fix building on windows

See github.com/parrot/parrot/pull/1139
FROGGS rurban1: ummm, you applied the patch only partially 14:18
rurban1: the line nmake complains about is left untouched 14:19
rurban1 yes, on purpose 14:20
FROGGS and what exactly is that prupose?
rurban1 ah, you mean $(LIBPARROT_STATIC) is empty on windows?
this should be fixed in the hints file then 14:21
FROGGS it is meant to be empty when I pass --disable-static 14:22
at least that's how I read it 14:23
rurban1 I see, that's bad. It influences the template logic
FROGGS k
rurban1 ok, looks like your patch is better
FROGGS HEAD fails again with: makefile(1139) : fatal error U1083: target macro 'à(LIBPARROT_STATIC)' expands to nothing 14:24
btw, the openpipe port only fails two tests (about opening a pipe to a non existing command) 14:25
would be nice to move all these hacks from nqp.ops upstream at some point 14:26
14:27 travis-ci joined
travis-ci parrot/parrot#1295 (master - 66b1f69 : Reini Urban): The build passed. 14:27
Change view : github.com/parrot/parrot/compare/a...b1f692d0da
Build details : travis-ci.org/parrot/parrot/builds/41157551
14:27 travis-ci left
dalek rrot: 17e3545 | rurban++ | config/ (2 files):
[build] more build fixes on windows

for --disable-static which makes a lot of sense on windows. See also PR #1139		 14:35
rurban1 Thanks for checking this. makes a lot of sense on windows indeed 14:39
so how about openpipe on windows
parrot has Parrot_Run_OS_Command for this
in src/platform/win32/exec.c 14:40
and an _Argv version also
FROGGS I used most of Parrot_io_internal_open_pipe (src/platform/win32/io.c)
Run_Os_Command is not about pipes 14:41
rurban1 right. this is better
FROGGS we've ported Run_Os_Command to nqp.ops last year already IIRC
(because we need to pass the environment to the subprocess too) 14:42
rurban1 Run_Os_Command is just for fast execs. openpipe needs to go via COMSPEC (cmd.exe, oh horror)
FROGGS besides executing the subprocess in a given directory, which is a parameter of the nqp::spawn and nqp::shell op 14:43
rurban1 ah, yes. I remember now. So looks you need nothing more from us then
FROGGS nqp::shell does the too obviously, so the argument quoting stuff is already in place
correct
rurban1 threading is still missing in nqp-p though 14:44
this is where parrot really shines
method calls are still horrible slow
FROGGS though it might be a good idea to move that logic to parrot, so one can pass the env and cwd as optional arguments to open(), shell() and spawn()
rurban1 oh, new args
FROGGS because 80% of the code is identical to nqp.ops (or vice versa) 14:45
rurban1 we need a new API call to accept those 2 args then
where is this in moar?
FROGGS src/io/procops.c
nqp::spawn, nqp::shell and now nqp::openpipe are identical across all three backends, which is nice 14:46
14:47 travis-ci joined
travis-ci parrot/parrot#1296 (master - 17e3545 : Reini Urban): The build passed. 14:47
Change view : github.com/parrot/parrot/compare/6...e3545fcbd4
Build details : travis-ci.org/parrot/parrot/builds/41158704
14:47 travis-ci left
rurban1 this is how it should it be, because we control everything 14:47
there's just one problem with jvm and moar, lstat is missing 14:48
or stat is doing lstat there
FROGGS and that's a problem because... ?
rurban1 it is not POSIX and is worse 14:49
stat follows the link, lstat not
FROGGS it provides what rakudo needs I'd say
rurban1 I made a PR on nqp for this. nqp blamed parrot, but the blame is on jvm and moar 14:50
FROGGS ahh, that TODO comment
rurban1 because sometimes you want to know something on the link also 14:51
FROGGS true... but I think I'd need use cases for Perl 6 to actually think about what we need/want 14:52
rurban1 oh, moar uses uv_spawn. this is easier, yes. 14:53
perl5 is a good example: perldoc -f lstat 14:54
FROGGS we might want to make it optionally to follow links or not... but there is nothing like that specced, so the PR might end up in a discussion about semantics at Perl 6 level
surely, but when you say: "foo".IO.s, do you want the size of the link or the target?
rurban1 when the perl5 standard makes sense, perl6 should not simplify it to a different meaning 14:55
FROGGS Perl 5 has a very different file/path model though
parrot HEAD works btw 14:56
rurban1 thanks
FROGGS ohh, thank you
rurban1 yes the -X file ops should follow links
let's make a parrot feature request to pass cwd and env to openpipe 14:58
FROGGS +1 15:00
rurban1 github.com/parrot/parrot/issues/1140
FROGGS and spawn/shell or whatever it is call in parrot 15:01
rurban1 in parrot is only 'open path, mode' 15:02
but adding a C api with these two added args is easy 15:05
15:37 lauleon joined
Coke f 16:29
ww
FROGGS who wants to write 'f' in another window anyway? :P
17:51 FROGGS_ joined 18:06 Hunger joined 22:47 kid51 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!