Parrot 4.7.0 "Hispaniolan" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 4 September 2012.
sorear all I know is that there was one recentish and it's one of very few tech things in my area 00:00
MikeFair sorear: yes Souther California Annual Linux Expo
sorear: You're in Los Angeles?!?
:)
me too
sorear MikeFair: Even worse.
MikeFair: San Diego.
MikeFair ahhh
sorear: But you have geeks.com
sorear: What more could you want?! ;) 00:01
sorear I wouldn't mind a yapc. 00:02
MikeFair sorear: Good point 00:03
sorear really, I could do without the 24+ hours of flying next time yapc season comes around 00:04
MikeFair sorear: Well I know the founders of SCALE so getting their input advice on going about a YAPC might work
not until after SCALE
sorear when is SCALE this year? 00:05
MikeFair sorear: but it's not totally out of the question, they've got the process down pretty good by now
this year was i Feb, next is Feb '13
sorear: They spend about 6 months in advance preparing the all volunteer work force, getting proposals, vendors, and what not 00:06
sorear note: my parents have been working comic-con for longer than they've been married and have played no small part in organizing its growth
MikeFair sorear: So there you go, they got tons of experience too :) 00:07
SoCal YAPC could happen
i'd like to get to the point of having some basic working code on my language before taking anything like that on though 00:08
sorear MikeFair: what impressed me most about the last yapc I was at... Frankfurt.pm is about 150% the size of SanDiego.pm 00:09
MikeFair sorear: I think SoCal is off the size that it's easy to think 'somebody else will do it' and be right a lot of the time 00:16
-f
sorear: unfortunately, it's also 'not right' on even more things 00:17
dalek rtcl-nqp/nqp2: 9c3c543 | coke++ | src/Partcl/Grammar.pm:
fixup Partcl::Grammar
 00:20
rtcl-nqp/nqp2: b47d8d3 | coke++ | src/Partcl/Compiler.pm:
fixup Partcl::Compiler
rtcl-nqp/nqp2: fde57c8 | coke++ | src/Partcl/Actions.pm:
fixup Partcl::Actions
rtcl-nqp/nqp2: 2f18dbb | coke++ | src/Partcl/Actions.pm:
update PAST style :pirop

  MikeFair++
rtcl-nqp/nqp2: 0a00651 | coke++ | src/Partcl/Actions.pm:
remove PAST style :isdecl
00:33 sivoais joined
dalek rrot/native_pbc2: 60b281e | rurban++ | / (11 files):
Rewrite native_pbc number converters and fix format errors

Fix wrong layout of intel 80-bit long double, it is 10-byte + 2/6 byte padding in i386 resp. x86_64/itanium. Renamed to FLOATTYPE_10. Older pbc contain a wrong floattype=2 for this format. It only depends on the word size: on 32bit padded to 12 byte, on 64 to 16byte. Fixed the header writer logic accordingly.
Add single float support FLOATTYPE_4.
Add detection of yet unsupported special ppc, mips and aix variants and the official IEEE-754 __float128 (quad double) format, which only Sparc64 supports.
Simplify endianizers on number converters to reduce complexity. Use native byteswap.h if detected (not yet). New and better number.pasm values.		 00:49
rrot/native_pbc2: 1cb93a8 | rurban++ | / (8 files):
pre-calculate FLOATTYPE

FLOATTYPE is cpu dependent for long double. Better do that in a config step, not at run-time. Improve __float128 support.
rrot/native_pbc2: 6c03889 | rurban++ | t/native_pbc/ (2 files):
remove instable number

on 32-bit the highest number is printed differently
rrot/native_pbc2: d8f0aae | rurban++ | tools/dev/mk_native_pbc:
rewrite tools/dev/mk_native_pbc

Support all possible floattypes, simplify logic Remove bashism
rrot/native_pbc2: 013d63e | rurban++ | / (12 files):
native_pbc: float 4 fixes, mk_native_pbc

floattype_4 needs some prev. undefined helpers improve mk_native_pbc regenerate 32-bit le pbc's
rrot/native_pbc2: 8f0a068 | rurban++ | / (3 files):
adjust number.t to new floattypes, do not use %Qg
00:58 rurban_mobile joined
dalek rrot/native_pbc2: 0b16b48 | rurban++ | t/native_pbc/number_8_ (2 files):
native_pbc: update 8_le
 00:59
rrot/native_pbc2: a146987 | rurban++ | tools/dev/mk_native_pbc:
fix mk_native_pbc syntax error
rrot/native_pbc2: a950453 | rurban++ | t/native_pbc/number_4_4_le.pbc:
t/native_pbc/number_4_4_le.pbc added
 01:01
rrot/native_pbc: 60b281e | rurban++ | / (11 files):
Rewrite native_pbc number converters and fix format errors

Fix wrong layout of intel 80-bit long double, it is 10-byte + 2/6 byte padding in i386 resp. x86_64/itanium. Renamed to FLOATTYPE_10. Older pbc contain a wrong floattype=2 for this format. It only depends on the word size: on 32bit padded to 12 byte, on 64 to 16byte. Fixed the header writer logic accordingly.
Add single float support FLOATTYPE_4.
Add detection of yet unsupported special ppc, mips and aix variants and the official IEEE-754 __float128 (quad double) format, which only Sparc64 supports.
Simplify endianizers on number converters to reduce complexity. Use native byteswap.h if detected (not yet). New and better number.pasm values.
rrot/native_pbc: 1cb93a8 | rurban++ | / (8 files):
pre-calculate FLOATTYPE

FLOATTYPE is cpu dependent for long double. Better do that in a config step, not at run-time. Improve __float128 support.
rrot/native_pbc: 6c03889 | rurban++ | t/native_pbc/ (2 files):
remove instable number

on 32-bit the highest number is printed differently
rrot/native_pbc: d8f0aae | rurban++ | tools/dev/mk_native_pbc:
rewrite tools/dev/mk_native_pbc

Support all possible floattypes, simplify logic Remove bashism
rrot/native_pbc: 013d63e | rurban++ | / (12 files):
native_pbc: float 4 fixes, mk_native_pbc

floattype_4 needs some prev. undefined helpers improve mk_native_pbc regenerate 32-bit le pbc's
rrot/native_pbc: 8f0a068 | rurban++ | / (3 files):
adjust number.t to new floattypes, do not use %Qg
01:14 bluescreen joined 01:24 mvorl joined 03:22 alvis_ joined
MikeFair What does the "term" match do exactly? 06:03
sorear What do you mean? 06:06
MikeFair Well it's switching between the recursive descent parser and the bottom up parser 06:12
and the "term" match invokes that switch
at least that's what is what I'm understanding it does
But it's still a bit fuzzy to me 06:13
When invoked I can see it will take the match string and search for the operators predefined operators
it will then try and parse the operands of that operator in top-down fashion 06:14
somefunc(value) * otherfunc() + 2 06:15
I know that "term" is involved in getting the * to pass the results of somefunc(value) and otherfun() as operands toto the pirop mult 06:16
and the result of that then gets passed to pirop "add" along with 2 06:17
I'm just not seeing what is matching what just yet in my head yet
I'll just keep plugging along
it will sink in eventually 06:18
:)
I think this is the key line fro mthe Squaak tutorial: The term proto token is invoked every time a new operand is needed 06:19
So in my above example, somefunc(value) and otherfunc() and 2 would all need to hit somewhere in the term:sym family of expressions 06:20
I think...
sorear MikeFair: the part you are missing is github.com/perl6/nqp/blob/master/s...ar.pm#L537 06:21
the bottom up parser is not as separate as you make it sound 06:22
MikeFair Right that's the <EXPR> match
sorear it is just another recursive descent rule
which happens to call 'term' internally
this might be more readable: github.com/sorear/niecza/blob/mast....pm6#L4405 06:23
MikeFair Right, I guess I'm just not quite seeing what belongs in "term" and when to use <EXPR> just yet
sorear use <EXPR> to parse an expression.
write a "term" rule when you want <EXPR> to see something as atomic
MikeFair like otherfunc() right 06:24
sorear 'term' is not involved at all in the parsing of operators like *
otherfunc() is parsed by 'term'
MikeFair right
sorear * is parsed by 'infix'
MikeFair but that who evaluation is triggered by <EXPR>
err whole
sorear 23:16 <@MikeFair> I know that "term" is involved in getting the * to pass the results of somefunc(value) and otherfun() as operands toto the pirop mult 06:25
that is *completelt wrong*
MikeFair: EXPR calls term, yes
term can also call EXPR, for instance function arguments
MikeFair EXPR also uses the Grammar.O list of things to find matches? 06:26
sorear: yeah and I think that's also baking my brain atm :)
if <EXPR> then <EXPR> else <EXPR> ? 06:27
and EXPR includes <term>
which could match a function call 06:28
that itself calls <EXPR> (for the sub-selection of text to match within the function call parameters) 06:29
I've mentally been thinking of "EXPR" as "returns a value" or "evaluates to something" 06:32
Which is somewhat different from flow control structures 06:33
sorear Flow control structures return values in p6 06:36
MikeFair Yeah, I wanted them to return values in Safire too 06:37
sorear EXPR nodes return values, but they are not the only things that do
many kinds of nodes in p6 return a single value
MikeFair I'll need to read up a lot more on that 06:38
sorear EXPR, term, sigterm, capterm, quote, value, circumfix, number, version, variable, ...
MikeFair what's a capterm?
sorear a lot of the perl 6 grammar flexibility comes about because so many things have the right shape to be plugged into term
\\(1,2,3) 06:39
MikeFair like an array?
ora list
or just commas and parantheses 06:40
sorear no, capterms are constructors for Capture objects
they're used very rarely, it's not very useful to know what they are 06:41
MikeFair nods.
constructors for Capture objects gave me enough context for when they show up
:)
06:47 mvorl joined
dalek kudo/nom: 1374a97 | moritz++ | src/core/Signature.pm:
use : as invocant marker in Signature.perl
 06:49
MikeFair Success! 07:12
MikeFair finally has most of the workings of the original language that comes from mk_language_shell 07:13
The only thing left is to get the "callmethod" op working to connect to the functions that are in Runtime.pm
MikeFair heads to bed for the night. 07:14
08:19 Psyche^ joined 09:08 fperrad joined
moritz function and 'callmethod' don't mix 09:32
if you want to call a sub, use 'call', not 'callmethod' 09:33
12:42 JimmyZ joined 12:47 whiteknight joined
whiteknight reading over emails, it looks like all threads-related issues have been resolved. No? 12:48
tadzik lexicals!
whiteknight well, all the ones in our repo, right
I consider that a separate set of problems 12:49
tadzik ah, yes, possibly
rurban_mobile we need a parrot testcase
tadzik not parrot-nqp one, hm?
or winxed-one?
whiteknight any of those should be fine
tadzik I have a parrot-nqp testcase alright
whiteknight winxed I might prefer, if it's easy enough to duplicate there
tadzik I can try winxeding it
whiteknight although that's just a personal thing, and I can try my hand at the translation if I have the parrot-nqp source 12:50
tadzik I wanted to try winxed anyway
gah. In winxed it works 12:57
well, sort-of
gist.github.com/3684165 12:58
the second line of output is wrong
whiteknight what's it supposed to say, 5 5 7? 13:00
tadzik I'd expect so, yes 13:01
I get 5 5 7 if I just run a():
that means that threads get lexical stuff wrong for some reason 13:02
whiteknight you have a gist with the parrot-nqp version, for comparison?
tadzik yes
gist.github.com/3610283
this one is a bigger problem 13:03
whiteknight I wonder if the difference in the first version is that x is an int and not a var 13:04
tadzik yes 13:05
then it silently dies like the nqp version
exactly the same behaviour
whiteknight okay, good 13:06
tadzik: are you using an optimized build/ 13:07
?
because when I run it locally with a debug build, I get a big assertion failure
src/call/context_accessors.c:258: failed assertion 'outer_ctx->vtable->base_type == enum_class_CallContext' 13:08
Ah, I got it 13:13
The outer ctx there is a Proxy to a CallContext, which it should be, but the code is asserting that it's a CallContext 13:14
okay, this is a bigger problem than I thought. 13:16
All the context accessor functions have been optimized to do direct pmc data access instead of going through vtables.
so when we proxy the CallContext, all context accesses fail hard 13:17
the trick is finding a way to get around this problem without killing performance 13:18
and without introducing stupid semantics 13:19
tadzik: I just sent an email to parrot-dev with the diagnosis. I'm out for most of the day so I have time to think about a good solution 13:30
tadzik whiteknight: yes, I'm on --optimize 13:49
whiteknight: okay, awesome. Thank you 13:50
14:08 kid51 joined
dalek sella: 697efd9 | Whiteknight++ | src/net/MimeBase64.winxed:
[Net] Add a TODO note about breaking lines in MIME, with reference to ticket about the parrot core implementation, which makes the same mistake.
 14:16
14:23 benabik joined
kid51 whiteknight, you wrote earlier: "reading over emails, it looks like all threads-related issues have been resolved. No?" 14:31
But that overlooks the Darwin/Intel problems both dukeleto and I have reported. 14:32
whiteknight kid51: unless you have a report somewhere that I missed (tadzik's report I'm treating separately)
okay, then I am overlooking those
moritz how about using a bug tracker for such issues?
that's what they are for (not losing overview)
kid51 moritz: Up until now, at any rate, we haven't used the bug tracker du jour for tracking *branch* problems. 14:33
whiteknight this is part of the reason why it's so hard for me to keep track of these issues
moritz kid51: but it'd make sense, no? 14:35
kid51 moritz: I'm not sure. 14:36
When we open a ticket in the bug tracker, we're saying that this is a problem of concern to the project as a whole.
whiteknight we can use tags or milestones to group branch tasks
kid51 But I tend to think that the people working on a particular branch not yet merged into master are responsible for keeping track of that branch's problems.
whiteknight a "merge threads" milestone could have several tickets assigned to it
moritz kid51: which is fine for small branches 14:38
kid51 There are a couple of branches I opened up to two years ago which are still around -- but I don't think tracking their problems is the responsibility of the project as a whole.
moritz kid51: but if the owner loses overview, technical help is welcome
kid51 moritz: I'm inclined to say, "Let's discuss this at parrotsketh" ... but that would require that we actually *hold* parrotsketch! :-(
whiteknight post an email to the list 14:39
kid51 Well, if you're the one who wants a change to our current processes (or lack thereof), then I'd suggest writing to list is your job. 14:40
whiteknight fair enough 14:41
kid51 whiteknight: If current time for parrotsketch doesn't work for you, and if you're the one writing most of the code right now, then we should change time so that you can get feedback you need.
whiteknight we can look at that, but I can't think of any time that is universally good for me 14:42
any time during work hours is going to fall victim to regular interruptions. Time outside those hours becomes bad for people in other timezones
more bad, for more people
kid51 I understand that -- I face the same challenges re work hours, what with new $job -- but at this point *any* parrotsketch is better than *no* parrotsketch 14:44
ISTM that there are 2 types of feedback the author of a complex branch needs: 14:50
1. test results, both (a) within Parrot, but on different platforms from the author's; ..
and (b) from Parrot users.
Example: (a) kid51; (b) moritz and pmichaud 14:51
2. engagement from those people with the skill sets capable of understanding what the branch author is doing.
Recent examples: rurban, Nick Clark, Andy Dougherty on threads and io_cleanup1 branches. 14:52
dalek sella: 3d7999a | Whiteknight++ | / (2 files):
[Net] Fix MimeBase64 so long encoded outputs are broken after 76 columns. The decoder still works with this change. Add a test to prove the new behavior
 14:53
kudo/nom: f488677 | moritz++ | / (3 files):
export trait for constants
 15:17
15:50 mvorl joined 16:04 tuxit joined 16:07 JimmyZ joined
dalek rrot/native_pbc2: 347d87c | rurban++ | / (4 files):
add native include/parrot/bswap.h and probe

probe for endian.h, byteswap.h or OSX header for native bswap inline functions/macros.		 16:11
rrot/native_pbc2: f26b383 | rurban++ | config/auto/sizes.pm:
add HAS_FLOAT128 in config hash

__float128 is binary compatible to 16-bit big-endian sparc/s390 long double formats. Available since gcc 4.6
rrot/native_pbc2: 775883a | rurban++ | / (5 files):
Fix and improve bswap.h

Add missing libkern/OSByteOrder.h Abstract macros into static inline functions Use fast replacement macros Use bswap in pf_items.c
rrot/native_pbc2: b0ab7d2 | rurban++ | include/parrot/bswap.h:
Fix byteswap.h and 64bit fallback macro

Forgot to define bswap macros with GNU byteswap.h Fixed bswap_64 fallback.		 16:36
17:01 benabik joined 17:16 Khisanth joined 17:53 contingencyplan joined 18:36 sivoais_ joined 19:28 lucian joined
dalek rrot/native_pbc2: 5851213 | rurban++ | / (3 files):
fix and optimize bswap

Also allow FLOATTYPE_16PPC, but this format seems to be double-double, not __float128		 20:00
20:11 lucian joined
MikeFair Howdy #parrot! :) 20:59
21:38 benabik joined 21:39 whiteknight joined
dalek rrot/native_pbc2: 44b7e3d | rurban++ | / (4 files):
Fix nvsize in config/auto/format.pm, number_4*_be pbcs

nvsize should be the same as numvalsize, probed in auto::sizes, but not one of floatvalsize, doublevalsize or hugefloatvalsize. E.g. with long double used and __float128 possible hugefloatvalsize is 16
Add generated ppc pbcs		 21:40
rrot/native_pbc2: 2d302a7 | rurban++ | / (6 files):
Add ppc converters, add PF_floattype_names

Added and document converters, ppc needs intermediate helpers. The ppc long double is the sum of two doubles stored one after the other: double-double.
rrot/native_pbc2: 4232a13 | rurban++ | t/native_pbc/number_4_10_le.pbc:
t/native_pbc/number_4_10_le.pbc added
whiteknight good evening, #parrot 22:37
23:31 kid51 joined 23:47 benabik joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!