»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, niecza:, std:, or /msg p6eval perl6: ... | irclog: irc.perl6.org/ | UTF-8 is our friend! Set by sorear on 4 February 2011. |
|||
masak | 'night, #perl6 | 00:02 | |
FROGGS | gnight all | 00:03 | |
not_gerd | night | 00:05 | |
00:05
not_gerd left
|
|||
uvtc | ☾ | 00:05 | |
00:09
wk_ left
00:15
uvtc left
|
|||
[Coke] | is rakudo using any of the runtime modules provided by parrot? | 00:15 | |
00:31
thou joined
00:38
lue joined
|
|||
dalek | kudo-js: 96b8ae7 | (Paweł Murias)++ | src/QAST/Compiler/JavaScript.nqp: mangle the new identifier |
00:45 | |
rl6-most-wanted: ee48cf8 | (Geoffrey Broadwell)++ | most-wanted/ (2 files): Start filling out most-wanted files based on Perl 6 Ecosystem Most Wanted Modules list |
00:49 | ||
00:52
PacoAir joined
01:26
PacoAir left
|
|||
dalek | kudo-js: b3325bc | (Paweł Murias)++ | run (2 files): Pass qast_stat.t. |
01:27 | |
01:29
PacoAir joined
|
|||
dalek | ast: 3972c4d | (Solomon Foster)++ | S02-types/set.t: Some basic tests for .set method. |
01:37 | |
ecza: 81d9dca | (Solomon Foster)++ | lib/CORE.setting: Add Hash.set and Hash.bag. |
01:38 | ||
01:38
jeffreykegler joined
|
|||
TimToady | Yes, set should not flatten in list context, even though hash does | 01:45 | |
otherwise it's nearly impossible to make a set of sets | |||
colomon | rn: say 42.set | 01:51 | |
p6eval | rakudo a3869a, niecza v24-21-g4c8f264: OUTPUT«set(42)» | ||
dalek | ecs: 13a275e | larry++ | S32-setting-library/Containers.pod: sets and bags don't flatten in list context |
||
TimToady | rn: say <a b c>.set | ||
p6eval | rakudo a3869a, niecza v24-21-g4c8f264: OUTPUT«set(a, b, c)» | ||
colomon | ?" | ||
sorry, was sorting socks on my keyboard. | 01:52 | ||
TimToady | that's a new one | ||
colomon hopes set(a, b, c) was the answer TimToady hoped to get. | |||
TimToady | yes | ||
colomon | \o/ | ||
TimToady | rn: (1,2,3).set | ||
p6eval | rakudo a3869a, niecza v24-21-g4c8f264: ( no output ) | ||
TimToady | rn: say (1,2,3).set | 01:53 | |
p6eval | rakudo a3869a, niecza v24-21-g4c8f264: OUTPUT«set(1, 2, 3)» | ||
colomon | I haven't added it to the spec yet, but I added it to both rakudo and niecza and roast. :) | ||
TimToady | \o/ | ||
thanks | |||
colomon | I'd written a piece of code that looked like (set @hashes).map(*.Str).sort.join(",") || "<none>"; and it just seemed really stupid that I couldn't say @hashes.set.map(*.Str).sort.join(",") || "<none>"; And I remembered thinking that for something before, too. | 01:54 | |
TimToady | rn: say (1,2,3).Set | 01:57 | |
p6eval | niecza v24-21-g4c8f264: OUTPUT«Unhandled exception: Unable to resolve method Set in type Parcel at /tmp/9cIkREXo2w line 1 (mainline @ 3)  at /home/p6eval/niecza/lib/CORE.setting line 4230 (ANON @ 3)  at /home/p6eval/niecza/lib/CORE.setting line 4231 (module-CORE @ 580)  at /home… | ||
..rakudo a3869a: OUTPUT«No such method 'Set' for invocant of type 'Parcel' in block at /tmp/ryQh_CEK28:1» | |||
TimToady | me wonders if it should be capitalized | 01:58 | |
especially since there's another meaning to the word "set" | |||
benabik | +1 | ||
One of these things are not like the others: *.Int, *.Str, *.set | 01:59 | ||
TimToady | well, there's .list | ||
benabik | Does it return a List? | ||
TimToady | though taking the .set method will discourage people from writing getters/setters :) | 02:00 | |
pmurias | TimToady: so what's the decision on Array.delete only exposing it on implementations which use sparse array internaly doesn't seem to portable | ||
s/Array.delete/Array.delete? | 02:01 | ||
TimToady | the semantics should stay the same regardless of how it's implemented underneath | ||
if an implementation can't support NULL poking, then it should probably support it via a real sparse array instead | 02:02 | ||
otoh an argument could be made that this may negatively affect performance on non-sparse arrays | |||
02:04
jeffreykegler left
|
|||
diakopter | what's a heuristic one could use to detect when to switch to a sparse backing array | 02:05 | |
TimToady | well, the first delete is a big clue :) | 02:06 | |
diakopter | ok, sounds good to me | ||
benabik | @a[$x] = $y, when $x >> +@a | ||
TimToady | but merely tracking how much wasted space there is would be a kloo | 02:07 | |
benabik | (Well, when $x >> @a.allocated_size) | ||
02:09
FROGGS_ joined
|
|||
pmurias | TimToady: on the other hand we could have a sparse array which just avoids storing Mu, and exposes a regular interface | 02:10 | |
02:10
FROGGS left
|
|||
TimToady | we could, but non-sparse arrays would tend to go all n-log-n-y on access | 02:12 | |
they might do that anyway if you're using a lockless structure, but it's really a choice of the implementor | 02:13 | ||
we just need to make sure the API is consistent, and hopefully provides sufficient info to optimize where that's important | 02:14 | ||
these are the sorts of implementation decisions that we should try to keep from leaking into our abstractions | |||
pmurias | TimToady: n-log-n-y? | 02:15 | |
benabik | Non-sparse arrays go n-log-n on access? Shouldn't non-sparse element access be O(1)? | ||
diakopter | benabik: (that's what I would imagine) | 02:16 | |
(based on my naive first guess at imagined implementation) | |||
TimToady | yes, they *should* be O(1), that's my point :) | ||
but merely swapping in a sparse implementation might not do that | |||
I mean instead of having a flat implementation | 02:17 | ||
I was talking about an implementation that always uses a tree for arrays, which would be suboptimalish in that way | |||
P5 has done very well with a bias towards flat arrays, and emulating a bit of sparseness by null poking | 02:18 | ||
diakopter | null poking? | 02:19 | |
TimToady | what P5 does on delete from array | ||
and exists just says whether there's a pointer at that index | |||
arrays and hashes are conceptually different, but in practice they mush into each other a bit, depending on the underlying container's semantics | 02:21 | ||
however, in P6, it's an absolute that .[] is always 0 based, and we use .{} aliasing (according to S09) if we want negative indices | 02:22 | ||
02:26
PacoAir left
02:42
alec__ left
|
|||
timotimo | i think tomorrow i shall play around with zmq :) | 02:43 | |
see if i can get a simple connection working with ipython | |||
did not notice anything missing so far | |||
what are the deciding factors for what gets put into rakudo star? | 02:44 | ||
02:59
pmurias left
|
|||
benabik | Actually, ideally a sparse array is no worse than log n on access. (Not that it really matters, just occurred to me.) | 03:04 | |
timotimo | right, because that would be a tree, right? | 03:07 | |
03:13
alec__ joined
03:22
stevan__ joined
03:25
stevan_ left,
stevan_ joined
03:28
stevan__ left
03:30
Chillance left
|
|||
dalek | ecza: 0520c7c | (Solomon Foster)++ | lib/CORE.setting: Add another to-set multi to resolve conflict. |
03:55 | |
04:01
swarley| left
|
|||
dalek | ast: 38dd58f | (Solomon Foster)++ | S02-types/bag.t: Some tests for .bag. |
04:01 | |
04:17
happydude joined
04:46
flussence left
04:57
preflex left
04:58
preflex joined
05:22
xinming left
05:33
xinming joined
05:36
daniel-s joined
05:52
happydude left
06:03
preflex left
06:05
preflex joined
|
|||
dalek | ecs: 3b88fdf | larry++ | S02-bits.pod: autopriming doesn't look inside metaops |
06:58 | |
07:07
GlitchMr left
07:11
GlitchMr joined
07:14
quester joined
07:22
ggoebel_ left
07:23
proller joined
08:07
pupoque joined
08:30
bluescreen100 joined
08:33
bluescreen10 left
08:34
domidumont joined
08:40
jaldhar left
08:48
thou left
08:51
domidumont left
08:52
domidumont joined
09:15
erkan joined
09:19
immortal joined
09:20
erkan left
09:24
shevy joined,
shevy left
|
|||
moritz | jnthn: rakudo/nom segfaults while compiling BOOTSTRAP | 09:26 | |
(on 64bit) | |||
09:29
quester left
09:33
immortal left,
erkan joined,
wk_ joined
09:35
FROGGS_ is now known as FROGGS
|
|||
FROGGS | "morning" | 09:35 | |
09:36
rindolf joined
|
|||
FROGGS | moritz: I get a $past that has $past.isa(QAST::Op) && $past.op eq 'callmethod' && $past.name eq 'list', then I could wrap it in an QAST::Op that calls map, right? | 09:37 | |
09:44
stevan_ left,
kaare_ joined
09:45
Psyche^ joined
09:48
Patterner left,
Psyche^ is now known as Patterner
|
|||
moritz | FROGGS: you could, yes | 09:53 | |
FROGGS | k, thanks | 09:55 | |
09:59
wk_ left,
snearch joined,
snearch left
|
|||
nwc10 | is Array.at_pos() part of the spec, or an implementation detail? | 10:31 | |
sorear | I think it's intended to be spec once there's consensus it's solid | 10:32 | |
nwc10 | OK. It accepts negative indices. [] doesn't | 10:33 | |
sorear | ISTR jnthn talking about at_pos as being the preferred point for module authors to hook into indexing | ||
arnsholt | Yep. There're some complicated bits like slicing that [] implements in terms of at_pos, so that other people don't have to | 10:34 | |
nwc10 | next stupid question - is there a way to monkey-patch methods into Array, so that I can test them without recompiling the setting? | 10:38 | |
arnsholt | I think the usual way is to subclass it and test your implementation that way, before moving it into the setting | 10:39 | |
moritz | nwc10: sure, you can write use MONKEY_TYPING; augment class Array { your methods here } | ||
nwc10: and then run your tests with it from the same file | 10:40 | ||
nwc10 | thanks | ||
moritz | that's how I developed many built-ins that ended up in the setting | ||
nwc10 | works on my machine | ||
moritz | you just can't replace existing methods that way | ||
(if the method isn't used for bootstrappy purposes, you can delete it once from the setting, recompile and them monkey-patch it in again) | 10:41 | ||
nwc10 | r: my @a = "Q"; my $b := @a.at_pos(-1); say @a; $b = "Pi"; say @a | 10:47 | |
p6eval | rakudo a3869a: OUTPUT«QPi» | ||
nwc10 | so, binding to -1 works, and can be assigned to. But direct assignement: | 10:48 | |
r: my @a = "Q"; @a.at_pos(-1) = "Pi"; say @a; | |||
p6eval | rakudo a3869a: OUTPUT«ResizablePMCArray: index out of bounds! in block at src/gen/CORE.setting:6312 in block at /tmp/pVWoo4iDNp:1» | ||
moritz | I think at_pos supporting negative arguments is a misfeature | 10:49 | |
nwc10 | it's easier to reimplement if it doesn't | ||
and I'm out of my depth to explain why I can bind then assign, but can't assign directly | 10:50 | ||
moritz | IMHO it's the job of postcircumfix:<[ ]> to make sure that sane arguments are passed to at_pos | ||
nwc10 | that, I think, already throws an exception for negative arguments | ||
jnthn | morning o/ | 11:06 | |
Well, not quite, but... | 11:07 | ||
moritz: Odd about the SEGV...did you (or could you try) make realclean in NQP and Rakudo just in case? | |||
moritz: I note that p6eval seems to have managed to build it... | |||
11:13
geekosaur left
11:15
geekosaur joined
|
|||
masak | afty, #perl6 | 11:18 | |
sorear | o/ masak | 11:20 | |
11:26
wk_ joined
11:31
not_gerd joined
|
|||
not_gerd | o/ | 11:31 | |
11:32
pupoque left
|
|||
masak | \o | 11:32 | |
11:32
wk_ left
|
|||
not_gerd | Is this correct: Rakudo depends on PCT via PAST/POST, but not on PGE and TGE | 11:33 | |
masak | Rakudo used to depend on PCT via PAST/POST. | ||
jnthn | Not, it doesn't use PAST or POST any more. | ||
masak | now nqp handles those bits, using QAST. | ||
not_gerd | good | ||
jnthn | Right, and POST was replaced with PIRT | 11:34 | |
Which saved a good bit of memory :) | |||
masak | it's correct that Rakudo doesn't use PGE anymore. nqp handles that, too. | ||
I'm not aware that Rakudo ever used TGE. | |||
jnthn | Maybe it did before it was Rakudo. | ||
:) | |||
masak | maybe. | ||
I've never seen TGE being used anywhere. my impression is that it was something XSLT-like. but I may be wildly wrong about that. | 11:35 | ||
jnthn | Attribute grammar based, iirc | ||
not_gerd is trying to rip out stuff from parrot | 11:36 | ||
jnthn | moritz: Just done a fresh build of everything here and it worked. If it is still segfaulting for you, a bt would help. | ||
nwc10 | oh yes, worked on a complete clean fresh build for me on x86_64 Linux | 11:38 | |
forgot to say | |||
masak | jnthn: oh, right. attribute grammar rings a bell. | 11:40 | |
which means, again IIUC, that values are calculated based on fairly fluid dependency relations up and down the tree. | |||
nwc10 | jnthn: if at_pos didn't accept negative indices, life would be easier | 11:52 | |
dalek | p: 6b358a3 | jnthn++ | src/core/NQPRoutine.pm: Toss now-unrequired clone callback legacy code. |
||
p: f92cd68 | jnthn++ | src/QAST/Operations.nqp: Add an nqp::escape that maps to pir::escape. |
|||
p: 3f27005 | jnthn++ | src/stage0/ (9 files): Update bootstrap. |
|||
p: 26d0d0f | jnthn++ | src/QAST/ (2 files): Get QASTNodes free of pir::. |
|||
jnthn | nwc10: I...wasn't terribly aware it did | 11:53 | |
nwc10 | well, it passes them all through unchecked to Parrot | ||
jnthn | nwc10: Oh, does it work because the underlying nqp::atpos call it makes will make it work? | ||
nwc10 | which does the Perl 5 thing | ||
jnthn | Yeah | ||
nwc10 | there is no spec for at_pos, is there? | ||
jnthn | r: my @a; @a[-1] = 42 | ||
p6eval | rakudo a3869a: OUTPUT«Cannot use negative index -1 on Array in method <anon> at src/gen/CORE.setting:10518 in at src/gen/Metamodel.pm:2488 in any find_method_fallback at src/gen/Metamodel.pm:2476 in any find_method at src/gen/Metamodel.pm:925 in block at /tmp/WQ5CfdWT6J:1»… | ||
nwc10 | jnthn: this one seems a bit special: | 11:54 | |
rn: my @a = "Q"; my $b := @a.at_pos(-1); say @a; $b = "Pi"; say @a | |||
p6eval | niecza v24-23-g0520c7c: OUTPUT«QUnhandled exception: Writing to readonly scalar at /tmp/5VIpPlG9bW line 1 (mainline @ 7)  at /home/p6eval/niecza/lib/CORE.setting line 4233 (ANON @ 3)  at /home/p6eval/niecza/lib/CORE.setting line 4234 (module-CORE @ 580)  at /home/p6eval/niecza/… | ||
..rakudo a3869a: OUTPUT«QPi» | |||
nwc10 | but if I assign directly: | ||
11:54
not_gerd left
|
|||
nwc10 | rn: my @a = "Q"; my $b := @a.at_pos(-2); say @a; $b = "Pi"; say @a | 11:54 | |
p6eval | niecza v24-23-g0520c7c: OUTPUT«QUnhandled exception: Writing to readonly scalar at /tmp/R97BJDqmX7 line 1 (mainline @ 7)  at /home/p6eval/niecza/lib/CORE.setting line 4233 (ANON @ 3)  at /home/p6eval/niecza/lib/CORE.setting line 4234 (module-CORE @ 580)  at /home/p6eval/niecza/… | ||
..rakudo a3869a: OUTPUT«QResizablePMCArray: index out of bounds! in block at src/gen/CORE.setting:6312 in block at /tmp/hf6AmK3vH1:1» | |||
nwc10 | oops | ||
jnthn | at_pos ain't meant to be called directly really | 11:55 | |
nwc10 | this one: | ||
rn: my @a = "Q"; @a.at_pos(-1) = "Pi"; say @a; | |||
p6eval | niecza v24-23-g0520c7c: OUTPUT«Unhandled exception: Writing to readonly scalar at /tmp/iUM6cmaxiq line 1 (mainline @ 4)  at /home/p6eval/niecza/lib/CORE.setting line 4233 (ANON @ 3)  at /home/p6eval/niecza/lib/CORE.setting line 4234 (module-CORE @ 580)  at /home/p6eval/niecza/li… | ||
..rakudo a3869a: OUTPUT«ResizablePMCArray: index out of bounds! in block at src/gen/CORE.setting:6312 in block at /tmp/ZaPQ0bu_mB:1» | |||
jnthn | @foo[...] calls postcircumfix:<[ ]> | ||
nwc10 | so, direct assignment is a bounds failure, but I can bind to it and then assign without error | ||
I'd figured out that @foo[...] called that, by using ack to find the error message :-) | |||
jnthn | Anyway, I suspect that the oddness is 'cus at_pos (the method) was written expecting to never be passed anything negative. | 11:56 | |
nwc10 | ah OK. | ||
jnthn | Which it never is in normal use thanks to postcircumfix:<[ ]> | ||
nwc10 | I shall try refactoring it to treat anything negative as, um, wrong-in-some-fashion | 11:57 | |
jnthn | Yeah, but if you do that let's consider moving the check out of postcircumfix maybe? | ||
Doing it twice over is wasteful. | |||
nwc10 | good point | ||
I might be abducted by the requirement to go out with the toboggan | 11:58 | ||
jnthn | ;) | ||
The other thing is that we can easily make the JVM impl of nqp::atpos etc just reject negative indices rather than trying to make sense of them, and declare that as the expected behavior. | 11:59 | ||
(Then find a way to make it happen on Parrot.) | |||
nwc10 | My gut feeling is that negative indices (and sparseness, if desired) belong in the layer that implements the Perl 6 compiler | ||
and the NQP level should be non-negative non-sparse only | 12:00 | ||
but this is a gut feeling | |||
jnthn | Well, you aren't allowed negative indices in Perl 6 really. | ||
@a[-1] is an error, you're meant to write @a[*-1] | |||
nwc10 | I sort of inferred that from Any.pm's grumpiness :-) | ||
12:06
not_gerd joined
|
|||
moritz idly ponders an ORM where you have roles instead of result classes, and when you do a join, it mixes in the roles that correspond to each table | 12:13 | ||
jnthn idly ponders than "ORM" is Swedish for "SNAKE" :) | 12:15 | ||
*that | |||
moritz | .oO( pyhton ORM ) |
||
though I guess when most of your tables have a last_changed timestamp, you'd get either a silent overwrite or a coposition conflict | 12:18 | ||
nwc10 | OK, is this a rakudobug | ||
r: my @a = "Q"; @a.at_pos(-1) = "Pi"; say @a; | |||
p6eval | rakudo a3869a: OUTPUT«ResizablePMCArray: index out of bounds! in block at src/gen/CORE.setting:6312 in block at /tmp/pAjocXUetQ:1» | ||
nwc10 | r: my @a = "Q"; say @a; @a.at_pos(-1) = "Pi"; say @a; | ||
p6eval | rakudo a3869a: OUTPUT«QPi» | ||
nwc10 | ie, adding say @a; makes everything peachy | 12:19 | |
jnthn | nwc10: It's just a consequence of nothing else downstream of at_pos expecting a -1 | 12:21 | |
nwc10: Of note, I suspect it's the "make sure we reified up to n elements" thing | 12:22 | ||
And reificiation is memoized, so the say makes it happen so it can output the array and then the data is luckily in the right place when the unexpected -1 indexing happens. | |||
nwc10 | OK. so this is all suggesting that life is simpler if at_pos does the negative index sanity check | 12:23 | |
jnthn | Anyway, I think the answer to all of this is "passing negative numbers to at_pos is a bad idea" :) | ||
Yeah. | |||
nwc10 | doctor doctor, it hurts if I do this | ||
well, don't do that then | |||
jnthn | Right, it's one of those. Everyday use doesn't run into this since @a[-1] already catches it | 12:24 | |
12:32
jurosz joined
|
|||
arnsholt | r: say "ø".bytes | 12:43 | |
p6eval | rakudo a3869a: OUTPUT«No such method 'bytes' for invocant of type 'Str' in block at /tmp/soOR_c1cPr:1» | ||
arnsholt | Oh, durr. Of course there's no .bytes in Str | 12:44 | |
12:44
jurosz is now known as mj41
|
|||
arnsholt | moritz: I want a DB that is an object store, rather than a relational one =) | 12:51 | |
timotimo: You're just timo on GitHub right? | 12:57 | ||
moritz | arnsholt: if that DB supports SQL-like queries, schemas and transactions, I'm all for it :-) | 12:58 | |
arnsholt | Yeah, that's always been the problem IIRC | 12:59 | |
moritz | I honestly don't understand the "schemaless" approach. For most applications the code has to make assumptions on the structure of the data (and if not, a simple key/value store is likely sufficient) | 13:09 | |
I mean, I like duck typing in my code, but in the data it always felt way more dangerous | 13:10 | ||
if I have made a type error that wasn't caught due to duck typing, I fix it an recompile. Done. But when I made type errors in the data (that weren't caught because of lack of a schema), then recompiling my code isn't enough to rectify the problem | 13:11 | ||
jnthn | I think having a schema *somewhere* is good, the issues arise when you end up with it in two places or zero places. If you're working in a language that guides you to specify types statically, then that serves as a kind of schema and thus keeping it sync'd with a SQL server's view of the schema is the pain point. In a more dynamic language, you don't get that duplication. | 13:13 | |
In other words, if you have yoru schema defined/statically checked in code, then a schemaless store can still be pretty safe. | 13:14 | ||
moritz | well, if your language is statically typed, and you change the types, you must still take care of migrating the data | ||
jnthn | Sure, but you gotta take care of what when changing any schema :) | 13:15 | |
Granted, if the same thing owns the data and the schema then that can make things easier. | 13:16 | ||
moritz | so we'd really need some way that the data store and the application can automatically sync or check their data models | 13:17 | |
jnthn | One approach (being used fairly well on some $dayjob client I sometimes do stuff with) is to specify the migrations in code. The database is given a version number; if at application startup the version is incorrect, it applies the changes. | 13:19 | |
13:19
not_gerd left
|
|||
moritz | that sounds sane | 13:20 | |
which basically means that the application has a model layer which is the only thing ever allowed to write to the database | |||
13:42
pupoque joined
13:47
fijal joined
|
|||
fijal | hi | 13:51 | |
arnsholt | 'lo fijal | 13:52 | |
jnthn: I think that's the RoR way (or at least possible to do in RoR) | 13:53 | ||
fijal | jnthn: hi, I think RaceConditions hinted me that you might want to have some questions about PyPy | 13:54 | |
jnthn | arnsholt: Perhaps so. This was a .Net shop. :) | ||
fijal | but maybe I misunderstood | ||
jnthn | fijal: Don't have anything just yet. At the moment I'm working on a JVM backend for NQP, but at least half the work is actually spotting the leftover places where things were coupled too tightly to Parrot. I'm interested in targeting more things in the future, I'm open to looking at PyPy, but my plate is a bit too full to think about that right now. :) | 13:58 | |
arnsholt | jnthn: Yeah, I figured they might be =) | ||
jnthn | arnsholt: Yes, there's LOADS of .Net here in Sweden :) | 13:59 | |
So I encounter it a lot. | |||
fijal | jnthn: ok | 14:00 | |
jnthn: I can also tell you why JVM is a bad idea, but I'm not sure you're interested in hearing that | |||
arnsholt | Yeah, I suspect there's a fair bit of .Net this side of the border as well, 'cept I don't see a lot of it, being in academia and all | 14:01 | |
jnthn | fijal: It's not really about good/bad ideas, it's about trade-offs. | ||
fijal | well, JVM is a bad platform for dynamic languages | ||
compared to e.g. writing an interpreter in C | |||
jnthn | What makes it especially bad? | 14:02 | |
fijal | it's too tied to java | ||
RPython is a much better choice (but you would expect me to say that) | |||
jnthn | :) | 14:03 | |
fijal | but they told you a lot of lies | 14:04 | |
of course it always depends | |||
but building stuff in RPython is both easier and gives you a better result | |||
geekosaur | having been at least on the soutskirts of several projects trying to use the jvm for not-java, I can vouch for that to some extent; if it's not a java feature, it's porly supported and may require a lot of hackery | 14:05 | |
*poorly | |||
jnthn | OTOH, Java doesn't do much, and as a result the JVM doesn't really do a great deal either. There is something to be said for having a small number of primitves and doing them really fast. OTOH, there are places where the fact the VM doesn't directly provide what's needed makes it hard to do well and/or impossible to get as fast as a VM that did offer the thing natively. | 14:06 | |
fijal | well | ||
but I claim we solved this | |||
and your performance expectations are a bit off probably | 14:09 | ||
because say jruby puts lots and lots of effort working around java limitations | |||
or JVM | |||
jnthn | My performance expectations are "better than Parrot". I think we'll get that. :) | ||
geekosaur | there is that... | 14:10 | |
fijal | hehe | ||
ok | |||
but then, why JVM? | |||
and of course why not PyPy? | |||
geekosaur | I think someone's poking at pypy (inspired by topaz) --- but the jvm is there and widely deployed | 14:11 | |
fijal | as is posix... | 14:12 | |
moritz | POSIX doesn't come with a GC and JIT compiler | ||
14:12
PacoAir joined
|
|||
geekosaur | from my* pov there's a smallish gap petween parrot and pypy due to deployment issues, and a much larger gap between those and clr/jvm | 14:12 | |
fijal | moritz: pypy does | ||
moritz | fijal: yes, but POSIX doesn't. | ||
fijal | geekosaur: er, I think you're missing the point | ||
jnthn | Partly familiarity, partly that I think there should be the option to use some kind of Perl on the JVM, partly because it has a real-world-tested threads implementation and we need to get our story straight on those. | 14:13 | |
geekosaur | and I hink *you* just missed the point | ||
fijal | geekosaur: pypy does compile stuff to native executable | ||
there is no "deployment problem" | |||
geekosaur | oh, youre stuck on performance | ||
moritz | fijal: parrot is also used on POSIX systems, but it's not widely deployed either | ||
geekosaur | that's not the deployment problem | ||
let me rephrase that: how many people even know about pypy? | |||
fijal | moritz: you need parrot to run stuff though, right? | ||
geekosaur | vs. how many know about the jvm and use it daily? | ||
fijal | geekosaur: why do you care? | 14:14 | |
geekosaur | ... | ||
fijal | geekosaur: if you get an executable that's posix-compliant? | ||
as in it's not the same | 14:15 | ||
geekosaur | hello, perl6 is already seen as being backed into a pointless niche. rebasing on *another* niche VM is not helpful | ||
fijal | you don't write a compiler to pypy bytecode that requires deployment | ||
you write an interpreter in RPython that's different | |||
14:15
PacoAir left
14:16
erkan left,
PacoAir joined
|
|||
geekosaur | there is a marketing issue here; I'm going to guess you don't see why that has any significance (and tbh that means you're part of the problem in some sense) | 14:16 | |
fijal | jnthn: I think perl on JVM is honestly not very helpful, but fair enough | ||
moritz | why shouldn't it be helpful? | ||
fijal | jnthn: as python on JVM for example has ever seen adoption from java programmers and not from python progammers | ||
moritz | what's wrong with that? | 14:17 | |
fijal | geekosaur: you mean "wrote on JVM" adds you marketing boost? | ||
jnthn | fijal: "only ever"? | ||
fijal | jnthn: ? | ||
geekosaur | perl6 needs any boost it can get. seriously | ||
moritz | and running on java-only mobile phones is certainly a big plus | ||
jnthn | fijal: "python on JVM for example has ever seen adoption" - did you mean "only ever" or did you typo "never"? :) | ||
fijal | ah | ||
jnthn: only Java using people ever used python on JVM | 14:18 | ||
14:18
Gwyxx joined
|
|||
fijal | as in, noone moved from CPython to Jython | 14:18 | |
but there are some users as a way to script JVM | |||
sure | |||
geekosaur: I'm not sure JVM is cool enough any more honestly, but well | |||
geekosaur | "vm that everyone knows about and exists everywhere" is kinda necessary to counter the years of "parrot wtf". | ||
cool doesn't really enter into it | |||
_sri | JRuby is a better example for success with the JVM | 14:19 | |
geekosaur | you're thinking like a geek. that's not sufficient | ||
fijal | geekosaur: I personally think that building on a technology that's "cool" these days would give you some boost | ||
but well | |||
it'\s a matter of opinion | |||
_sri: yes | |||
geekosaur | again, you're thinking like a geek. and again, that's not sufficient | 14:20 | |
moritz | also, scala and clojure | ||
just to name two more non-java languages on the JVM | 14:21 | ||
fijal | well yeah | ||
aren't geeks the target audience? | 14:22 | ||
anyway | |||
of course I don't have any way to convince you what you should do in the free time | 14:23 | ||
_sri | the JVM is as close to a "you won't get fired for choosing this" option for VMs as it gets | ||
moritz | then please stop doing so | ||
fijal | moritz: ok, goodbye | ||
14:23
fijal left,
Patterner left
|
|||
moritz waves | 14:23 | ||
14:24
fijal joined,
fijal left
|
|||
jnthn | Just to be clear: the way this is being done is *adding* the JVM support as an extra backend, just like we were able to add the debugger as a different frontend. It's not like I'm saying "we'll only run on the JVM forever" or even "we're going to now tie ourselves to the JVM". I'm saying the JVM is where we're going as the first non-Parrot thing. | 14:24 | |
Unless pmurias beats me to it with the JS work ;) | |||
ah, he left. | |||
14:24
Psyche^ joined,
Psyche^ is now known as Patterner
|
|||
moritz | sorry 'bout that. I thought he wanted to discuss technical merits, not just convince us | 14:25 | |
14:25
stevan_ joined,
jaldhar joined
|
|||
jnthn | Well, I'm mostly convinced by technical merit, so... :) | 14:26 | |
14:29
stevan_ left
|
|||
rindolf | Hi jnthn , moritz | 14:31 | |
jnthn | o/ rindolf | ||
nwc10 | bother, I missed fijal. I know I can /msg him | 14:32 | |
rindolf | jnthn: what's up? | ||
jnthn | rindolf: Not much. It's the weekend, I'm trying to remember to relax as well as hack on stuff ;) | ||
14:39
Chillance joined
14:40
fgomez left
14:45
pmurias joined
|
|||
[Coke] | (why the jvm) - because then I can run perl6 at a work, since I have to run things inside a j2ee container. :) | 14:46 | |
nwc10 | it's that sort of thing that makes that JVM a politically useful target, even if it's not the best from a technical perspective | 14:48 | |
14:49
erkan joined
15:20
b1rkh0ff joined
15:21
SunilJoshi joined
|
|||
timotimo | arnsholt: i am indeed "timo" on github | 15:22 | |
15:23
benabik left,
benabik joined
|
|||
arnsholt | Excellent. I've added you as a collaborator to the repo =) | 15:27 | |
Hmm. ufo generates a circular dependency for Net::ZMQ | 15:29 | ||
moritz | arnsholt: that usually happens if there's a "use"-statement in the pod | 15:30 | |
in one of the pods, at least | |||
arnsholt | I don't have any POD | 15:31 | |
moritz | hm | 15:32 | |
arnsholt | Could be that I've actually put in a circular use chain | 15:37 | |
Indeed I have =D | |||
Thought I'd tested that before running ufo | 15:38 | ||
Oh, derp. Think I know what I did | |||
moritz | ufo prevails! | 15:39 | |
arnsholt | Indeed =) | 15:40 | |
timotimo | so, is there a test suite that we can adapt from somewhere? i suppose a few simple tests can be written that create inproc sockets and send some stuff around? | 15:46 | |
arnsholt | In-process might work | 15:47 | |
I was going to see what ZMQ::LibZMQ2 on CPAN did for its testsuite to get inspiration | |||
But I'm also dangerously close to doing some more NQP/dyncall hacking | 15:48 | ||
Our string handling ATM kind of sucks | |||
15:51
marloshouse left
|
|||
moritz | r: my int4 $x = 1; for 1..10 { $x = $x * 2; say $x } | 15:54 | |
p6eval | rakudo a3869a: OUTPUT«2481632641282565121024» | ||
moritz | have any of rakudo's small-int types adopted to benefit from the REPR changes? | 15:56 | |
15:57
marloshouse joined
|
|||
jnthn | Well, it's more that the lexical handling ain't updated yet | 15:57 | |
moritz | so it might work as an attribute? | 15:58 | |
jnthn | Yeah | ||
arnsholt | It should work as an attribute I think | ||
Or at least, it did work as an attribute at some point during my branch =) | |||
moritz | r: class A { has int8 $.x; method doit { for ^16 { $!x = $!x * 2; say $!x } }; A.new(x => 1).doit | 15:59 | |
p6eval | rakudo a3869a: OUTPUT«===SORRY!===Unable to parse expression in block; couldn't find final '}'at /tmp/GsjRTgfV_u:1------> $!x * 2; say $!x } }; A.new(x => 1).doit⏏<EOL> expecting any of: method arguments postfix infix o… | ||
moritz | r: class A { has int8 $.x; method doit { for ^16 { $!x = $!x * 2; say $!x } } }; A.new(x => 1).doit | ||
p6eval | rakudo a3869a: OUTPUT«Cannot assign to a non-container in block at src/gen/CORE.setting:769 in method BUILDALL at src/gen/CORE.setting:752 in method bless at src/gen/CORE.setting:742 in method new at src/gen/CORE.setting:727 in block at /tmp/NMlB46N9AC:1» | ||
moritz | r: class A { has int8 $!x = 2; method doit { for ^16 { $!x = $!x * 2; say $!x } } }; A.new(x => 1).doit | 16:00 | |
p6eval | rakudo a3869a: OUTPUT«Cannot assign to a non-container in block at src/gen/CORE.setting:797 in method BUILDALL at src/gen/CORE.setting:752 in method bless at src/gen/CORE.setting:742 in method new at src/gen/CORE.setting:727 in block at /tmp/cAixnkgtbt:1» | ||
moritz | r: class A { has int8 $!x = 2; method doit { for ^16 { $!x = $!x * 2; say $!x } } }; A.new.doit | ||
p6eval | rakudo a3869a: OUTPUT«0000000000000000» | ||
moritz | r: class A { has int8 $!x = 2; method doit { $!x = 1; for ^16 { $!x = $!x * 2; say $!x } } }; A.new.doit | ||
p6eval | rakudo a3869a: OUTPUT«248163264-128000000000» | ||
moritz | bumpy ride, but got there eventually :-) | 16:01 | |
16:02
Energy joined
|
|||
arnsholt | Yeah, the lack of containers on natives is a bit annoying as well | 16:02 | |
16:05
Energy left
16:07
stevan_ joined
|
|||
arnsholt | timotimo: The API is ZMQ 2.x, BTW (since that's what my Ubuntu had on tap) | 16:29 | |
16:31
Aka2 joined
|
|||
timotimo | ah | 16:31 | |
arnsholt | Hopefully that's manageable | 16:33 | |
Or does ipython use ZMQ3? | |||
timotimo | i think it supports both, but i'm not sure. let me have a look. | 16:38 | |
arnsholt | I want to support ZMQ3 as well, but the ZMQ2 API is smaller, so I'd like to get a handle on that first, and then start looking at ZMQ3 | 16:39 | |
timotimo | mhm | 16:40 | |
apparently they require >= 2 | 16:42 | ||
2.1.11 is their minimum version at this time | |||
arnsholt | That's the the exact version Ubuntu ships, so excecllent =) | 16:43 | |
timotimo | coincidence? :) | 16:45 | |
timotimo builds a fresh rakudo | |||
with an nqp from master, hell yeah bleeding edge :)) | 16:47 | ||
jnthn | You should see how bleeding my local one is :P | 16:49 | |
timotimo | :3 | ||
make: *** [NQPP5QRegex.pbc] Segmentation fault | 16:51 | ||
well, that was surprising | |||
jnthn | Try a make clean :) | ||
timotimo | sure | ||
jnthn | I had to do that a couple of times yesterday. I suspect a missing Makefile dep somewhere, but didn't spot it. | 16:53 | |
16:57
awwaiid left
|
|||
timotimo | huh, make clean wasn't clean enough it seems | 16:58 | |
maybe i need a newer parrot, too? | |||
jnthn | No | ||
moritz | rakudo compilation still segfaults for me :( | ||
timotimo git clean'd | 16:59 | ||
jnthn | :/ | ||
moritz | I've tried to run it under gdb, but it seemed to hang | ||
I aborted after a few minutes | |||
17:03
uvtc joined
|
|||
timotimo | git clean helped it seems | 17:03 | |
er, no | |||
three seconds after i said that, it exploded :)) | |||
arnsholt | No segfault on NQP HEAD here | 17:06 | |
But failures in the test suite, it seems | 17:07 | ||
timotimo deleted nqp, parrot and install folders | |||
arnsholt | Segfault before first test but after plan in t/nqp/60-bigint.t and segfault after test 71 in t/qast/qast.t, as well as failure of test 19 (which is bigint-related) | 17:08 | |
arnsholt tries HEAD^ | 17:09 | ||
pmichaud | good morning, #perl6 | 17:11 | |
arnsholt | 'lo pmichaud | ||
moritz | good am, pm | ||
jnthn | arnsholt: That one I had to kill with a properly clean | ||
It's something to do with not getting a proper bigint ops rebuild. | |||
s/properly/proper/ | 17:12 | ||
o/ pmichaud | |||
arnsholt | Aha | ||
FROGGS | hi pmichaud, hi all | 17:14 | |
dalek | p/rx-portability: f5d0a8b | jnthn++ | / (5 files): Stub in an NFA representation. We'll keep it in the current form for construction; this is what we'll feed to the executor and also serialize them as. |
17:15 | |
p/rx-portability: ecc5234 | jnthn++ | src/QAST/Operations.nqp: Sketch in some nqp:: ops for NFA handling. |
|||
p/rx-portability: ce1308b | jnthn++ | src/stage0/ (9 files): Update bootstrap to get nqp::ops. |
|||
p/rx-portability: b027079 | jnthn++ | src/ (3 files): Implement various NFA ops. |
|||
p/rx-portability: 5980aa5 | jnthn++ | src/QRegex/NFA.nqp: Start using new NFA REPR and ops. Avoids doing a lot of v-table calls while evaluating the NFA (can do a bit more improvement yet also). This should also help ease NFA porting, plus it's good to get this cleared up before porting things. |
|||
arnsholt | jnthn: Cheers. That fixed it | ||
jnthn | moritz: Does make test in NQP look good to you? | 17:16 | |
moritz | jnthn: I'm rebuilding from scratch now, so will tell you when I get there again :-) | ||
jnthn | ok :) | ||
timotimo | hm, i wonder if i had been running parrot 5 at the time nqp segfaulted when trying to build | 17:17 | |
because now it looks like i've gotten to rakudo, with --gen-parrot | 17:18 | ||
uvtc | Oh, interesting. The Parrot history I was asking about last night was re-asked by cotto on #parrot, and allison had some comments on it. | 17:23 | |
pmichaud | I guess I should go read the logs. :-) | 17:24 | |
uvtc | Oh, hi pmichaud . | ||
timotimo | /home/timo/build/rakudo/install/bin/nqp --target=pir --output=src/gen/perl6-bootstrap.pir --encoding=utf8 \ --vmlibs=perl6_ops src/gen/BOOTSTRAP.pm | 17:25 | |
get_pmc_keyed_str() not implemented in class 'ResizablePMCArray' | |||
is this known? | |||
jnthn | No | 17:26 | |
Can you gist me the entire output? | 17:27 | ||
timotimo | sure | ||
paste.ee/p/kIgEB | |||
oh, hold on | 17:28 | ||
i think that got corrupted | |||
pmichaud | moritz++ # comments on #parrot and rakudo/parrot merge | 17:29 | |
timotimo | paste.ee/p/Cehwq - there you go | 17:30 | |
jnthn | timotimo: Whoa | 17:31 | |
timotimo: What Rakudo sha1 and what nqp sha1 are you building? | |||
timotimo | Sonoma-93-g14c9305 - rakudo | nqp - 2013.01-143-g26d0d0f | 17:32 | |
jnthn | Because that looks exactly like a Rakudo speaking a previous version of the repr compose protocl... | ||
2013.01-113-ga3869a0 | |||
That is my Rakudo | 17:33 | ||
timotimo | i *thought* i had git pull'd rakudo just before i did that. | ||
oh, yeah, i was on the constant-folding branch | |||
that was clever | |||
jnthn | oops :) | ||
And also, phew. That error could have meant something a lot wrose if it had happened in a difference place. | 17:34 | ||
timotimo | yes, excuse me for causing a state of nationwide panic in johnathantown :) | ||
jnthn | np :) | ||
shop, dinner, etc :) | 17:38 | ||
timotimo | rakudo succeeded to build now :) | 17:40 | |
17:42
WAAMX10 joined
|
|||
timotimo | arnsholt: any way to implement the ipython heartbeat socket? it's supposed to run asynchronous to the program. (except for of course q:x'ing another rakudo...) | 17:46 | |
arnsholt | Not really, I think | ||
For that we really want threads | |||
timotimo | yes, we do | ||
arnsholt | jnthn: Using the set/get_int REPR hooks to deal with the length of a C string buffer: acceptably eww, or "don't go there" eww? | 17:48 | |
17:56
ponbiki left
18:00
SunilJoshi left
|
|||
jnthn | arnsholt: That's...wrong. | 18:02 | |
arnsholt | Yeah, I know =) | ||
jnthn | Those are for boxing/unboxing only :) | ||
arnsholt | Won't do that, then | ||
Doodling around with the best ways to implement a CStr REPR as outlined in the gist I made a while back | 18:03 | ||
18:07
ponbiki joined
18:08
ponbiki is now known as Guest20810
|
|||
moritz | jnthn: after git clean -dxf in both rakudo and nqp, nqp's 'make test' and rakudo's build succeeded again | 18:19 | |
jnthn | moritz: Phew. :) I wouldn't mind trying to figure out what we're missing. | 18:23 | |
18:31
Aka2 left
|
|||
nwc10 | bother - does an "is rw" subroutine have to "fall off the end" to work? (ie, be able to assign to the returned lvalue) | 18:34 | |
18:35
SunilJoshi joined
|
|||
moritz | nwc10: no, you can return-rw | 18:36 | |
nwc10 | excellent! | 18:37 | |
moritz | r: my $x = 42; sub f() is rw { return-rw $x }; f() = 23; say $x | ||
p6eval | rakudo a3869a: OUTPUT«23» | ||
moritz | it's kind of a design smell, to have both return and return-rw. But normal people(tm) exepct return to decontainerize | 18:38 | |
18:46
ObseLeTe joined
|
|||
colomon has never used return-rw | 18:50 | ||
benabik | Why doesn't return just do return-rw inside sub is rw? | 18:51 | |
moritz | benabik: because return isn't simply lexically scoped | ||
benabik | oy | ||
... Wait | 18:54 | ||
What kind of scoping does it use then? | |||
Or is this "mostly lexically scoped, but can be altered because it's all exceptions"? | 18:56 | ||
moritz | yes | 19:00 | |
jnthn back from le dinner :) | 19:08 | ||
nwc10 | was it good? | ||
jnthn | It involved bacon. ;) | 19:09 | |
And white wine. | |||
And cream and mushrooms and stuff. | |||
So yeah, pretty good ;) | |||
colomon | bacon++ | 19:10 | |
moritz | sounds diverse and tasty :-) | 19:11 | |
19:25
ObseLeTe left
|
|||
alec__ | spaghetti carbonara? | 19:28 | |
uvtc | alec__: Is that a pun about the old pre-Cocoa Mac OS interface? :) | 19:33 | |
19:33
pyrimidine joined
|
|||
jnthn | alec__: Not really...no eggs or cheese in what I did :) | 19:33 | |
alec__ has a policy of letting you believe he's clever whenever something he says happens to be funny like that, uvtc | 19:34 | ||
i see, jnthn | |||
19:48
SunilJoshi left
19:49
amkrankruleuen left
|
|||
jnthn | We call the things CONTROL catches control exceptions...do we have a name for the non-control ones (besides non-control :))? | 19:59 | |
moritz | errors? :-) | 20:03 | |
ordinary exceptions? | |||
nwc10 | regular socials? | 20:08 | |
20:20
brrt joined
|
|||
colomon | they'd be more popular if they were ice cream socials. | 20:21 | |
masak | (by symmetry, they should be called 'catch exceptions'.) | 20:29 | |
hi, #perl6 | |||
20:30
fgomez joined
20:31
domidumont left
|
|||
brrt | hi masak | 20:34 | |
20:39
kaare_ left
|
|||
colomon | o/ | 20:48 | |
moritz | \o masak | 20:50 | |
20:52
ggoebel_ joined
20:54
spider-mario joined
21:19
pyrimidine left
21:20
pyrimidine joined
21:27
thou joined
21:29
brrt left
21:40
xdbr left
|
|||
[Coke] starts ripping things out at github.com/coke/parrot . only something small so far. | 21:40 | ||
Every PMC I've tried so far is actually used internally somewhere. ;) | |||
21:53
lizmat is now known as Liz,
Liz is now known as lizmat
|
|||
pmurias | [Coke]: what would be the benefit of that? easier maintenance? | 21:56 | |
[Coke] | pmurias: parrot has a lot of stuff rakudo isn't using. Maybe rakudo will go faster on a parrot that doesn't have them. | 21:57 | |
Or have a smaller footprint, or.. | |||
or, at least, build faster. | |||
21:58
dbr joined
22:02
pupoque left
22:03
dbr left,
dbr joined
22:06
pupoque joined
|
|||
uvtc | [Coke]++ | 22:07 | |
masak | (build faster)++ | 22:08 | |
22:08
PacoAir left
22:09
pyrimidine left,
pupoque left
22:31
pyrimidine joined,
MikeFair_ joined
22:32
rindolf left
22:33
spider-mario left
22:37
proller left
22:44
bluescreen100 left
|
|||
dalek | p/rx-portability: 5ecc011 | jnthn++ | src/ (3 files): Add nqp::const mechanism. Allows mapping constants in a backend-independent way. |
23:02 | |
p/rx-portability: b7756b5 | jnthn++ | src/stage0/ (9 files): Update bootstrap. |
|||
p/rx-portability: 081a30f | jnthn++ | src/QRegex/ (2 files): Lots of pir:: => nqp:: in NFA and Cursor. |
|||
23:06
pyrimidine left
23:07
pjcj left
23:09
pjcj joined
23:12
alester joined
|
|||
masak | 'night, #perl6 | 23:32 | |
23:37
MikeFair_ left
23:38
pyrimidine joined
23:42
alester left
|
|||
jnthn rests also...'night | 23:48 | ||
colomon | o/ | 23:49 |