| Time |
S |
Nick |
Message |
| 00:02 |
|
dalek |
winxed/multi_syntax: d573a38 | Whiteknight++ | / (2 files): |
| 00:02 |
|
dalek |
winxed/multi_syntax: the new multi syntax overrides, and is ignorant of, a more manual approach |
| 00:02 |
|
dalek |
winxed/multi_syntax: review: https://github.com/Whiteknight[…]commit/d573a38157 |
| 00:02 |
|
dalek |
winxed/verbose_diagnostics: d00e872 | Whiteknight++ | / (2 files): |
| 00:02 |
|
dalek |
winxed/verbose_diagnostics: Merge branch 'nf_master' into verbose_diagnostics |
| 00:02 |
|
dalek |
winxed/verbose_diagnostics: review: https://github.com/Whiteknight[…]commit/d00e872e37 |
| 00:07 |
|
dalek |
winxed/multi_syntax: ad9459c | Whiteknight++ | winxedst1.winxed: |
| 00:07 |
|
dalek |
winxed/multi_syntax: Make sure to initialize the is_multi field, so we can avoid null pmc accesses |
| 00:07 |
|
dalek |
winxed/multi_syntax: review: https://github.com/Whiteknight[…]commit/ad9459cc00 |
| 00:13 |
|
|
preflex_ joined #parrot |
| 00:18 |
|
dalek |
winxed/verbose_diagnostics: 9f746d1 | Whiteknight++ | winxed.winxed: |
| 00:18 |
|
dalek |
winxed/verbose_diagnostics: subs_by_flag -> subs_by_tag. explicitly return null when we can't load the packfile |
| 00:18 |
|
dalek |
winxed/verbose_diagnostics: review: https://github.com/Whiteknight[…]commit/9f746d1b19 |
| 00:19 |
|
lucian |
bah, can't fix this damned bug |
| 00:20 |
|
lucian |
i can't for the life of me figure out why this happens |
| 00:34 |
|
lucian |
this test fails https://github.com/lucian1900/[…]typeobject.t#L126 |
| 00:34 |
|
lucian |
very odd |
| 00:54 |
|
whiteknight |
let me look |
| 00:55 |
|
whiteknight |
...loading...slowly... |
| 00:55 |
|
|
darbelo joined #parrot |
| 01:03 |
|
whiteknight |
lucian: okay, I see the test now. What part of it fails? The assertion? |
| 01:03 |
|
lucian |
whiteknight: yeah, i.bla is null |
| 01:04 |
|
whiteknight |
darn |
| 01:04 |
|
lucian |
apparently tracking nulls on parrot is hard |
| 01:04 |
|
whiteknight |
what do you mean? |
| 01:05 |
|
lucian |
anyway, type.winxed:t.__getattribute__ gets called for that |
| 01:05 |
|
lucian |
whiteknight: that null has to come from somewhere, i never explicitly return null |
| 01:05 |
|
whiteknight |
ah, okay |
| 01:07 |
|
dalek |
Rosella: 69aef39 | Whiteknight++ | src/ (5 files): |
| 01:07 |
|
dalek |
Rosella: start updating the Contract library with new features and updated standards |
| 01:07 |
|
dalek |
Rosella: review: https://github.com/Whiteknight[…]commit/69aef391ee |
| 01:07 |
|
dalek |
Rosella: 2e30dc5 | Whiteknight++ | s (8 files): |
| 01:07 |
|
dalek |
Rosella: Rename Contract library to Assert |
| 01:07 |
|
dalek |
Rosella: review: https://github.com/Whiteknight[…]commit/2e30dc532b |
| 01:08 |
|
lucian |
whiteknight: i probably need to test __getattribute__ failures better |
| 01:15 |
|
dalek |
Rosella: 0111611 | Whiteknight++ | s (2 files): |
| 01:15 |
|
dalek |
Rosella: Add some experimental higher-order functions to the core library. Inspired, in part, by underscore.js and other sources |
| 01:15 |
|
dalek |
Rosella: review: https://github.com/Whiteknight[…]commit/01116116a3 |
| 01:26 |
|
dalek |
Rosella: 7b779df | Whiteknight++ | src/ (2 files): |
| 01:26 |
|
dalek |
Rosella: Add forward-declarations for Function routines to Core.include. Fix compilation in assert |
| 01:26 |
|
dalek |
Rosella: review: https://github.com/Whiteknight[…]commit/7b779df2e4 |
| 01:26 |
|
lucian |
hmm failure to find attributes does throw the expected exception |
| 01:42 |
|
* Coke |
finds the release guide probably more convoluted than strictly necessary. |
| 02:00 |
|
Coke |
anyone planning on committing anything anytime soon? |
| 02:01 |
|
|
RobertLJ_ left #parrot |
| 02:01 |
|
Coke |
(I'm testing a 3.7 release candidate right now.) |
| 02:18 |
|
dalek |
nqp/nfa: ef8359b | pmichaud++ | src/Q (2 files): |
| 02:18 |
|
dalek |
nqp/nfa: Add :rxtype<ws> to differentiate meta whitespace from direct calls to <.ws>. |
| 02:18 |
|
dalek |
nqp/nfa: review: https://github.com/perl6/nqp/commit/ef8359b6e8 |
| 02:18 |
|
dalek |
nqp/nfa: 6d9e44e | pmichaud++ | src/NQPQ/Actions.pm: |
| 02:18 |
|
dalek |
nqp/nfa: QRegex::Actions::buildsub no longer sets :blocktype('method') by default. |
| 02:18 |
|
dalek |
nqp/nfa: review: https://github.com/perl6/nqp/commit/6d9e44e169 |
| 02:18 |
|
dalek |
nqp/nfa: 88b34ff | pmichaud++ | / (3 files): |
| 02:18 |
|
dalek |
nqp/nfa: Initial version of nfa generation. Build nqpq by default for now to make testing easier. |
| 02:18 |
|
dalek |
nqp/nfa: review: https://github.com/perl6/nqp/commit/88b34ff82e |
| 02:18 |
|
dalek |
nqp/nfa: d3798ba | pmichaud++ | src/QRegex/NFA.nqp: |
| 02:18 |
|
dalek |
nqp/nfa: Relabel NFA_* constants to EDGE_*. Add a simple __dump() method to make it easier to visualize the NFA. |
| 02:18 |
|
dalek |
nqp/nfa: review: https://github.com/perl6/nqp/commit/d3798ba48e |
| 02:18 |
|
dalek |
nqp/nfa: 8c346b0 | pmichaud++ | src/PAST/NQP.pir: |
| 02:18 |
|
dalek |
nqp/nfa: Add nqp::sprintf opcode. |
| 02:18 |
|
dalek |
nqp/nfa: review: https://github.com/perl6/nqp/commit/8c346b0a89 |
| 02:18 |
|
dalek |
nqp/nfa: 94795ee | pmichaud++ | src/QRegex/ (2 files): |
| 02:18 |
|
dalek |
nqp/nfa: Initial protoregex nfa generation and merging. |
| 02:18 |
|
dalek |
nqp/nfa: review: https://github.com/perl6/nqp/commit/94795ee05e |
| 02:18 |
|
dalek |
nqp/nfa: 742b33a | pmichaud++ | src/QRegex/ (2 files): |
| 02:18 |
|
dalek |
nqp/nfa: Add NFA.run -- code to run the NFA on a given input string. |
| 02:18 |
|
dalek |
nqp/nfa: review: https://github.com/perl6/nqp/commit/742b33a871 |
| 02:23 |
|
|
rohit_nsit08 joined #parrot |
| 02:25 |
|
Coke |
so, where can someone on OS X get sha256sum ? |
| 02:26 |
|
Coke |
:P |
| 02:30 |
|
Coke |
gerd: you about? |
| 02:35 |
|
Coke |
msg kid51 did you cut the release on your mac? |
| 02:35 |
|
aloha |
OK. I'll deliver the message. |
| 02:42 |
|
tcurtis |
Coke: is there any difference between sha256sum and shasum -a 256? |
| 02:42 |
|
Coke |
tcurtis: I have no idea whatsoever. |
| 02:43 |
|
Coke |
(looks like shasum is a perl script) |
| 02:44 |
|
* Coke |
is done for the night, I'll just do the release on a linux box tomorrow. |
| 02:59 |
|
dalek |
website: soh_cah_toa++ | SOD: Symbolic Opcode Description |
| 02:59 |
|
dalek |
website: http://www.parrot.org/content/[…]pcode-description |
| 03:48 |
|
|
sri joined #parrot |
| 03:48 |
|
|
cotto joined #parrot |
| 03:49 |
|
|
darbelo joined #parrot |
| 04:02 |
|
dalek |
nqp/nfa: 505a3d7 | pmichaud++ | src/QRegex/NFA.nqp: |
| 04:02 |
|
dalek |
nqp/nfa: Add anchor and enumcharlist to QRegex::NFA. |
| 04:02 |
|
dalek |
nqp/nfa: review: https://github.com/perl6/nqp/commit/505a3d7e92 |
| 04:02 |
|
dalek |
nqp/nfa: ef5cfd3 | pmichaud++ | src/QRegex/NFA.nqp: |
| 04:02 |
|
dalek |
nqp/nfa: Some small fixes to anchors and eos handling. |
| 04:02 |
|
dalek |
nqp/nfa: review: https://github.com/perl6/nqp/commit/ef5cfd31e3 |
| 04:02 |
|
dalek |
nqp/nfa: 4903492 | pmichaud++ | src/QRegex/Cursor.nqp: |
| 04:02 |
|
dalek |
nqp/nfa: Code to invoke protoregexes in (decreasing) order of longest match. |
| 04:02 |
|
dalek |
nqp/nfa: review: https://github.com/perl6/nqp/commit/49034925ec |
| 04:20 |
|
cotto |
~~ |
| 04:25 |
|
dalek |
parrot: b9fb194 | cotto++ | docs/dev/profiling.pod: |
| 04:25 |
|
dalek |
parrot: temporarily delete an unfinished section in the profiling doc |
| 04:25 |
|
dalek |
parrot: review: https://github.com/parrot/parr[…]commit/b9fb194a43 |
| 04:37 |
|
|
tewk_ joined #parrot |
| 04:46 |
|
|
tewk joined #parrot |
| 04:47 |
|
ttbot |
Parrot b9fb194a MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/44596 |
| 04:48 |
|
cotto |
lolwut |
| 05:20 |
|
cotto |
Can someone try to repeat that? |
| 05:33 |
|
|
SHODAN joined #parrot |
| 05:50 |
|
|
fperrad joined #parrot |
| 06:15 |
|
|
SHODAN joined #parrot |
| 06:41 |
|
|
cotto joined #parrot |
| 07:01 |
|
cotto |
If the release hasn't been cut, we probably shouldn't send out a tarball that installs a known-horribly-broken parrot_debugger. |
| 07:03 |
|
cotto |
aloha, clock? |
| 07:03 |
|
aloha |
cotto: LAX: Tue, 00:03 PDT / CHI: Tue, 02:03 CDT / NYC: Tue, 03:03 EDT / UTC: Tue, 07:03 UTC / LON: Tue, 08:03 BST / BER: Tue, 09:03 CEST / TOK: Tue, 16:03 JST / SYD: Tue, 17:03 EST |
| 07:15 |
|
dalek |
nqp/nfa: 8ea85a9 | pmichaud++ | src/QRegex/NFA.nqp: |
| 07:15 |
|
dalek |
nqp/nfa: Refactor mergesubrule a bit. |
| 07:15 |
|
dalek |
nqp/nfa: review: https://github.com/perl6/nqp/commit/8ea85a939c |
| 07:18 |
|
|
woosley joined #parrot |
| 07:28 |
|
|
mj41 joined #parrot |
| 08:28 |
|
|
Kulag joined #parrot |
| 08:44 |
|
|
cotto joined #parrot |
| 09:02 |
|
|
bubaflub joined #parrot |
| 09:25 |
|
|
nine joined #parrot |
| 09:27 |
|
nine |
Hi! Would now be a good time to start implementing threading support in Rakudo or is Parrot now ready for that yet? |
| 09:30 |
|
|
Tene joined #parrot |
| 09:41 |
|
|
lucian joined #parrot |
| 09:47 |
|
cotto |
nine, it needs a lot of thought and design work, but we've been complaining about Parrot's poor threading support for a very long time. |
| 09:50 |
|
nine |
cotto: I'm not quite sure what to make of that answer :) |
| 09:51 |
|
cotto |
nine, I don't think the Parrot threading code is nearly mature enough, so Rakudo would end up having to roll its own. |
| 09:51 |
|
cotto |
(initially misparsed your question) |
| 09:51 |
|
cotto |
nine, if you want to help improve Parrot's threading model (so that Rakudo can start using it), that'd be most welcome. |
| 09:55 |
|
nine |
cotto: tempting :) It's just a matter of time having a full time job and a study and having picked concurrency support for Rakudo as topic for my bachelor's paper due in February. |
| 10:09 |
|
|
cotto joined #parrot |
| 10:12 |
|
|
ligne joined #parrot |
| 10:24 |
|
|
RobertLJ joined #parrot |
| 10:58 |
|
|
NotFound joined #parrot |
| 10:58 |
|
NotFound |
Hi |
| 11:02 |
|
cotto |
hi NotFound |
| 11:14 |
|
cotto |
aloha, clock? |
| 11:14 |
|
aloha |
cotto: LAX: Tue, 04:14 PDT / CHI: Tue, 06:14 CDT / NYC: Tue, 07:14 EDT / UTC: Tue, 11:14 UTC / LON: Tue, 12:14 BST / BER: Tue, 13:14 CEST / TOK: Tue, 20:14 JST / SYD: Tue, 21:14 EST |
| 11:19 |
|
dalek |
winxed: 250bbe7 | Whiteknight++ | winxedst1.winxed: |
| 11:19 |
|
dalek |
winxed: Add multi funcitionality to class methods. |
| 11:19 |
|
dalek |
winxed: review: https://github.com/NotFound/wi[…]commit/250bbe724d |
| 11:19 |
|
dalek |
winxed: b239fab | Whiteknight++ | t/advanced/10multi.t: |
| 11:19 |
|
dalek |
winxed: update multi tests |
| 11:19 |
|
dalek |
winxed: review: https://github.com/NotFound/wi[…]commit/b239fabb50 |
| 11:19 |
|
dalek |
winxed: c23371e | Whiteknight++ | / (2 files): |
| 11:19 |
|
dalek |
winxed: Merge branch 'nf_master' into multi_syntax |
| 11:19 |
|
dalek |
winxed: review: https://github.com/NotFound/wi[…]commit/c23371e7c5 |
| 11:19 |
|
dalek |
winxed: d573a38 | Whiteknight++ | / (2 files): |
| 11:19 |
|
dalek |
winxed: the new multi syntax overrides, and is ignorant of, a more manual approach |
| 11:20 |
|
dalek |
winxed: review: https://github.com/NotFound/wi[…]commit/d573a38157 |
| 11:20 |
|
dalek |
winxed: ad9459c | Whiteknight++ | winxedst1.winxed: |
| 11:20 |
|
dalek |
winxed: Make sure to initialize the is_multi field, so we can avoid null pmc accesses |
| 11:20 |
|
dalek |
winxed: review: https://github.com/NotFound/wi[…]commit/ad9459cc00 |
| 11:20 |
|
dalek |
winxed: 6f516b1 | NotFound++ | / (3 files): |
| 11:20 |
|
dalek |
winxed: Merge pull request #4 from Whiteknight/multi_syntax |
| 11:20 |
|
dalek |
winxed: |
| 11:20 |
|
dalek |
winxed: Multi functions and methods |
| 11:20 |
|
dalek |
winxed: review: https://github.com/NotFound/wi[…]commit/6f516b1e68 |
| 11:20 |
|
cotto |
looks like someone's waking up |
| 11:27 |
|
cotto |
seen not_gerd |
| 11:27 |
|
aloha |
not_gerd was last seen in #parrot 2 days 21 hours ago saying "looks good to me". |
| 11:33 |
|
dalek |
winxed: c6ac75c | NotFound++ | winxedst1.winxed: |
| 11:33 |
|
dalek |
winxed: work around stage 1 limitations to allow multi tests pass with make test1 |
| 11:33 |
|
dalek |
winxed: review: https://github.com/NotFound/wi[…]commit/c6ac75c79d |
| 11:49 |
|
|
JimmyZ joined #parrot |
| 11:55 |
|
dalek |
winxed: 8f25134 | NotFound++ | winxedst1.winxed: |
| 11:55 |
|
dalek |
winxed: use separate methods to get and set the is_multi flag, and recognize multi declarations on reopened namespaces |
| 11:55 |
|
dalek |
winxed: review: https://github.com/NotFound/wi[…]commit/8f25134dee |
| 12:03 |
|
|
whiteknight joined #parrot |
| 12:04 |
|
whiteknight |
good morning, #parrot |
| 12:05 |
|
dalek |
winxed: 2cd7e1a | NotFound++ | t/advanced/10multi.t: |
| 12:05 |
|
dalek |
winxed: tests for multi in reopened namespace |
| 12:05 |
|
dalek |
winxed: review: https://github.com/NotFound/wi[…]commit/2cd7e1a001 |
| 12:05 |
|
cotto |
hi whiteknight |
| 12:05 |
|
NotFound |
whiteknight: I've merged the multi push request and fixed a few things. |
| 12:10 |
|
lucian |
bah, so if i want to participate in a boolean context i must implement get_integer ?! |
| 12:11 |
|
lucian |
what's get_bool for, then |
| 12:11 |
|
* lucian |
think it's that same problem again |
| 12:12 |
|
whiteknight |
NotFound++ |
| 12:12 |
|
NotFound |
lucian: the problem lies in the "boolean context". |
| 12:12 |
|
whiteknight |
NotFound: How was your fiesta? |
| 12:13 |
|
lucian |
NotFound: yes, i remember |
| 12:13 |
|
lucian |
very annoyin |
| 12:13 |
|
NotFound |
whiteknight: good, seeing old friedns, eating, drinking, dancing... |
| 12:13 |
|
whiteknight |
NotFound: Sounds like a lot of fun |
| 12:14 |
|
NotFound |
And wearing a Mazinger-Z t-shirt X-) |
| 12:16 |
|
NotFound |
lucian: in winxed you can use the ? operator to force a boolean context: (a ? 1 : 0) |
| 12:16 |
|
lucian |
NotFound: yeah, i realise. the problem is that many other functions expect ints |
| 12:16 |
|
lucian |
like Rosella.Test's assert.is_equal |
| 12:17 |
|
whiteknight |
yeah, that's a limitation of Parrot |
| 12:17 |
|
lucian |
very annoying |
| 12:17 |
|
whiteknight |
why would anybody ever need to use a boolean outside of a normal integer? |
| 12:18 |
|
lucian |
because it's semantically correct |
| 12:18 |
|
NotFound |
We don't have a native boolean type so we can't provide a box/unbox mechanic that do the right thing. |
| 12:19 |
|
lucian |
NotFound: exactly. let's have one |
| 12:20 |
|
lucian |
i guess i'll use the ? : workaround in tests for now |
| 12:20 |
|
whiteknight |
We do have a Boolean PMC type, although I always feel like it's pretty heavy-weight to hold a single bit |
| 12:20 |
|
NotFound |
lucian: I don't oppose the idea. Can you create an RFC ticket for it? |
| 12:21 |
|
lucian |
NotFound: in trac? |
| 12:21 |
|
NotFound |
lucian: yes |
| 12:21 |
|
lucian |
ok, i'll put it in the todo list |
| 12:21 |
|
lucian |
whiteknight: that shouldn't be a problem, if everything actually used it |
| 12:22 |
|
NotFound |
Even if it gets rejected, it may help to clarify when get_bool should be used. |
| 12:22 |
|
* lucian |
thinks all types should be boxed, let the JIT unbox things |
| 12:22 |
|
whiteknight |
lucian: Yeah, I know |
| 12:22 |
|
whiteknight |
We had talked a long time ago about having a get_bool and set_bool opcodes, as wrappers around the vtables of the same name |
| 12:23 |
|
whiteknight |
If we did that, we could cut out a hell of a lot of stupid jump opcodes. |
| 12:23 |
|
NotFound |
I know, but a ticket is better than isolated talks. |
| 12:24 |
|
whiteknight |
yes |
| 12:24 |
|
whiteknight |
ticket++ |
| 12:24 |
|
cotto |
+1 |
| 12:25 |
|
lucian |
campaign name suggestions? |
| 12:26 |
|
lucian |
to put on the ticket |
| 12:32 |
|
whiteknight |
? |
| 12:33 |
|
lucian |
whiteknight: ticket name |
| 12:36 |
|
whiteknight |
oh, whatever. It's not important |
| 12:36 |
|
whiteknight |
if it's bad, it can be changed |
| 12:37 |
|
lucian |
http://trac.parrot.org/parrot/ticket/2178 |
| 12:38 |
|
whiteknight |
lucian++ |
| 12:42 |
|
|
bluescreen joined #parrot |
| 12:44 |
|
lucian |
NotFound: i think i have a feature request for winxed |
| 12:45 |
|
lucian |
NotFound: i have a lot of code like "if(exists foo['bar']){ var bar = foo['bar'] ... }" |
| 12:46 |
|
lucian |
something like if-let would help, a conditional binding |
| 12:46 |
|
lucian |
or maybe something like Groovy's/CoffeeScript's soaking operator ?. |
| 12:48 |
|
whiteknight |
lucian: I'm not familiar with if-let. example syntax? |
| 12:49 |
|
lucian |
whiteknight: http://clojuredocs.org/clojure[…]ojure.core/if-let |
| 12:49 |
|
|
darbelo joined #parrot |
| 12:50 |
|
lucian |
in particular http://clojuredocs.org/clojure[…]f-let#example_165 |
| 12:50 |
|
whiteknight |
bleh. I hate S-expressiony syntax |
| 12:50 |
|
lucian |
whiteknight: :P |
| 12:51 |
|
whiteknight |
okay, can you give me an example of what you think it should look like in winxeD? |
| 12:51 |
|
lucian |
if(var a = foo['bar']) |
| 12:51 |
|
lucian |
but that's a little evil |
| 12:52 |
|
dalek |
TT #2178 created by lucian++: Parrot lacks a boolean type |
| 12:52 |
|
dalek |
TT #2178 : http://trac.parrot.org/parrot/ticket/2178 |
| 12:52 |
|
lucian |
?. is less general |
| 12:52 |
|
lucian |
so intead of foo.bar.baz |
| 12:52 |
|
lucian |
you could do foo?.bar?.baz |
| 12:52 |
|
whiteknight |
like a defined-or operator? |
| 12:52 |
|
lucian |
and if bar didn't exist, or baz didn't exist, the entire expression would return null |
| 12:52 |
|
lucian |
whiteknight: yes, sort of |
| 12:53 |
|
whiteknight |
var a = foo['bar'] defined-or "def"; |
| 12:53 |
|
lucian |
var a = foo['bar'] ?or "def"; |
| 12:54 |
|
lucian |
the closest to winxed syntax is the coffeescript feature |
| 12:54 |
|
NotFound |
You mean the equivalent of: (exists foo["bar"] ? foo["bar"] : null) |
| 12:55 |
|
lucian |
http://jashkenas.github.com/coffee-script/ search for "Existential operator" |
| 12:56 |
|
lucian |
NotFound: yes, sort of. but without repeating foo['bar'] ideally |
| 12:56 |
|
NotFound |
Sounds useful, but I don't know how easy can be to chain it. |
| 12:56 |
|
lucian |
me neither, at least not on hashes |
| 12:56 |
|
lucian |
maybe foo?['bar'] |
| 12:56 |
|
lucian |
and foo?.bar for attributes |
| 12:58 |
|
whiteknight |
parsing that is going to conflict with the current ? syntax |
| 12:59 |
|
whiteknight |
or, we would have to add a bunch of new operators, '?[', '?.', etc |
| 12:59 |
|
NotFound |
A possible way is to use the ? : operator omiting the second operand, but I'm not sure about its readability, |
| 12:59 |
|
|
cotto joined #parrot |
| 13:00 |
|
whiteknight |
yeah |
| 13:00 |
|
NotFound |
foo["bar"] ? : null |
| 13:00 |
|
whiteknight |
that seems...tricky |
| 13:01 |
|
NotFound |
Yes, and its parsing can be ambiguous. |
| 13:01 |
|
lucian |
seems confusing |
| 13:01 |
|
lucian |
i like adding ?[ and ?. operators |
| 13:02 |
|
lucian |
so "foo?['bar']" would be sugar for "exists foo['bar'] ? foo['bar'] : null" |
| 13:02 |
|
NotFound |
That will conflict with the ? operator. Maybe [? and .? |
| 13:03 |
|
lucian |
wouldn't that conflict with [ true ? 1 : 0 ] |
| 13:04 |
|
lucian |
also, it might be advantageous to have similar syntax with other js-like languages (CS and Groovy) |
| 13:04 |
|
NotFound |
Note that for attributes the thing is not so easy, it must catch an exception. |
| 13:04 |
|
lucian |
yes, i realise |
| 13:04 |
|
lucian |
i've yet to feel a need for it on operators |
| 13:05 |
|
NotFound |
No, [? and .? currently are syntax errors, the ? operator needs an operand. |
| 13:05 |
|
lucian |
right |
| 13:06 |
|
lucian |
do hashes have a method for silently failing |
| 13:06 |
|
lucian |
? |
| 13:06 |
|
NotFound |
exists |
| 13:07 |
|
lucian |
i mean a getter that silently fails |
| 13:08 |
|
NotFound |
lucian: that depends on what the PMC does and what you need to know. exists can be true if the value is null. |
| 13:08 |
|
lucian |
hmm |
| 13:08 |
|
NotFound |
And hashes can return a null pmc for both cases. |
| 13:09 |
|
NotFound |
Non existent, or set to null. |
| 13:10 |
|
|
Tene joined #parrot |
| 13:13 |
|
lucian |
NotFound: it might be useful to show you the ugly code https://github.com/lucian1900/[…]c/type.winxed#L92 |
| 13:19 |
|
|
darbelo joined #parrot |
| 13:22 |
|
NotFound |
lucian: that cases seems to be a bit more complicated than exists-or-null |
| 13:23 |
|
lucian |
it is, indeed |
| 13:24 |
|
lucian |
but bind-if-exists would help |
| 13:26 |
|
|
ambs joined #parrot |
| 13:26 |
|
|
baest joined #parrot |
| 13:27 |
|
Coke |
Anyone want to take a stab at fixing the release process on os x before I get off work today and do the release? ;) |
| 13:31 |
|
cotto |
Coke, I have a concern. parrot_debugger --help segfaults pretty reliably and I don't feel good about letting that escape. |
| 13:31 |
|
cotto |
that said, it did the same thing in 3.6.0 |
| 13:31 |
|
Coke |
cotto: ok. I don't have time to fix it, but you have several hours before I get to a point where I can cut a release today. |
| 13:32 |
|
Coke |
(one of the reasons I wanted to do this @midnight. ah well) |
| 13:32 |
|
cotto |
Coke, ok |
| 13:34 |
|
NotFound |
Coke: It's fine to update the winxed snapshot? |
| 13:34 |
|
Coke |
NotFound: I have no idea what sort of support implications that has, if any. so, go for it? |
| 13:35 |
|
NotFound |
I'll go. |
| 13:35 |
|
* lucian |
loves the winxed snapshot |
| 13:35 |
|
lucian |
it makes boostrapping puffin from scatch last a good 5mins less |
| 13:35 |
|
lucian |
or maybe more |
| 13:36 |
|
cotto |
awesome. It's trying to treat --help as a file |
| 13:37 |
|
cotto |
why are we shipping this? |
| 13:38 |
|
Coke |
cotto - just remove it from the install target. |
| 13:38 |
|
cotto |
I'll do that. |
| 13:39 |
|
Coke |
(also, please add a note to NEWS) |
| 13:39 |
|
cotto |
that too |
| 13:39 |
|
dalek |
TT #2179 created by "mzoppet@…>++: Bug in setup-parrot-3.6.0.exe broke PATH |
| 13:39 |
|
dalek |
TT #2179 : http://trac.parrot.org/parrot/ticket/2179 |
| 13:39 |
|
Coke |
NotFound: ditto, please update news mentioning the new winxed version #. |
| 13:40 |
|
Coke |
who generated a windows installer for parrot? |
| 13:40 |
|
Coke |
fperrad? |
| 13:40 |
|
cotto |
trac-- |
| 13:40 |
|
cotto |
trac-- |
| 13:40 |
|
cotto |
trac-- |
| 13:41 |
|
cotto |
though at least the information is there |
| 13:44 |
|
cotto |
dukeleto, ping |
| 13:44 |
|
cotto |
I should run parrot_debugger's removal by him first. |
| 13:44 |
|
atrodo |
=~ |
| 13:45 |
|
cotto |
hio atrodo |
| 13:45 |
|
atrodo |
Good, well, i assume it's evening for you cotto? |
| 13:46 |
|
cotto |
atrodo, you assume correctly |
| 13:46 |
|
cotto |
it feels wrong being in a timezone so different from most Parrot hackers |
| 13:46 |
|
atrodo |
YAPC::EU going well? |
| 13:46 |
|
cotto |
quite. lots of facetime with rakudo hackers |
| 13:47 |
|
cotto |
finally getting to meet jnthn and masak |
| 13:48 |
|
cotto |
riga is charming |
| 13:48 |
|
atrodo |
Sounds like a good time. Get much hacking in? |
| 13:49 |
|
cotto |
more thinking than hacking, but lots of that. good feedback on m0 too |
| 13:49 |
|
dalek |
winxed: 747b557 | NotFound++ | / (2 files): |
| 13:49 |
|
dalek |
winxed: update NEWS and set version to 1.1.0 |
| 13:49 |
|
dalek |
winxed: review: https://github.com/NotFound/wi[…]commit/747b557e6b |
| 13:50 |
|
whiteknight |
NotFound++ |
| 13:51 |
|
whiteknight |
oh, I'm very happy that the multi patch is going to be in this release. Rosella will be able to make immediate use of it |
| 13:51 |
|
cotto |
seen dukeleto |
| 13:51 |
|
aloha |
dukeleto was last seen in #parrot 1 days 20 hours ago saying "endeavormac: they seem "unlimited", but of course, you will eventually not be able to store any more due to memory constraints". |
| 13:52 |
|
cotto |
whiteknight, care to offer a second opinion on parrot_debugger? |
| 13:52 |
|
cotto |
it segfaults when you pass --help, and has done so since at least 3.6.0 |
| 13:53 |
|
cotto |
I'm tempted to remove it on that basis, though it looks like it does that because it does excessively simple option parsing |
| 13:53 |
|
cotto |
*remove it from the install |
| 13:55 |
|
whiteknight |
of course remove it. Does it do anything useful? Is it workable? Does it provide anything that users are relying on? |
| 13:55 |
|
whiteknight |
if the answer to all those questions is "no", kill it |
| 13:56 |
|
cotto |
I hope not. |
| 13:56 |
|
whiteknight |
and do a little victory dance. |
| 13:56 |
|
cotto |
either way, it's easily reversible |
| 13:56 |
|
whiteknight |
yeah |
| 13:56 |
|
whiteknight |
my forcast: deleting, with a chance of awesome |
| 13:57 |
|
atrodo |
what about just deleting it for release, save the final decision for a less crunched time? |
| 13:57 |
|
cotto |
too late |
| 13:57 |
|
dalek |
parrot: 73135c5 | cotto++ | / (2 files): |
| 13:57 |
|
dalek |
parrot: don't install parrot_debugger |
| 13:57 |
|
dalek |
parrot: |
| 13:57 |
|
dalek |
parrot: it may work, but segfaulting on --help is a non-starter |
| 13:57 |
|
dalek |
parrot: review: https://github.com/parrot/parr[…]commit/73135c53c4 |
| 13:57 |
|
* cotto |
goes afk to learn about Go |
| 13:59 |
|
lucian |
cotto: on Go, i found this useful http://www.syntax-k.de/projekte/go-review |
| 14:00 |
|
dalek |
winxed/version_1_1: fd223f9 | NotFound++ | pir/winxed_compiler.pir: |
| 14:00 |
|
dalek |
winxed/version_1_1: update installable compiler |
| 14:00 |
|
dalek |
winxed/version_1_1: review: https://github.com/NotFound/wi[…]commit/fd223f9305 |
| 14:08 |
|
dalek |
parrot: e4ff789 | NotFound++ | / (2 files): |
| 14:08 |
|
dalek |
parrot: update winxed snapshot to 1.1.0 and add its news |
| 14:09 |
|
dalek |
parrot: review: https://github.com/parrot/parr[…]commit/e4ff789141 |
| 14:11 |
|
cotto |
lucian, very |
| 14:18 |
|
lucian |
yay for DRY |
| 14:20 |
|
ttbot |
Parrot 73135c53 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/44650 |
| 14:21 |
|
whiteknight |
FFFFUUUUUU |
| 14:21 |
|
whiteknight |
win32-- |
| 14:22 |
|
whiteknight |
let me fire up the build now |
| 14:22 |
|
cotto |
it did the same thing after I made a pod change in a non-code file earlier today |
| 14:22 |
|
cotto |
whiteknight++ |
| 14:23 |
|
whiteknight |
"syntax error at config/auto/arch.pmc line 115, near ')'" |
| 14:23 |
|
whiteknight |
so that's not good |
| 14:23 |
|
whiteknight |
"syntax error at config/auto/arch.pmc line 115, near '}'" |
| 14:23 |
|
whiteknight |
sorry |
| 14:23 |
|
whiteknight |
config/auto/arch.pm has too many errors |
| 14:23 |
|
whiteknight |
so there's the problem |
| 14:24 |
|
whiteknight |
http://software.intel.com/en-u[…]he-time-has-come/ |
| 14:26 |
|
cotto |
whiteknight, so Configure.pl fails but the build proceeds anyway? |
| 14:26 |
|
whiteknight |
it's not building here |
| 14:26 |
|
whiteknight |
configure fails, that's it |
| 14:27 |
|
whiteknight |
hold on, let me try something else |
| 14:27 |
|
whiteknight |
oh wait, I think I had a messed up local setting. It's building now |
| 14:27 |
|
cotto |
looks like removing parrot_debugger from the install didn't cause any surprises |
| 14:28 |
|
cotto |
sounds like progress |
| 14:28 |
|
whiteknight |
progress++ |
| 14:28 |
|
cotto |
(boring releases)++ |
| 14:31 |
|
whiteknight |
NotFound: ping |
| 14:31 |
|
cotto |
allison, ping |
| 14:32 |
|
whiteknight |
everybody: ping |
| 14:32 |
|
allison |
cotto: pong |
| 14:32 |
|
cotto |
allison, Parrot's gradually moved from thinking of itself as being close to hardware to being more abstract. |
| 14:32 |
|
cotto |
I'm thinking about moving back toward hardware with M0 and would like to make sure that I'm not going down the same road we've already been down. |
| 14:33 |
|
allison |
cotto: the thing to watch out for is portability |
| 14:33 |
|
cotto |
I'm looking to reduce the impedance mismatch between M0 and hardware so that the generated code will be easier to make efficient. |
| 14:33 |
|
allison |
cotto: M0 shouldn't be too closely tied to any one architecture |
| 14:33 |
|
cotto |
a minimalist instruction set guarantees that we'll be generate poor code without an optimizer, which isn't optimal |
| 14:34 |
|
allison |
but, on the other hand, since M0 is tiny, it makes it much, much easier to port |
| 14:34 |
|
cotto |
allison, absolutely |
| 14:34 |
|
allison |
so, it's totally possible to have some parts that are closely tied to one architecture |
| 14:34 |
|
allison |
the Linux Kernel is a good model here |
| 14:34 |
|
cotto |
yes |
| 14:34 |
|
cotto |
that's definitely part of the charm of a small VM |
| 14:34 |
|
allison |
they make a clear distinction between the "general" parts and the "architecture dependent" parts |
| 14:35 |
|
allison |
(even to the point of segmenting off architecture-dependent directories |
| 14:35 |
|
allison |
What you don't want is a confused mish-mash of what is or isn't architecture-dependent |
| 14:35 |
|
lucian |
allison: the point here is that if M0 is too small, certain constructs will have to be composed, when they might be already existent on most platforms natively |
| 14:35 |
|
cotto |
I'd been thinking of separate interpreters, but that's a good way to do it. |
| 14:36 |
|
cotto |
lucian, yes |
| 14:36 |
|
allison |
so, if a component is architecture dependent, it is segmented off and customized for all architectures |
| 14:36 |
|
lucian |
so all modern archs have vector units |
| 14:36 |
|
allison |
lucian: right, it should be totally allowed to have an M0 op be "straight to native" on some platforms |
| 14:36 |
|
lucian |
but M0 has nothing to support that |
| 14:37 |
|
|
darbelo joined #parrot |
| 14:37 |
|
whiteknight |
If M0 is the common lowest-level language, what we need are platform-dependent optimizers and platform-specific JIT |
| 14:37 |
|
whiteknight |
in addition to maybe a suite a higher-level optimizations which can operate irregardless of platform |
| 14:37 |
|
allison |
but, we also want to steer clear of the pain of the old JIT, that involved hand-crafting a huge number of statements for each architecture |
| 14:38 |
|
lucian |
whiteknight: it seems to me that interesting platforms already have a similar set of features. so platform-specific (non-peephole) optimisers shouldn't be necessary |
| 14:38 |
|
allison |
(again, the beauty of the small op set in M0) |
| 14:39 |
|
cotto |
allison, can you shed some light on Parrot's move away from thinking as itself as close to hardware to more abstract |
| 14:39 |
|
whiteknight |
lucian: Right, that's what I'm talking about. Platform-specific peephole optimizers, mostly |
| 14:39 |
|
allison |
cotto: I'm not sure it ever did think of itself as truly close to the hardware |
| 14:39 |
|
allison |
cotto: its background is in interpreters like Perl |
| 14:39 |
|
cotto |
allison, ok. |
| 14:39 |
|
dukeleto |
we already deleted a platform-specific JIT. Some parts of a JIT can be platform specific, but maintaining platform-specific JIT opcodes again is not a goal we should have |
| 14:40 |
|
allison |
cotto: it has certainly been inspired by hardware models all along (register-based, etc) |
| 14:40 |
|
cotto |
allison, definitely yes wrt a small op set. Still, even 100 is reasonable. |
| 14:40 |
|
lucian |
whiteknight: and any existing jit framework has peepholes already written |
| 14:40 |
|
whiteknight |
every JIT has to be tied to the platform in some way. You can generate "general" machine code |
| 14:40 |
|
whiteknight |
can't |
| 14:41 |
|
lucian |
whiteknight: except when it can, i.e. llvm ir, nanojit ir |
| 14:41 |
|
whiteknight |
if we want to avoid writing platform-specific JIT code, we need to use an existing JIT that somebody else went through the pain of writing |
| 14:41 |
|
ttbot |
Parrot e4ff7891 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/44667 |
| 14:41 |
|
lucian |
the way i see it, a goal for M0 should be straightforward, efficient mapping to at least LLVM IR |
| 14:41 |
|
allison |
whiteknight: indeed, but you can compose JIT code for macro-level ops from JIT code for M0 ops |
| 14:41 |
|
|
JimmyZ joined #parrot |
| 14:41 |
|
whiteknight |
there will be pain, the question is how little of it we take upon ourselves |
| 14:41 |
|
allison |
whiteknight: which radically reduces the effort of JITting on a new platform |
| 14:42 |
|
allison |
whiteknight: what our previous JIT proved to us is that we can't rely on anyone else to do the porting either |
| 14:42 |
|
allison |
whiteknight: so, it's either ourselves, or no one |
| 14:42 |
|
lucian |
allison: but that's a pasting jit, and it sort of sucks :) |
| 14:43 |
|
allison |
lucian: it's better than no JIT :) |
| 14:43 |
|
cotto |
I'd like to see different backends that use e.g. llvm, gnu lightning, etc. cpu-specific code is definitely out |
| 14:43 |
|
allison |
lucian: and more can be built on top of it |
| 14:43 |
|
whiteknight |
What sucked most about our previous JIT was maintainability. Every time we added a new op, or changed an existing op, we needed to recreate the exact same changes in several files for several platforms |
| 14:43 |
|
lucian |
cotto: i don't think that's a realistic goal |
| 14:43 |
|
dukeleto |
firefox uses both nanojit and nitro, for tracing and method-based JITting. It chooses between them via heuristics about hot code |
| 14:43 |
|
whiteknight |
and when you have 1300+ ops and variants, that's a nightmare |
| 14:43 |
|
cotto |
whiteknight, yes. If we can keep m0 mostly static, much pain goes away. |
| 14:44 |
|
allison |
whiteknight: yup, 1300+ is unworkable for manual JITting |
| 14:44 |
|
lucian |
dukeleto: yes, it defaults to tracing (with nanojit) and uses method-jit (nitro) for generally hot methods |
| 14:44 |
|
allison |
whiteknight: also, our previous JIT wasn't actually "just-in-time" |
| 14:44 |
|
lucian |
dukeleto: with a slightly different approach it's possible to use only tracing (what PyPy do) |
| 14:44 |
|
whiteknight |
What we need in a JIT is all the bells and whistles: We need optimizations, tracing, type specialization, and other details. We would never have gotten there with the old architecture |
| 14:44 |
|
allison |
whiteknight: it was pre-compiled |
| 14:45 |
|
whiteknight |
a JIT that doesn't do aggressive type-specialization is worthless in the modern world |
| 14:45 |
|
dukeleto |
and spidermonkey (the main javascript vm for firefox) has something call interpolines (interpreter trampolines) which are tiny bits of platform-specific code (possibly assembly). I am still trying to fully understand it, but it seems to be the only platform-specific part of spidermonkey |
| 14:46 |
|
cotto |
whiteknight, eventually, yes. We can still get meaningful performance just by using a dumb jit. |
| 14:46 |
|
dukeleto |
whiteknight: the mozilla people call it "type inference" and have been breaking new ground in that area. They are doing *static* type inference for Javascript, which is kind of amazing. |
| 14:46 |
|
whiteknight |
cotto: all a dumb JIT is going to do is reduce op dispatch costs |
| 14:46 |
|
lucian |
whiteknight: the effort of writing a good JIT may dwarf the effort of supporting x86, x86-64 and ARM (the only relevant platforms) |
| 14:46 |
|
lucian |
v8 and PyPy have certainly gone that route |
| 14:46 |
|
cotto |
whiteknight, which will be meaningful for small ops |
| 14:46 |
|
whiteknight |
lucian: right. That's why I think that our best bet is still to use an existing JIT |
| 14:47 |
|
cotto |
allison, thanks |
| 14:47 |
|
whiteknight |
Compare how many coders we could devote 100% to a complete in-house JIT infrastructure, against how many coders Mozilla can throw at the problem, or LLVM |
| 14:47 |
|
lucian |
whiteknight: sure, if possible. but i've yet to see a successful project use an off-the-shelf jit |
| 14:47 |
|
allison |
cotto: anytime, and thanks for thinking of it |
| 14:47 |
|
whiteknight |
lucian: if we devote two coders, some of the time, to brewing our own, it will not be successful either |
| 14:47 |
|
dukeleto |
from what I can see in Firefox, they have easily spent dozens to hundreds of dev-years already on their JITs, and they didn't develop it from scratch. They built on existing tech (nanojit and nitro) |
| 14:48 |
|
lucian |
whiteknight: of course, which is why we should choose two platforms and try |
| 14:48 |
|
whiteknight |
and that's two coders without any distractions, without a deprecation policy in the way, and without real life botching the schedule |
| 14:48 |
|
dukeleto |
whiteknight: indeed. Writing our own JIT from scratch is just a non-starter |
| 14:48 |
|
allison |
someone recently asked me if v8 JIT could be split out as a reusable library for Parrot |
| 14:48 |
|
whiteknight |
lucian: I don't care if it's two or whatever. We do have to start from somewhere |
| 14:48 |
|
allison |
I don't know |
| 14:48 |
|
lucian |
allison: no |
| 14:48 |
|
dukeleto |
allison: the v8 JIT is very specialized to Javascript |
| 14:48 |
|
atrodo |
allison> I was hoping for a better answer |
| 14:48 |
|
whiteknight |
allison: I've looked at v8 before. I think it's too JS dependent |
| 14:48 |
|
lucian |
allison: others have asked before, it's not realistic |
| 14:49 |
|
allison |
on the whole, I think we'll be doing well to support a few existing JIT libraries |
| 14:49 |
|
allison |
and see what works best |
| 14:49 |
|
lucian |
allison: to me, that seems about as hard as supporting a few archs |
| 14:49 |
|
whiteknight |
We have to pick one to start with, and I think we've already made a good decision with LLVM |
| 14:49 |
|
atrodo |
allison> However, if, in a magical world, m0 existed on as a JS backend, that could be |
| 14:49 |
|
cotto |
rolling our own is a non-starter. I hope no one thinks I'm suggesting that. |
| 14:49 |
|
lucian |
all we'll get from a JIT library is cross-platform IR and a peephole optimiser |
| 14:49 |
|
dukeleto |
whiteknight: have we? do we really do much with LLVM yet? |
| 14:50 |
|
lucian |
whiteknight: uh, everyone who's tried llvm has failed so far |
| 14:50 |
|
allison |
atrodo: Parrot already has several JS implementations, so yes, one possible use case would be v8 as a JIT backend for Parrot *only* with JS |
| 14:50 |
|
whiteknight |
dukeleto: We don't do anything with LLVM yet, but it's as good an option as any. It's maintained, and it's not hopelessly tied to a particular language or semantic |
| 14:50 |
|
lucian |
whiteknight: it's just very, very bad |
| 14:50 |
|
cotto |
lucian, great. We can learn from them. |
| 14:50 |
|
allison |
whiteknight: well, LLVM as a static compiler is well maintained |
| 14:50 |
|
lucian |
whiteknight: and it is hopelessly tied to C semantics |
| 14:50 |
|
lucian |
allison: indeed. and jus tthat |
| 14:50 |
|
whiteknight |
Parrot is written in C |
| 14:50 |
|
allison |
whiteknight: LLVM as a JIT is not, which the unladen-swallow guys definitely proved |
| 14:51 |
|
atrodo |
allison> I think you misunderstood. Imagine a m0 interp written in js |
| 14:51 |
|
lucian |
both PyPy and unladen swallow have shown that LLVM sucks for JITs, and is very buggy on top |
| 14:51 |
|
cotto |
atrodo, I have been. |
| 14:51 |
|
allison |
whiteknight: (they also improved it, but it has a lot of work needed) |
| 14:51 |
|
whiteknight |
so then what are the alternatives? We need at least one JIT, if we plan to support more than one |
| 14:51 |
|
lucian |
whiteknight: right, but HLLs aren't C |
| 14:51 |
|
whiteknight |
the one is where we need to start |
| 14:51 |
|
allison |
atrodo: I try to take JS as a backend language seriously, but I just can't |
| 14:51 |
|
lucian |
rubinius are having moderate success with llvm |
| 14:51 |
|
whiteknight |
so what's the first one? v8 and most of the current-gen JS ones are out |
| 14:51 |
|
lucian |
but they're only using it for assembly |
| 14:51 |
|
lucian |
they do their own optimisations |
| 14:52 |
|
whiteknight |
LLVM is apparently not popular |
| 14:52 |
|
allison |
atrodo: no matter how good the VM gets, the language itself is for writing web pages |
| 14:52 |
|
allison |
atrodo: not a good general-purpose language |
| 14:52 |
|
lucian |
allison: i'd dispute that |
| 14:52 |
|
lucian |
allison: but hijacking v8 is probably a bad idea |
| 14:52 |
|
allison |
lucian: it's not just a predjudice on my part, I've been a JS developer almost from the start of the language |
| 14:52 |
|
lucian |
i see a few platforms to target: llvm, nanojit, lightning, x86, ARM |
| 14:53 |
|
whiteknight |
lucian: So pick one to start with |
| 14:53 |
|
allison |
lucian: languages have domains where they're well suited, and domains where they're poorly suited |
| 14:53 |
|
whiteknight |
we're not going to write a 5-way JIT subsystem to start out with |
| 14:53 |
|
lucian |
allison: it's still much better than many languages people use nowadays |
| 14:53 |
|
atrodo |
allison> if you had asked me a year or two ago, i would have agreed. and then this: http://imrannazar.com/GameBoy-[…]ion-in-JavaScript |
| 14:53 |
|
lucian |
whiteknight: of course not. two-way at most for prototyping, i would guess |
| 14:53 |
|
allison |
lucian: I take it a bit like Java. The VM is state-of-the art, with amazing features that are still poorly exposed in the Java syntax |
| 14:53 |
|
whiteknight |
lucian: okay, so pick two |
| 14:54 |
|
lucian |
whiteknight: x86 and ARM, or llvm and nanojit |
| 14:54 |
|
allison |
atrodo: sure, it's turing complete, and you can implement anything in a turing complete language |
| 14:54 |
|
cotto |
lucian, are you suggesting cpu-specific code, and who'd maintain it? |
| 14:54 |
|
allison |
atrodo: you can implement anything in assembly language |
| 14:54 |
|
whiteknight |
lucian: when you say x86 and arm, what do you mean? Writing our own JIT for those? |
| 14:54 |
|
lucian |
cotto: whoever'd maintain the llvm backend |
| 14:54 |
|
lucian |
whiteknight: yep |
| 14:54 |
|
cotto |
lucian, ok |
| 14:55 |
|
lucian |
there are only two relevant CPUs: x86 and ARM |
| 14:55 |
|
allison |
atrodo: that doesn't mean it's well adapted for ease of use, maintainability, or high-quality code for that domain |
| 14:55 |
|
lucian |
it's likely about as much effort as dealing with llvm, on the whole |
| 14:55 |
|
allison |
drat, meeting, and this is an interesting conversation :) |
| 14:55 |
|
allison |
later all |
| 14:55 |
|
cotto |
actually, the important thing is to get M0 defined. if you want to go nuts and write a pure x86_64 jitting interpreter, that's fine. ;) |
| 14:55 |
|
* lucian |
waves |
| 14:55 |
|
atrodo |
allison> I agree. But it makes it possible in my mind. Maybe not ideal or anything, but reasonably possible |
| 14:55 |
|
cotto |
allison, thanks for dropping by |
| 14:56 |
|
lucian |
cotto: of course. as long as M0 is not lower level than x86 or ARM |
| 14:56 |
|
cotto |
lucian, that'd be difficult |
| 14:56 |
|
lucian |
cotto: how so? |
| 14:57 |
|
cotto |
x86 is pretty low-level |
| 14:57 |
|
lucian |
if it's lower level that the platforms it targets, how will it ever be efficient? |
| 14:57 |
|
lucian |
cotto: nvm, misread |
| 14:57 |
|
lucian |
so if M0 has everything that x86 and ARM have in common, and is not lower level than either one, it's fine |
| 14:57 |
|
* cotto |
gets deconfused |
| 14:57 |
|
whiteknight |
broad-spectrum optimizations are going to be happening at higher levels. HLL compilers will optimize, and PCT will optimize. Once we get down to the PIR/M0 level, what's left are peephole optimizations |
| 14:57 |
|
lucian |
may want to add LLVM IR and nanojit IR there |
| 14:58 |
|
lucian |
whiteknight: exactly |
| 14:58 |
|
lucian |
whiteknight: also, there will have to be a parrot-specific JIT bit |
| 14:58 |
|
whiteknight |
we don't need a JIT to be doing huge, broad optimizations. We need a JIT that does basic peephole optimizations and can emit basic platform-specific machine code |
| 14:58 |
|
cotto |
yes |
| 14:58 |
|
atrodo |
cotto> This is where I think composed ops could help. You'd end up with a JITable code, but if a platform understands a particular composed op, it can optimize it further |
| 14:58 |
|
whiteknight |
so if LLVM's optimizations are unsuitable for dynamic languages, that doesn't impact parrot at all |
| 14:58 |
|
whiteknight |
we wouldn't use them anyway |
| 14:58 |
|
atrodo |
platform = platform or jit engine |
| 14:59 |
|
whiteknight |
So, ignoring all that crap, we need a JIT backend library that can generate machine code for our target platforms |
| 14:59 |
|
whiteknight |
We can do tracing and type-specializations in Parrot |
| 14:59 |
|
lucian |
atrodo: that sounds useful |
| 15:00 |
|
lucian |
atrodo: but i don't think it's too relevant. x86, ARM and LLVM IR are *very* similar |
| 15:00 |
|
whiteknight |
broad optimizations at the HLL and PCT levels, type-specialization and tracing at the parrot level to generate an M0 stream, and a JIt backend to do M0->machine code |
| 15:00 |
|
lucian |
rather, the sane subset of x86 that everyone uses |
| 15:01 |
|
whiteknight |
If M0 ops are fixed-width, tracing can actually become extremely easy |
| 15:01 |
|
lucian |
whiteknight: my point about llvm is that it's only marginally better than generating C, compiling and linking at runtime |
| 15:01 |
|
cotto |
and generated C can be pretty heavily optimized |
| 15:01 |
|
whiteknight |
lucian: So what? For a first JIT system it doesn't need to be fantastic |
| 15:01 |
|
whiteknight |
Put together the prototype, build a suitable abstract interface around it, replace the backend with something better |
| 15:01 |
|
lucian |
whiteknight: sure. but you end up having to deal with llvm, which is huge and buggy |
| 15:02 |
|
whiteknight |
lucian; and under active development |
| 15:02 |
|
whiteknight |
that's a bit not to be underestimated |
| 15:02 |
|
lucian |
it's been like that for years |
| 15:02 |
|
lucian |
it has only had small improvements for JITs |
| 15:02 |
|
whiteknight |
lucian: that doesn't bother me |
| 15:02 |
|
lucian |
that may of course change |
| 15:03 |
|
whiteknight |
Parrot's object model hasn't had any love for years, but that doesn't mean I'm going to bet against it getting love in the future |
| 15:03 |
|
lucian |
another option could be using an existing vm framework |
| 15:03 |
|
lucian |
whiteknight: right, but parrot's object model is microscopic by comparison |
| 15:03 |
|
cotto |
whiteknight, you'd be wise not to do so ;) |
| 15:03 |
|
lucian |
you may be underestimating just hog mind-bogglingly huge and buggy llvm is |
| 15:04 |
|
lucian |
s/hog/how/ |
| 15:04 |
|
whiteknight |
lucian: and you may be overestimating |
| 15:04 |
|
atrodo |
s/llvm/parrot ;) |
| 15:04 |
|
cotto |
lucian, do you have some blog posts by hackers with scars? |
| 15:04 |
|
whiteknight |
If the Rubinus people are using it, it can't be all bad |
| 15:04 |
|
cotto |
atrodo, enough out of you ;) |
| 15:04 |
|
whiteknight |
The plight of the unladen swallow people is an interesting story, but hardly the law of the land |
| 15:04 |
|
lucian |
cotto: morepypy.blogspot.com, older posts. also rubinius and unladen swallow |
| 15:05 |
|
lucian |
whiteknight: sure, it's doable. just very, very hard. also, rubinius folks like C++ |
| 15:06 |
|
atrodo |
cotto> Sorry, couldn't resist. |
| 15:07 |
|
whiteknight |
What I need is to get email addresses for some of these pypy people and start communicating with them |
| 15:07 |
|
cotto |
+1 |
| 15:07 |
|
lucian |
whiteknight: join freenode#pypy |
| 15:07 |
|
lucian |
if all of parrot is to be rewritten in M0, it could even be done with PyPy itself |
| 15:07 |
|
lucian |
write the VM in RPython, the rest in M0 |
| 15:08 |
|
lucian |
get GC and JIT for free |
| 15:08 |
|
lucian |
but that's likely to be unpopular |
| 15:08 |
|
cotto |
it'd be a hard sell |
| 15:08 |
|
lucian |
when i have time, i'll try writing a M0 interpreter with PyPy |
| 15:08 |
|
cotto |
but we'd have to have a mostly-M0 parrot first anyway |
| 15:08 |
|
lucian |
sure |
| 15:09 |
|
cotto |
lucian, I'd recommend waiting for a bit. I suspect some big changes will be coming down the pipeline |
| 15:09 |
|
cotto |
but I'd like to see it |
| 15:10 |
|
lucian |
not like i have time for it now, anyway :) |
| 15:11 |
|
whiteknight |
If we run on top of another VM, Parrot is no longer a VM in itself. It becomes little more than a runtime library |
| 15:11 |
|
lucian |
whiteknight: no, PyPy is a framework for generating VMs |
| 15:11 |
|
lucian |
you write an interpreter in RPython, and it spits out a VM with a JIT for you |
| 15:11 |
|
lucian |
there's an unfortunate naming clash with pypy, the python interpreter written in RPython |
| 15:12 |
|
lucian |
py.py, rather |
| 15:12 |
|
lucian |
so the fast python vms PyPy has (pypy-c-jit) are generated by translating py.py with the PyPy translation framework to C |
| 15:13 |
|
lucian |
and during translation, interesting aspects are added (GC, JIT) |
| 15:13 |
|
whiteknight |
ok |
| 15:14 |
|
lucian |
in fact, if that perl M0 interpreter had been written in Python instead, we'd almost have it |
| 15:15 |
|
cotto |
and we'd have ctypes |
| 15:15 |
|
cotto |
which would be quite nice |
| 15:15 |
|
lucian |
cotto: there's _rawffi (or _ffi) which is just a libffi binding |
| 15:15 |
|
lucian |
ctypes on PyPy is purely app-level, on top of _rawffi |
| 15:16 |
|
JimmyZ |
Parrot on pypy :) |
| 15:16 |
|
lucian |
anyway, all this requires parrot being M0 |
| 15:16 |
|
lucian |
which i think is a good idea, but isn't the case at all now |
| 15:16 |
|
JimmyZ |
and then Perl 6 on pypy ? |
| 15:16 |
|
cotto |
yeah. It's good to give it some thought, but not in too much detail. |
| 15:16 |
|
lucian |
JimmyZ: sure, why not. it'd be easier to just write a perl6 interpreter directly, in fact |
| 15:17 |
|
lucian |
JimmyZ: it's another cultural thing. rubinius folks would've been much better off using PyPy, but they didn't because it's Python |
| 15:18 |
|
JimmyZ |
language is not problem |
| 15:18 |
|
JimmyZ |
s/not/not a/ |
| 15:19 |
|
lucian |
in some cases, it is |
| 15:19 |
|
JimmyZ |
I think missing coder is a real problem |
| 15:22 |
|
JimmyZ |
it's make me remember what linus said from a email, the creator of linux "talking is cheaper, show me the code" ;) |
| 15:23 |
|
cotto |
time for noms |
| 15:24 |
|
* JimmyZ |
doesn't what noms means, nom branch of rakudo? |
| 15:24 |
|
JimmyZ |
doesn't know |
| 15:24 |
|
dafrito |
JimmyZ, noms is likely eating ;) |
| 15:24 |
|
lucian |
JimmyZ: nom-nom-nom. muching |
| 15:24 |
|
lucian |
s/munching/ |
| 15:26 |
|
JimmyZ |
oh, whenever pmichaud++ said noms, I always thought nom branch of rakudo, which is exciting |
| 15:26 |
|
JimmyZ |
hehe |
| 15:27 |
|
cotto |
#ps is during dinner. I'll try to make it. |
| 15:28 |
|
cotto |
can't say for certain I'll be there though |
| 15:34 |
|
|
Tene joined #parrot |
| 15:36 |
|
whiteknight |
win32 build is definitely broken, and I'm not able to look at it now |
| 15:37 |
|
|
darbelo joined #parrot |
| 15:39 |
|
whiteknight |
wait, it looks like it's going this time |
| 15:40 |
|
whiteknight |
weird, must be a makefile issue |
| 15:42 |
|
|
dmalcolm joined #parrot |
| 15:47 |
|
* JimmyZ |
built parrot successfully with strawberry perl |
| 15:47 |
|
whiteknight |
win32 build, all tests pass |
| 15:47 |
|
lucian |
whiteknight++ |
| 15:48 |
|
whiteknight |
http://smolder.parrot.org/app/[…]ort_details/21141 |
| 15:54 |
|
|
mj41 joined #parrot |
| 16:36 |
|
|
theory joined #parrot |
| 16:45 |
|
dalek |
rakudo/nom: 15ef06f | moritz++ | src/ (2 files): |
| 16:45 |
|
dalek |
rakudo/nom: implement numification of strings like :16<BEEF>, and :16("BEEF") style conversions |
| 16:45 |
|
dalek |
rakudo/nom: |
| 16:45 |
|
dalek |
rakudo/nom: This is only a first rough cut, and does not support a lot of features |
| 16:45 |
|
dalek |
rakudo/nom: review: https://github.com/rakudo/raku[…]commit/15ef06f32c |
| 17:05 |
|
|
jsut_ joined #parrot |
| 17:12 |
|
|
jay joined #parrot |
| 17:15 |
|
whiteknight |
mmmm. beef |
| 17:51 |
|
whiteknight |
http://herbsutter.com/2011/08/[…]imously-approved/ |
| 17:52 |
|
benabik |
C++0xB! |
| 17:52 |
|
lucian |
huh. they still haven't taken things out, have they? |
| 17:53 |
|
whiteknight |
take things....out? |
| 17:53 |
|
whiteknight |
that sentence doesn't parse, in the context of C++ |
| 17:53 |
|
lucian |
even with 7 parsing passes! bam |
| 17:53 |
|
lucian |
thank you, i'll be here all night |
| 17:54 |
|
benabik |
0xB is a significantly improved language. Lambas, auto typing, improved libraries… Now we just have to wait several years for everyone to support it. *sigh* |
| 17:55 |
|
lucian |
benabik: right. but it's still the most gigantic and inconsistent language on earth |
| 17:55 |
|
lucian |
and the new standard is even more gigantic |
| 17:57 |
|
whiteknight |
is it bigger than perl6? |
| 17:57 |
|
lucian |
whiteknight: don't know perl6 in detail, but i'd guess it is |
| 17:57 |
|
benabik |
I personally find it an extremely useful language, that adds a lot of power without adding a ton of overhead. But I also realize I'm in a significant minority. |
| 17:58 |
|
whiteknight |
benabik: where you lose people is in the "without adding a ton of overhead" |
| 17:58 |
|
|
contingencyplan joined #parrot |
| 17:58 |
|
whiteknight |
maybe it doesn't have a lot of runtime overhead |
| 17:58 |
|
lucian |
benabik: i like those particular properties. i just think it's an overly complex language |
| 17:59 |
|
benabik |
whiteknight: That's what I mean. It does have an unfortunate tendency to explode in size… But when I'm trying to explore large keyspaces I need runtime performance. |
| 18:00 |
|
benabik |
lucian: I find it fairly clear. People regularly use horrible styles of programming with it, which I find unfortunate. But I find the base language clear. |
| 18:00 |
|
lucian |
benabik: that surprises me a lot. i find it extremely ambiguous and odd |
| 18:01 |
|
lucian |
there's a reason it's so hard to parse |
| 18:03 |
|
* whiteknight |
is upgrading to FireFox 6.0 |
| 18:03 |
|
whiteknight |
prepare for cursewords! |
| 18:03 |
|
benabik |
I should probably try FF again at some point. But it has this horrible tendency to absorb all my memory. |
| 18:11 |
|
jay |
benabik: I'm hooked on FF. Doing big data scrapes right now to prepare for the draft in two weeks. |
| 18:12 |
|
benabik |
jay: And firefox makes that easy how? |
| 18:13 |
|
jay |
lol Sorry. Fantasy Football... you can tell my mind is elsewhere. Actually have severe jetlag, too. Oh well. |
| 18:13 |
|
benabik |
jay: Ah. Fair enough. Fantasy Football seems to absorb all your memory, just like Firefox aborbs all my computer's. ;-) |
| 18:15 |
|
jay |
benabik: exactly. My FF frustrations include different plugin behavior on different Ubuntu installations... clearly my fault, but hard to pin down. Sometimes video works, other times not. |
| 18:25 |
|
|
whiteknight joined #parrot |
| 18:32 |
|
|
Coke joined #parrot |
| 18:32 |
|
Coke |
~~ ## home machine was apparently rebooted. |
| 18:36 |
|
whiteknight |
hello Coke |
| 18:50 |
|
|
alester joined #parrot |
| 19:14 |
|
|
soh_cah_toa joined #parrot |
| 19:25 |
|
|
cotto joined #parrot |
| 19:36 |
|
|
kid51 joined #parrot |
| 19:37 |
|
kid51 |
Coke: On OSX, does 'man openssl' have anything you can use re sha256? |
| 19:37 |
|
|
daniel-s joined #parrot |
| 19:38 |
|
tcurtis |
~~ |
| 19:39 |
|
whiteknight |
hello tcurtis |
| 19:41 |
|
tcurtis |
hello, whiteknight. |
| 19:41 |
|
cotto |
whiteknight, #ps? |
| 19:42 |
|
benabik |
Arg! I must have gotten more used to the old #ps time than I thought. |
| 19:42 |
|
cotto |
no complaining. I'm halfway across the world. ;) |
| 19:43 |
|
benabik |
cotto: It's more just irritation at myself for forgetting to show up on time than irritation about the time. |
| 19:44 |
|
whiteknight |
that time already? |
| 19:44 |
|
cotto |
'fraid so |
| 19:52 |
|
|
particle1 joined #parrot |
| 20:11 |
|
|
rdesfo joined #parrot |
| 20:12 |
|
cotto |
soh_cah_toa, did you see that module I msg'd you? Someone did a talk on it at yapc and I thought of your HBDB test code |
| 20:12 |
|
soh_cah_toa |
let's see... |
| 20:12 |
|
soh_cah_toa |
there it is |
| 20:13 |
|
cotto |
I just sent a link because I didn't want my attention to diverge from the talk too much. |
| 20:13 |
|
soh_cah_toa |
this looks interesting |
| 20:14 |
|
soh_cah_toa |
cotto: wow, i'm glad you saw this |
| 20:14 |
|
soh_cah_toa |
i'm downloading the source now. see what i can borrow |
| 20:15 |
|
cotto |
if it's useful enough as-is, we can bundle it |
| 20:15 |
|
soh_cah_toa |
ok |
| 20:23 |
|
whiteknight |
what is it? |
| 20:24 |
|
cotto |
whiteknight, it encapsulates running a process and dealing with stdin/stdout/stderr and exit codes |
| 20:27 |
|
benabik |
kid51++ # doing legwork |
| 20:27 |
|
soh_cah_toa |
kid51++ indeed |
| 20:32 |
|
Coke |
kid51: I've no tuits to figure out at the moment what the drop in replacement for that linux command is, so Iunno. |
| 20:38 |
|
|
bluescreen_ joined #parrot |
| 21:11 |
|
|
perlite_ joined #parrot |
| 21:11 |
|
|
plobsing joined #parrot |
| 21:45 |
|
|
Psyche^ joined #parrot |
| 22:16 |
|
* Coke |
sits down to try the release again. |
| 22:17 |
|
sorear |
eep. what happened? |
| 22:17 |
|
|
mj41 joined #parrot |
| 22:17 |
|
Coke |
linux-specific code in the release path. |
| 22:17 |
|
|
rdesfo joined #parrot |
| 22:17 |
|
Coke |
my main box is OS X. re-doing on feather. |
| 22:18 |
|
sorear |
... |
| 22:19 |
|
dalek |
parrot-gmp: 42941e4 | bubaflub++ | LICENSE: |
| 22:19 |
|
dalek |
parrot-gmp: Add artistic license 2.0 |
| 22:19 |
|
dalek |
parrot-gmp: review: https://github.com/bubaflub/pa[…]commit/42941e47c9 |
| 22:19 |
|
dalek |
parrot-gmp: 08879a3 | bubaflub++ | / (4 files): |
| 22:19 |
|
dalek |
parrot-gmp: update some docs |
| 22:19 |
|
dalek |
parrot-gmp: review: https://github.com/bubaflub/pa[…]commit/08879a37f6 |
| 22:19 |
|
sorear |
I'd say "seriously?" but I think I know the answer. |
| 22:20 |
|
Coke |
eh. there's a very small # of people that have to do the release. |
| 22:20 |
|
Coke |
and the problem is very fixable. |
| 22:20 |
|
Coke |
(it's just the use of sha256sum, SFAIK) |
| 22:20 |
|
Coke |
wtf. feather and git don't seem to be talking to each other. |
| 22:21 |
|
Coke |
*github |
| 22:23 |
|
Coke |
anyone else able to git clone/pull/fetch on feather to a github origin? |
| 22:24 |
|
sorear |
yes |
| 22:24 |
|
|
darbelo joined #parrot |
| 22:25 |
|
* lucian |
has written a long blog post http://honeyweb.wordpress.com |
| 22:25 |
|
lucian |
phew |
| 22:25 |
|
sorear |
Coke: correction: I can pull from gist.github.com but not github.com, from featuer |
| 22:25 |
|
sorear |
feather |
| 22:29 |
|
|
ReachingFarr joined #parrot |
| 22:29 |
|
dalek |
website: lucian++ | The End. |
| 22:29 |
|
dalek |
website: http://www.parrot.org/content/end. |
| 22:30 |
|
Coke |
ARGH. |
| 22:30 |
|
Coke |
so now I have to fall back to plan C, which is making "make release" work on OS X. |
| 22:30 |
|
lucian |
dalek: no, bad dalek. this is the link http://honeyweb.wordpress.com |
| 22:32 |
|
sorear |
Coke: *I can pull from the github main site* |
| 22:32 |
|
* Coke |
remembers he's got a linux laptop around here somewhere, and goes off to find it. |
| 22:32 |
|
Coke |
sorear: yes, but I cannot. |
| 22:32 |
|
sorear |
have you tried in the last minute or two? |
| 22:33 |
|
sorear |
I was having a problem too but it started working again for me |
| 22:35 |
|
Coke |
nope. it's just hanging. if I run it with -v, looks like it's talking to the server, even. |
| 22:38 |
|
ReachingFarr |
Is it possible to execute parallel code inside the Parrot VM? |
| 22:38 |
|
lucian |
Coke: github wfm |
| 23:11 |
|
|
kid51 joined #parrot |
| 23:23 |
|
|
theory joined #parrot |
| 23:24 |
|
dukeleto |
Coke: sha256 = shasum -a 256 . do you have shasum on os x? |
| 23:25 |
|
kid51 |
$ perl -e "print qq(abc)" | shasum -a 256 |
| 23:25 |
|
kid51 |
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad - |
| 23:25 |
|
kid51 |
On Mac OS X 10.4.11 |
| 23:25 |
|
kid51 |
Will that work for us? |
| 23:28 |
|
dukeleto |
yes |
| 23:28 |
|
dukeleto |
lucian++ # blogging |
| 23:32 |
|
kid51 |
On Mac OS X: |
| 23:32 |
|
kid51 |
$ shasum -a 256 Parse-File-Metadata-0.07.tar.gz |
| 23:32 |
|
kid51 |
831240e0ca832283ec18016517fcbf5c8e67751c1b8213686815c5825dad8e57 Parse-File-Metadata-0.07.tar.gz |
| 23:32 |
|
kid51 |
On Linux (Debian): |
| 23:33 |
|
kid51 |
sha256sum Parse-File-Metadata-0.07.tar.gz |
| 23:33 |
|
kid51 |
831240e0ca832283ec18016517fcbf5c8e67751c1b8213686815c5825dad8e57 Parse-File-Metadata-0.07.tar.gz |
| 23:33 |
|
kid51 |
works4me |
| 23:42 |
|
Coke |
dukeleto: awesome. someone should totally probe for which one of those is the right one. For now, I'm just doing the release on linux. |
| 23:48 |
|
Coke |
I will attempt to provide a patch for that post release. |
