Parrot 3.2.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Parrot is accepted for GSoC 2011! Student application deadline is Apr 8
Set by moderator on 27 March 2011.
benabik That did, in fact, fail for me. 00:02
00:05 bbatha joined 00:08 takadonet1 joined
takadonet1 Can Parrot support reading files with different 'line' delimiter other then "\\n"? 00:12
00:12 theory left
whiteknight takadonet1: good question 00:14
I suspect so, but I've never done that test
takadonet1 whiteknight: I'm from the Rakudo world and in our implementation, if we see that argument passed to the IO object and it's not a "\\n", it fails :( 00:15
I need more then just "\\n" :)
whiteknight IO object, you mean the FileHandle PMC? 00:18
or does Rakudo implement something custom?
takadonet1 whiteknight: something custom I believe 00:19
<--- Rakudo user, not developer
whiteknight ah, gotcha
takadonet1 I can look at Perl 6 and understand it very well but PIR.... not so much
whiteknight well, we'd have to figure out where that particular logic lives 00:20
takadonet1 and that what i'm doing right now
good old grep :)
plobsing ack is better
takadonet1 well I have somewhat an idea where to look in the src folder 00:21
benabik Looks like Rakudo's IO object calls readline on a Parrot IO object (result of open__PSS)
takadonet1 i'm just hope it's implemented
benabik takadonet1: Where are you passing in the "something other than \\n"? 00:22
takadonet1 benabik: multi sub lines
plobsing takadonet1: Handle has a 'record_separator' attribute. that's probably what you are looking for. 00:25
benabik takadonet1: fail 'Fancy newlines not supported yet' if $nl ne "\\n";
takadonet1 plobsing: in Rakudo it will be $*FH.input_record_separator() however nyi
benabik: indeed that is the line 00:26
plobsing not parrot's problem
benabik takadonet1: Ah, you're trying to remove the NYI problem?
benabik misunderstood.
takadonet1 benabik: that too
just wonder if parrot support it, if so then I would change it in rakudo 00:27
i think it's hardcoded in parrot :( 00:32
parrot 3.2.0 src/io/api.c line 632 00:33
all well thx guys 00:34
00:37 theory joined
plobsing takadonet1: um no. Handle has a field called 'record_separator' that is consulted in readline. that's what I told you before. 00:38
src/io/api.c:632 only applies for StringHandle 00:39
00:42 mikehh joined
whiteknight holycrap that imcc_compreg_pmc merge diff is huge 00:47
that's a pretty big weight off my shoulders
dalek rrot: 54c4f34 | Whiteknight++ | NEWS:
mention IMCC happenings in NEWS
 00:48
cotto ~ 00:58
00:58 kid51 left
plobsing can we classify the imcc decouple roadmap goal a success now, or are there other criteria that need addressing? 01:00
whiteknight technically, no. It's mostly decoupled, but not completely decoupled 01:02
we still only have one libparrot, not a separate libparrot-imcc
plobsing what else can we do before the deprecation boundary? 01:03
whiteknight that's a very good question 01:05
I don't think there are any user-facing changes to come.
IMCC has the new interface that it's going to have, the compregs aren't going anywhere. We're not changing any syntax 01:06
the parrot.exe frontend is going to handle loading all the necessary libraries
I think we're good for deprecation
plobsing I thought IMCC was only going to be available *when asked for*
01:10 eternaleye left, eternaleye joined
dalek rrot: 443ce3a | (Michael Hind)++ | compilers/imcc/reg_alloc.c:
fix codetest failure - trailing spaces
 01:10
whiteknight plobsing: the parrot.exe frontend is the user "Asking for it" 01:13
alternate frontends will have different behaviors
plobsing whiteknight: what about ./parrot my-pbc-file.pbc ??? 01:14
mikehh bah - pushing from newly installed system seems to have lost my normal user id
whiteknight that's the same frontend, it will provide the same environment
plobsing still IMCC availability from NQP is user visible 01:15
mikehh I think I copied files from elsewhere rather than new clone 01:16
whiteknight fakecutables will probably include IMCC also, at least the current generation of them
pbc2exe can be extended with an option to omit it 01:17
NotFound: ping
01:32 bbatha left 01:34 eternaleye left, eternaleye joined
whiteknight on the bright side, I just figured out why ExceptionHandlers can't be subclassed 01:38
Object.pmc-- 01:39
cotto why not? 01:44
Tene whiteknight: I don't think that's the only reason, if you found what I think you found. 01:48
... it's starting to get to the point that reading #parrot causes anxiety by reminding me of all the projects I've started or talked about or planned for but haven't finished (or started) 01:49
I haven't even merged my exceptions refactor work.
whiteknight Tene: That's what I'm working on right now, a rewrite of your exceptions stuff 01:51
Tene whiteknight: nice
whiteknight: feel free to ask me if you have any questions about it.
whiteknight where I'm stuck now is a part of it which was added after you started work
the finalize_p opcode is causing me trouble
Tene: don't worry, I will
Tene It was a very simple branch; just changed some "== Exception" to "isa Exception" 01:52
whiteknight Tene: you can take a look at the whiteknight/eh_subclass branch to see what I've done so far
I already merged in the stuff you did subclassing Exceptions
it's ExceptionHandlers that are causing problems now
Tene the big issue was with the two separate attribute stores in isntances of subclasses of exceptions. I was never able to understand WTF was going on there.
that's why I didn't merge it before.
whiteknight yeah, that's what I'm seeing now
Object["proxy"] stores an instance of the superclass to delegate to. Both objects have separate attribute stores and don't sync 01:53
first off, let me say how much it bugs me that the attribute name "proxy" is reserved here 01:54
Tene Does it actually need a full instance?
whiteknight yeah
Tene Ah. What for? What does it use attribute parents for?
erm
attributes of the superclass isntance?
Oh, I guess it's p6 style. 01:55
whiteknight if I create a subclass of ExceptionHandler, every object of my subclass has an ExceptionHandler PMC in the "proxy" attribute
so that's two PMCs for the price of one
dalek tracwiki: v4 | whiteknight++ | ExceptionRefactor
tracwiki: add a quick note about why ExceptionHandler cannot be subclassed
whiteknight or, one PMC for the price of two
dalek tracwiki: trac.parrot.org/parrot/wiki/Excepti...ction=diff
whiteknight whichever makes the least sense
01:56 petdance joined
Tene like: class A { has $!x; method a { say $!x } }; class B is A { has $!x; method b { say $!x } } 01:56
the reason I was seeing a problem was due to two different ways of accessing object attributes. get_*_keyed_str is overloaded in Exception.pm to redirect to getattribute, or something 01:57
whiteknight no, not for all classes. Only cases where a Class inherits from a PMCProxy
Tene so that was getting the Exception attributes, instead of the subclass attributes
whiteknight right
don't worry if you don't understand it. There's nothing to understand
it's the worst design ever 01:58
Tene well, understanding isn't that necessary, but being able to actually use it is. As long as everything ends up using the same attribute store in the end, is all we really need for this. The problem I had was inconsistency in how different pieces of parrot accessed exception attributes, and I didn't know which direction to try to resolve it in. 01:59
so, you're seeing the same behaviour with exceptionhandler 02:00
whiteknight There are three possible solutions: 1) the quick hack-job to make it work now. 2) Change the way the exceptions system stores attributes to avoid this issue, or 3) Fix the damned object model
Tene I've never understood wtf a PMCProxy is
whiteknight 3 is obviously the best, but is probably the most wok
Tene: it's shit 02:01
(that's the short answer) :)
Tene If I were doing it, I'd do 2.
whiteknight Tene: yeah, that's where I
'm leaning
I don't want to play with the object model if we have 6model on the horizon 02:02
of course, we need to make sure we don't implement this same insanity when 6model lands 02:03
Tene whiteknight: standardizing attribute storage for exceptions system shouldn't be more work than a set of hack jobs, I expect, and is more correct. 02:04
whiteknight Tene: right now, ExceptionHandler.set_pointer falls back to Continuation.set_pointer. 02:05
Continuation.set_pointer sets both the address and runloop_id attributes 02:06
anyway, it's time for bed. we can talk about this more later
goodnight
02:07 whiteknight left
Tene whiteknight: what I *really* want to do is move away from this rubbish set_pointer dynamic adding and removing of handlers stuff, and have EHs statically represented in the bytecode. 02:08
02:22 mtk left 02:29 mtk joined 02:32 takadonet1 left 02:33 dngor_ joined
sorear +1 02:35
02:37 dngor left 02:54 petdance left, hudnix left
plobsing what is the point of subclassable exceptions? many dynamic languages use any object as a throwable (perl, javascript, lua, etc...). we should encourage HLLs to not mix their exceptions with Parrot's bookkeeping and to always use the "payload" attribute. 03:00
Tene plobsing: we currently do some things with the "type" of exception thrown, except it's a static list of integer types in the "type" attribute of the exception. That makes it a bit more awkward than it should be to do some things. 03:02
plobsing well yes. we should be dispatching based on the type of the payload 03:03
Tene plobsing: I'd expect that those languages where you can throw any object would just use an Exception, or possibly a sing language-specific subclass of Exception.
plobsing: Perhaps. That's where subclasses of ExceptionHandler come in to play.
That's an entirely reasonable strategy; I hadn't considered that before. 03:04
plobsing Tene: the problem lies in inter-HLL exception compatibility. if one HLL expects subclassed exceptions and the other expects encapsulated exceptions... BOOM
if everyone always uses encapsulated exceptions, because they are the most general type, no problems 03:05
Tene plobsing: Possibly. I don't think I have a sufficiently comprehensive knowledge of exception and handler usage in all languages to really speak definitively about this.
plobsing neither do I. I'm just making educated guesses based on how I know some languages expect exceptions to work. 03:06
Tene plobsing: it's currently the case that core parts of parrot rely on information in the attributes of the exception, not its payload.
plobsing perhaps fallback to the 'type' attribute of the exception if there is no payload? 03:07
Tene so, if we want to allow HLL exceptions to participate in that non-hackishly, we need to change *something*, and the most-reasonable way to do that, I'd expect, is expose it as type information in the exception object.
plobsing ie the payload is PMCNULL
Tene plobsing: the 'type' attribute right now is an integer, which has no relation to any classes or roles anywhere. They're incomparable. 03:08
plobsing so how does making exception subclassable manage to make them comparable?
Tene plobsing: we drop the 'type' attribute, put the relevant information into roles or whatever, and HLL authors can then apply those roles in the appropriate places of their exception type hierarchy, if they have one. 03:10
plobsing: I do like the idea of moving functionality from exception attributes into the payload, but there are a few questions that would need to be addressed. 03:11
plobsing so we're moving to type-dispatched exceptions for HLLs (but only when those types map to underlying Parrot exception types)?
Tene plobsing: the other issue is that moving functionality into the payload places restrictions on what can be put in the payload.
plobsing Tene: how does it restrict the payload? 03:12
Tene plobsing: for example, to resume from a resumable exception, we need to get the resume continuation from the exception. We could move to storing the resume continuation in the exception, or we could store a reference to the exception in the payload, or we require some fumbling on the part of every hll author on every exception handler, unpacking the exception and storing information in the payload. 03:14
so, you're right, it's not necessarily a restriction.
(I hadn't thought of the last option until I was responding) 03:15
plobsing I'm going to wager that most exception handlers don't care about resumption (based on the fact that most HLLs don't use resumable exceptions). 03:16
so for HLLs that don't care about all the fancy exception stuff, just unpacking the exception and passing that to the user (hiding all the parrot exception guts) would be good enough 03:17
Tene plobsing: please note that I'm not saying that it's infeasible, I'm just trying to work out what issues would come up, and how they might be addressed.
plobsing I realize that getting a backtrace could be tricky.
but then again, our backtraces are so borked on rethrow anyways, I'm not sure it matters. 03:18
Tene plobsing: additionally, there are other semantic mismatches. Consider perl 'die' and 'warn'. 'warn' means throwing an object non-fatally, so if it gets caught, nothing happens and the EH gets the originally-thrown object, but if it's not caught, it just gets stringified and printed to stderr. Right now, parrot handles that with the severity attribute of the exception, but are there languages where that varies with the type of the ...
... thrown exception?
plobsing: I fixed that in my exceptions refactor branch, which whiteknight says has been reimplemented in his branch which should actually get merged, unlike mine. :) 03:19
plobsing: additionally, if we're doing dispatch based on the type of the payload, that has similarly nontrivial interactions with other HLLs. 03:20
plobsing Tene: that would get packed into the invisible ParrotException object on the thrower side 03:21
Tene If I want to catch all IO errors, what happens if I call some parrot code which throws a core parrot exception which has the 'type' attribute set to an IO error? How do I set up my HLL EH to catch that, and to catch all instances of my HLL class "IOError"
plobsing I suppose you'd need two exception handlers that jumped to the same code. 03:22
Tene (note: I don't actually have a good solution for this in the type-based case either, fwiw)
plobsing: well, the way EHs work is that they have a can_handle method which gets the exception, and can either accept it or pass it on.
right now, can_handle does several checks because we have just one EH class 03:23
(it skips the checks if none of the filtering attributes are set)
we can filter based on positive or negative matches on the type attribute, the severity, and I think something else.
plobsing subclassable exceptions seem like a great solution for limited exception heirarchies with direct analogs to parrot's exception types. everyone else is left high and dry 03:24
Tene plobsing: I had planned to expose the relevant types that parrot cares about as a set of roles, so when you want parrot behaviour for something, you compose that role into the relevant parts of your HLL exception hierarchy. 03:25
I would not want parrot to have an exception hierarchy that it expected everyone else to conform to.
plobsing and if I have created an exception type that has no analog in Parrot? what role do I apply then?
Tene plobsing: If there's parrot behaviour that varies based on any roles that you want to happen for that type, you include those roles. If there isn't, you don't. 03:26
I think I must be missing something about your question.
plobsing so I could dispatch between IOError and NullPointerException, but not from eg: InvalidXMLException and InvalidDBConnectionString 03:27
because those have either no analog, or the same "Parsing Error" type behaviour 03:28
Tene plobsing: You could do whatever you wanted with your own types; If there's no parrot behaviour that varies with exception type that you want, then you don't have to do anything at all. This is the case for most exceptions. 03:29
03:29 Eduardow left
plobsing so then what do the roles do? 03:30
Tene plobsing: as a specific example, all pct-based languages (at least) do loop control with exceptions that have type attributes set to CONTROL_LOOP_NEXT, CONTROL_LOOP_LAST, CONTROL_LOOP_REDO
plobsing: I'm looking for specific examples right now... 'sec
plobsing: fwiw, to me, the big issue is the other direction. 03:31
plobsing the way I see it, PCT could create "LoopNext" "LoopLast" and "LoopRedo" singletons and use those as magic signal payloads
Tene plobsing: if I want to catch DivideByZero errors, or IO errors, how can I detect those from any language?
plobsing that is, in fact, what Ī©Ī· does now 03:32
Tene How can I annotate my exceptions as IO error such that any other language will recognize them?
plobsing: Sure, it certainly could.
plobsing: that would make it awkward for non-pct languages to interoperate there, though.
plobsing Tene: are you suggesting that you could set up a loop in one HLL nested in the other? I don't see that as a very compelling use case. 03:34
But the case for making core exceptions visible to HLLs does seem legit.
Tene as far as I'm able to work out, with either exception class or payload class based filtering, I don't see how the types from two HLLs could be arranged to be appropriately comparable. 03:35
plobsing Tene: they likely cannot in general. The general case should be served with check-and-'rethrow'. 03:36
but for specific exceptions, matching on class is a good idea
because many HLLs do that
Tene plobsing: part of my motivation was to allow a reasonably-extensible set of exception types, such that if I want to catch all of a certain class of errors, and someone adds an error of that class, my code will catch it too. A static list of integer exception types doesn't work for that.
plobsing no. and a static list of exception roles is no better. 03:37
Tene plobsing: my question is what the check would actually be. If a user in an HLL writes "catch all IO errors", what convention should HLL authors use to annotate their IO exceptions such that I can generate code to catch them? 03:38
soh_cah_toa don't meant to SIGINT you guys. i just wanna let all you late night hackers know that i've added the finishing touches to my proposal at www.google-melange.com/gsoc/proposa...kpolulak/1 03:39
plobsing I think, if you're using cross-HLL interaction, you can be expected to catch exceptions from the other language's heirarchy
cotto soh_cah_toa, great.
03:39 petdance joined
plobsing what are the odds that you will be doing IO operations from different HLLs? 03:39
Tene plobsing: pretty significant. Many libraries perform IO, and I expect most HLL interop to be basic library use. 03:40
petdance Anyone know the whole packfile API?
plobsing Tene: sure. but creating a unified exception system is bound to cater to the lowest-common-denominator. 03:41
cotto petdance, what's your question about it?
plobsing what we need is an *interoperable* exception system
petdance There are many args in the funcs that are entirely unused.
I'm eitehr going to keep them SHIMmed up, or I'd prefer to remove them entirely.
cotto petdance, start a branch and go nuts 03:42
petdance Not even gonna start a branch. :)
Tene plobsing: Ah, right, the other minor reason I wanted to move to type-based was because it's awkward to use PIR constants from an HLL.
cotto or that
petdance Didn't know if there was future work impending.
plobsing Tene: that's easily remedied. Use something like what Winxed does - read the constant.pasm and fill your constants appropriately. 03:44
cotto petdance, as long as the functions are internal and unused, there's a good chance they can be excised. 03:45
petdance Yeah, I'm not worried about breakage outside. More about "HEY, I WAS GONNA USE THOSE!"
Tene plobsing: incidentally, one of the problems we ran into before I started this branch, was that adding new exception types to the big static list invalidated other bytecode that had used constants generated from earlier versions.
plobsing Tene: yes, I agree the constant types are stupid. 03:46
cotto Tene, sigh
plobsing and I'm not defending them
Tene plobsing: yes, that's solvable by exclusively adding to the end of the list, but there's no way to coordinate changes there, etc.
plobsing: :)
plobsing: fwiw, I had remembered that there were places in parrot code that relied on specific exception types, but I'm not finding any, except the control exceptions in pct. 03:47
plobsing the exception type is mostly unused, because it is so dumb
Tene plobsing: I expect you feel similarly about exception severity, resumability, etc?
plobsing I think we need some mechanism for resumability. I'm not really sure what severity is for. 03:48
but I think that the thrower can work that out and tell parrot's bookkeeping about it.
alternatively, we could throw all the exception bookkeeping into the prophash of the thrown object 03:49
Tene plobsing: erm, I mean "similarly" to refer to "doesn't belong in HLL exceptions; just set it in the core exception in your language builtin that throws"
plobsing: well, at that point, what's the point of the exception object at all?
plobsing Tene: if we used prophashes, there would be no exception object.
that's the beauty
although there are disadvantages there too probably 03:50
Tene plobsing: so, instead of changing parrot's checks from "== exception" to "isa exception", we could just drop the check entirely, and rm exception.pmc
plobsing But, responding to your earlier question, no, I don't beleive that HLL exceptions should hold that kind of parrot-bookkeeping information. if the thrower thinks it is relevant, they can form an object graph between the ParrotException and the HLLException to mediate what they are looking for 03:52
Tene: I'm not sure we could fully drop exception.pmc. What would core parrot throw?
Tene plobsing: strings, of course. ;) 03:53
plobsing oh yes. strings as exceptions are marvelous. where is chromatic with some form of weapon when you need him?
Tene plobsing: severity is currently used for 1) choosing to exit() in a few places and setting the return code of the process, and checking if we should automatically resume from a non-fatal exception if severity is less than EXCEPT_error 03:57
(printing out a warning to stderr including the text of the exception if present) 03:58
Ahh, right, the "msg" attribute which is also used for get_str and set_str on parrot's exception objects.
That's another valuable thing we'd lose if we dropped exception objects; we'd have to print the stringification of the payload instead! 03:59
plobsing and how is that a bad thing?
Tene ;) 04:00
dalek rrot: e71a7ff | petdance++ | src/p (2 files):
consting pointers, and annotating function pointers
 04:02
petdance anyone else have t/perl/Parrot_Test.t failing? 04:08
I am, but nobody on taptinder is
cotto petdance, whiteknight or dukeleto might have seen failures earlier today 04:11
petdance and my t/src/extend_vtable.t has been failing for days as well 04:18
plobsing Tene: thanks for explaining subclassable exceptions. I think I now see how they make the state of parrot exceptions better. 04:19
Tene plobsing: I'm certainly not convinced that they're the best way to go, and I'm pretty sure that I agree that HLLs should probably not be subclassing exceptions, but should instead be putting their own exception objects in the payload. 04:21
Not entirely convinced, though.
I'm pretty sure that real type information is going to be a better option than the type and severity attributes, though. 04:22
plobsing nope. I still don't think they cover the whole problem. but it seems they would still be an improvement over the existing state of affairs. 04:23
Tene plobsing: what are you disagreeing with in "nope."?
04:23 soh_cah_toa left
plobsing I thought you were talking about me when you said "still not convinced" 04:23
Tene Ahh. 04:24
No, I was saying that I'm not entirely convinced that HLLs subclassing Exception would be bad.
The main argument I've seen in favor of the type and severity attributes is that a single itneger compare is far faster than walking the inheritance chain or whatever. 04:26
dalek rrot: ffb5e90 | petdance++ | / (2 files):
removed the unused arguments from all the packfile functions and their function pointer types
Tene If we move to using a prophash and letting users throw anything at all, though, we get the best of both worlds. 04:27
plobsing the inheritance chain can be cached. I don't think the int-compare argument holds much water.
Tene It's also possible that there's multiple inter-related concepts here that could be disentangled.
plobsing if we ever get a JIT with tracing, type-dispatch will be king 04:28
Tene if we get exception handlers static in bytecode, it would be possible in some cases to optimize 'next', 'return', etc. to a single goto. 04:29
plobsing Tene: I think in those cases, it should be possible for PCT to do that already.
Tene plobsing: Quite possibly. exception shit is very poorly represented in PAST. I don't know why anyone lets me work on important subsystems. ;) 04:30
afk; going home
plobsing Tene: you are the most qualified. be afraid. 04:31
;)
04:31 dngor_ left, dngor joined
petdance Dropping those function pointers makes me happy. 04:41
04:47 Eduardow2 joined 04:50 woosley joined 04:52 Kulag left 04:53 Kulag joined 04:59 Kulag left
dalek rrot: ae4f8e1 | petdance++ | / (2 files):
properly annotated some function pointers, and cleaned up 16 splint errors
 05:06
05:08 Eduardow2 is now known as Eduardow, Kulag joined 05:14 Kulag left 05:16 Kulag joined 05:20 jrtayloriv joined 05:38 petdance left 06:17 UltraDM joined 06:39 ShaneC left 06:41 theory left 06:49 ShaneC joined 06:58 cotto left 07:31 mj41 joined 07:35 UltraDM left 07:49 ShaneC left 08:20 jevin left 08:21 contingencyplan left
mikehh got an error in t/examples/pod.t - Parse errors: Tests out of sequence. Found (336) but expected (335)... 08:43
08:43 jrtayloriv left
mikehh never seen this before - Displayed the first 5 of 279 TAP syntax errors. 08:44
Re-run prove with the -p option to see them all. 08:45
running prove -p t/examples/pod.t - t/examples/pod.t .. Failed 1/613 subtests -> 08:48
Parse errors: Tests out of sequence. Found (336) but expected (335)
Tests out of sequence. Found (337) but expected (336) 08:49
then lists up to
Tests out of sequence. Found (613) but expected (612)
Bad plan. You planned 613 tests but ran 612.
the Parse errors: etc. was in the Test Summary Report 08:51
09:07 Kulag left 09:11 Kulag joined 09:39 JimmyZ joined, JimmyZ left 09:47 mikehh left 09:55 woosley left 10:10 mtk left 10:16 mtk joined 10:56 bacek left 11:32 mikehh joined 11:38 darbelo joined 11:54 darbelo left 11:55 Patterner left 12:01 Psyche^ joined, Psyche^ is now known as Patterner 12:02 UltraDM joined 12:10 bubaflub joined 12:39 plobsing left 13:06 ambs joined 13:08 whiteknight joined
whiteknight good morning, #parrot 13:16
bubaflub morning whiteknight 13:25
13:25 darbelo joined 13:47 hudnix joined 13:48 Eduardow left 13:49 Eduardow joined 13:52 JimmyZ joined
whiteknight hello bubaflub, how are you today? 14:01
bubaflub whiteknight: not bad, a little tired but workin' nonetheless
whiteknight: you?
whiteknight pretty damn good, actually. Got a full night of sleep, and I've finally merged in my huge imcc refactors branch 14:02
JimmyZ whiteknight++ for huage mcc refactors branch 14:03
NotFound whiteknight: pong 14:06
(pong from the past) 14:07
bubaflub whiteknight: i saw that. need any testing? i've got Mac OS X 10.6 14:09
JimmyZ tests are always welcome 14:12
14:18 darbelo left, darbelo joined
moritz last call for GSOC proposals: about 4 hours left until submission deadline 14:22
whiteknight NotFound: I was digging into problems with the finalize opcode, but I figured out what was going wrong 14:28
NotFound: so, unpong 14:29
NotFound Ok 14:32
14:42 JimmyZ left 15:05 theory joined 15:09 dod left
whiteknight benabik: ping 15:22
15:27 mj41 left
whiteknight msg benabik I would like to recommend some changes to your GSoC proposal, in light of the IMCC refactor work I merged last night. Let's talk about it when you have a chance 15:28
aloha OK. I'll deliver the message.
15:31 UltraDM left 15:39 cotto joined
PerlJam whiteknight: re Java bytecode for Parrot proposal, it's at the gist: gist.github.com/889846 15:41
15:41 bacek joined
whiteknight PerlJam: okay, but we're getting close to the deadline when it needs to be on the google-melange website 15:42
I would hate to see the proposal get screwed up because of the deadline 15:43
PerlJam Well, the URL for the gist is there. Are we really going to penalize a student who put a link to his proposal instead of the actual text of the proposal? 15:45
NotFound PerlJam: I don't know but I guess a contest have its rules. 15:50
PerlJam NotFound: I guess I'm more a "spirit of the law" than a "letter of the law" kind of person then. 15:51
NotFound PerlJam: a deadline is kinda letter. 15:52
Anyway, both the spirit and the letter come from google, not from us. 15:53
15:58 plobsing joined 16:02 JimmyZ joined 16:04 rohit_nsit08 joined
rohit_nsit08 hello #parrot 16:04
whiteknight hello rohit_nsit08
16:05 nnunley joined
rohit_nsit08 whiteknight: so today is the last day for the proposal submission :-) 16:05
I've made some more improvements in mine and added the javascript object model in it 16:06
whiteknight: how will students know about their status ?
16:07 |newbie| joined
|newbie| hi 16:07
PerlJam hello |newbie|
|newbie| nto os new 16:08
not so new
load_language" couldn't find a compiler module for the language 'perl6'
Could someone help?
What path do I need to set?
What is it looking for?
this is what is given back by parrot. 16:11
cotto_work ~ 16:17
whiteknight rohit_nsit08: we make comments if there is anything to change. Your proposal is good right now :) 16:34
|newbie| do you have perl6 compiled and available on your machine? 16:35
|newbie| yes 16:36
whiteknight |newbie|: where is the .pbc file loaded? Do you know where it is on your machine?
|newbie| which one?
yes
whiteknight |newbie|: the perl6.pbc file
|newbie| yes
whiteknight |newbie|: you should be able to use the -L option to parrot to add in a new search path 16:37
parrot -L/my/path/to/perl6.pbc/ myprogram.whatever
|newbie| no space after L? 16:38
whiteknight I don't think it's necessary
|newbie| it does not make any difference, anyway
whiteknight weird
|newbie|: can you nopaste the code you are running and the error message you are getting? 16:39
aloha, nopaste?
aloha whiteknight: nopaste is is nopaste.snit.ch (works with the script in $_PARROT/tools/dev/nopaste.pl)
cotto_work |newbie|: what's the process you went through to get Rakudo onto your system? 16:42
|newbie| nopaste.snit.ch/39705. 16:43
I got the binaires
from sourceforge
dukeleto ~~ 16:45
Coke boggles. we have binaries on SF?
cotto_work I think rurban provides them. 16:46
whiteknight yeah, that makes me nervous
are they current?
cotto_work or fperrad
whiteknight fperrad was doing it for a while I know
|newbie| 3.2.0
whiteknight well I'll be damned
fperrad++
|newbie| 3.2.0 , is it current version? 16:47
cotto_work seen fperrad
aloha fperrad was last seen in #parrot 1 days 1 hours ago joining the channel.
whiteknight |newbie|: try this: parrot -L C:\\parrot-3.2.0\\lib\\parrot\\languages\\ -o D:\\m\\p6\\pirout.pbc D:\\m\\p6\\pirout.pir 16:49
I suspect Parrot is doing something weird with search paths on windows
|newbie| it does not help 16:50
whiteknight blah. Damn 16:51
|newbie|: what are you working on?
plobsing perhaps parrot was compiled with weird paths. parrot_config libdir should show where libraries are expected.
|newbie| just trying to measure the execution speed of Perl6 program
which is compiled into pbc 16:52
plobsing I don't think Rakudo supports compilation to PBC
it didn't last time I checked
|newbie| but parrot does 16:53
whiteknight Parrot has more features than any compiler or language uses
NotFound You can compile to pbc... but maybe the pbc doesn't work stand alone. 16:54
dukeleto |newbie|: howdy
|newbie|: what are you trying to do? 16:55
|newbie| well, somebody tried it already under Linux
and claimed that the method works
I am under Windows.
Coke the usual answer to this question on *nix is that the person only built perl6, but didn't install it. 16:56
s/perl6/rakudo/
|newbie| not sure 16:58
what you are getting at.
NotFound That binary packages are supposed to be used together? 17:00
I guess the rakudo package includes its own parrot.
Coke I'm on windows at work. lemme try. 17:03
|newbie|: did you just install "parrot-win32" ? 17:04
or "rakudoport", or...?
|newbie| there is rakudo package 17:05
and a parrot package
both need to be installed in the same directory 17:06
Coke what is the name of the rakudo package?
|newbie| setup-parrot-3.2.0.exe
and setup-parrot-3.2.0.exe-rakudo-39.exe
17:09 lucian joined, contingencyplan joined
Coke ah, it's buried under the files dir of the parrot-win32 project... downloading... 17:09
it concerns me that you reference both parrot-3.2.0 and parrot-1.4.0 in your script there. 17:11
s/script/nopaste 17:12
where is your "array.p6" file? 17:13
17:14 JimmyZ left
nopaste "coke" at 192.168.1.3 pasted "works with no changes to path here..." (5 lines) at nopaste.snit.ch/39709 17:15
cotto_work Coke: do you have an installed parrot that might be making that work by accident? 17:16
|newbie| it contains this:my $h;$h=8*4;print $h;
that is the content of the file
Coke "which parrot" says no.
so, what happens when you run "perl6.exe /path/to/array.h" ? 17:17
either when c:\\parrot-3.2.0\\bin is in your path, or you specify it directly.
|newbie| nothing special 17:18
it executes properly
Coke cotto_work: er, and which which says D:\\bin\\which.bat, which is going through my %PATH% looking for executable things.
ok. so what is it you're trying to do?
|newbie| convert into pbc and run it as pbc 17:19
Coke compile to pbc?
k.
so, I can use perl6 --target=pir to generate the PIR, but then cannot run the pir (ignoring the compilation to pbc) 17:21
and adding the -L doesn't help, right. 17:22
I have to run to a meeting, but "bug confirmed"
dalek nxed: r941 | NotFound++ | trunk/winxedst0.cpp:
minimal refactor of some op emisions in stage 0
 17:24
mikehh whiteknight: ping 17:25
17:31 dodathome joined
cotto_work benlynn.blogspot.com/2011/04/list-c...-in-c.html (just because) 17:43
17:43 fperrad left
benabik whiteknight: pong (delay: 2h 16m) 17:44
ETIMEOUT :-( 17:47
17:47 plobsing left 17:48 fperrad joined
benabik msg whiteknight Today's a day off for me, but I'll keep an eye out for you. I think it's after the deadline for proposals, so I don't know if I can "officially" edit mine, but plans are always subject to change. :-) 17:53
aloha OK. I'll deliver the message.
whiteknight benabik: I don't know about editing either 17:54
benabik: have you read my blog post from today about the IMCC work?
benabik whiteknight ohai, didn't see you there. ;-) Haven't seen it, no. 17:55
whiteknight: Knew you merged the compreg branch, but hadn't looked at it in detail.
lucian DEADLINE IN 4min! :) 17:56
wait 1h4min
moritz THE END IS NEAR
whiteknight zomg
benabik: with the new refactor merged, it should be possible to replace IMCC with PIRATE and newPOST 17:57
lucian CLOSE ALL WINDOWS. ENSURE TOILET SEATS ARE DOWN. LOCK ALL CHILDREN
whiteknight benabik: an interesting project might be to implement a new Parrot frontend executable with PIRATE instead of IMCC 17:58
more than interesting, it's something on our roadmap
17:58 mtk left 17:59 mtk joined
benabik whiteknight: Hmm. Does sound interesting but also mildly orthogonal to my current proposal. Although I'd guess merging PIRATE into master would require the PAST changes I'm talking about doing. 18:00
whiteknight benabik: not orthogonal, more an extension of your current work
PIRATE needs newPOST to replace IMCC. Once you have that part of it merged, you can follow the project to its logical conclusion
Merge in newPOST, update PIRATE to use it effectively, write a new frontend for Parrot without IMCC 18:01
sorear Next time you break the PBC format, how will you get PIRATE working again? 18:02
whiteknight sorear: We still have IMCC, and it will stay the default for the forseeable future
but we want a second frontend which does not use it
benabik whiteknight: I could try to add it to the tail end of my proposal, but I'd be worried about getting it done in the time allotted. If everything goes well, I could def look at it, but I don't like planning on everything going well. ;-) 18:04
whiteknight I have to take another look at your proposal
benabik whiteknight: Or I could replace the "update POST with more features" with "merge PIRATE", I suppose. :-/ 18:05
whiteknight in the whole grand scheme of things, the reason we want to emit PBC from POST is to allow us to replace IMCC with PIRATE
and, in a wider sense, allow more compilers to avoid IMCC
it's all about killing IMCC 18:06
benabik (Not saying I'm not interested in trying to do it, but don't want to cram too much into my project and leave it half-done if I don't have time when school starts in Fall.)
whiteknight that's the big, ultimate goal
I'm not sure I see a huge benefit in rewriting PAST into NQP. Besides consistancy and readability maybe. I don't think we gain any architectural or performance improvements from that 18:07
moritz we gain hackability.
whiteknight is that lacking in PAST? 18:08
I mean, it's not a fast moving target
18:08 ShaneC joined
whiteknight benabik: I suspect you will be able to translate PAST to NQP in a week or less 18:08
benabik whiteknight: I do tend to be somewhat pessimistic on time estimates. 18:09
whiteknight benabik: okay, that's good to a degree, but if things go faster we want to make sure you have plenty of things to work on to fill time 18:10
there's no thumb twiddling in GSoC
benabik: We probably want to talk to bacek more about it, but if we could get newPOST merged to trunk, get PIRATE working on it, that would be a great start
a new parrot frontend program is a days worth of work with the new API 18:11
cotto_work whiteknight: when did our old cow strings get ripped out?
whiteknight benabik: here is a blog post I wrote on a similar idea: whiteknight.github.com/2011/01/20/p...ntend.html
cotto_work: as part of the immutable strings refactor
dalek TT #2088 created by mikehh++: strange error in t/examples/pod.t
TT #2088: trac.parrot.org/parrot/ticket/2088
whiteknight cotto_work: I don't remember when that was. 2.7ish? 18:12
18:13 mtk left
cotto_work whiteknight: ok 18:13
whiteknight cotto_work: why, are we reconsidering that change? 18:14
cotto_work whiteknight: no, I just want to get a handle on how cow works. 18:15
whiteknight oh, okay. the more I learn about cow, the less I like it 18:16
at least, in a parrot setting
18:17 dmalcolm joined
whiteknight from everything I've seen COW + threads = bad 18:17
18:17 mtk joined
lucian whiteknight: that's a general truth 18:19
benabik whiteknight: I could shrink the "convert" phase down a week and add a week for "create PIRATE-based parrot frontend." Or add it as a "if time allows" deliverable. The end of my proposal is purposefully vague because bacek seemed slightly uncertain about what features are still needed and I thought I'd be somewhat likely to encounter them as I went.
lucian whiteknight: your COW can however be good enough to work with threads
whiteknight benabik: an "if time allows" entry would be ideal
18:19 plobsing joined
cotto_work I'm thinking about it as a way to share variables between m0 contexts 18:20
whiteknight is an m0 context like a thread or a green thread? both? neither? 18:21
moritz wow, why do all those people want to write Pod6 parsers for parrot? 18:22
whiteknight no idea 18:23
it is curious
moritz was it on the parrot ideas page?
whiteknight yes
I suspect last-minute students are trolling the list for something that appears easiest to do
cotto_work whiteknight: it's close to what PARROT_INTERP is now.
moritz could understand it if parrot folks wanted a p5 pod processor, for reducing th p5 dependency
whiteknight cotto_work: okay, so like a parrot thread. we probably don't want COW for that 18:24
lucian whiteknight: from the literature i've read, you can do persistent immutable data, and COW on top
but i don't know if that'd work 18:25
18:25 soh_cah_toa joined
whiteknight lucian: sure, we could do some kind of a proxy over immutable objects to provide something like COW 18:25
lucian so thread A owns pmc1
whiteknight hell, Rosella can do that today
lucian thread B sees pmc1 as immutable
pmc1 uses a persistent data structure
whiteknight the problem with that kind of system is that thread B can't easily communicate changes to pmc1 back to thread A
lucian to modify, thread B gets a clone of pmc1 with COW, and structura sharing 18:26
18:26 davidfetter joined
lucian whiteknight: it can't, must return a new one 18:26
whiteknight and that's what we most need. Sending immutable data from A to B is easy, but sending changes back is hard
lucian: okay, so a message-passing system?
that's fine by me
lucian whiteknight: a bit. do you know clojure?
whiteknight no. but I know other made-up words
frabulate
lucian if your data structures (in this case pmcs) use structural sharing, you can treat them as immutable 18:27
when you return pmc1.1 to thread A, it's transparently diffed over pmc1 (easy with structural sharing)
you then get pmc1.2 in thread A
no memory waste, completely safe, few locks
but it's a bit intrusive (all data with COW must use this system) 18:28
but this system doesn't easily work for certain data structures you might want
like arrays ... 18:29
whiteknight What we really need to do is provide a simple mechanism to share data, and let HLLs built up from there
lucian clojure works around this by "sharding" arrays into trees with a constant depth
i'm quite sure "classical" concurrency primitives will be necessary
threads and locks and monitors and all that evil
necessary to be exposed to HLLs that is 18:30
i'm not sure it can be worked around, even if that'd be very nice
whiteknight yeah, that's the trick. We don't want to provide "The Solution", we want to provide the tools and let HLLs provide solutions 18:31
or extension projects
lucian but as soon as you allow threads with full memory sharing + locks, you're kinda fucked 18:32
can't cooperate with evil like that very well
whiteknight right, that's where I keep coming back to. I don't think we want full data sharing
I would rather have some kind of system that could provide the illusion of sharing, without the headaches 18:33
lucian en.wikipedia.org/wiki/Persistent_data_structure in case you're not familiar
whiteknight: you can, with a little breakage
whiteknight what do you mean breakage?
lucian you need great async APIs and very, very, very fast greenlets
benabik whiteknight: I added a note about a new frontend to deliverables and project details, but left the timeline alone.
whiteknight benabik++
lucian whiteknight: HLLs will introspect the actual treads
can't emulate POSIX threads entirely 18:34
whiteknight lucian: that's basically what I've been thinking about. N:M hybrid threads, cheap greenlets, and message passing
lucian ah, but N:M is HARD
whiteknight not necessarily, especially if we're not sharing data
lucian have you looked at how erlang does it? 18:35
they just have all APIs async + no sharing
whiteknight that's where the idea is self-referential. So long as we have no sharing, we can do N:M scheduling without too much headache
and greenlets are basically parrot continuations, maybe with a little overhead, so that's mostly ready to go
lucian however, you'll need to be able to break the abstraction every now and then
from M1 or something 18:36
whiteknight internally, sure. I don't think the user would ever need it broken
lucian i would hope so, but i'm not sure
after Python3 works (wink wink, nudge nudge), i should have a more informed opinion
whiteknight: there are some videos on clojure's structural sharing, quite interesting 18:37
whiteknight if we have that system, we could pretend to have a more classic system by setting N=M, and providing a library of locks. 18:38
and if we have both a class threading api, and a message-based greenlets API, we should be able to build anything on that
lucian yes, but the classic threading api will leak non-posix-ness 18:39
anyway, it's a very good idea
and it'd make parallelism folks' eyes gleam 18:40
whiteknight I didn't say our classic threads api would be posix-ish 18:43
lucian whiteknight: the cool thing is, with persistent data structures we might end up simulating shared mutable data safely
whiteknight: well, it'd have to be close enough for HLLs to be fooled
whiteknight there's no reason to expect that a high-level VM like Parrot would simply duplicate that low-level standard
lucian: sounds like a very interesting research project. You interesting in gradschool? :) 18:44
lucian whiteknight: is that USspeak for postgraduate?
i am interested in a PhD, yes. few ideas too
whiteknight I keep looking for places to go back for my PhD. 18:45
lucian yeah, i have 1year to do that
(i'll be working in Paraguay for one year, starting this summer)
whiteknight My MS is in EE, but I'm much more interested in software stuff.
Paraguay? That's quite an interesting destination. What are you doing there?
lucian i see. that's an ongoing trend
Activity Central have hired me to work on Sugar activities 18:46
well, haven't signed contracts yet
whiteknight is that going to interfere with GSoC? 18:47
and, are there any good universities in Paraguay?
lucian no, it's after
uh, i don't know. i was sort of planning to come back to the UK
18:48 particle1 joined
whiteknight I saw a draft of Allison's dissertation proposal at one point that was extremely interesting to me 18:50
of course, it would probably be rude to steal it for myself :)
lucian possibly, yes
whiteknight I'm not sure I can think of anything in the world more interesting or personally rewarding than implementing that kind of threading system for Parrot 18:51
that would be killer
lucian heh
18:52 particle left
lucian i could think of a few, ranging from unlikely to UNFRIGGINGPOSSIBLEGOAWAYANDCRYNOW 18:52
whiteknight: this is interesting, but not the one i wanted blip.tv/file/812787 18:53
whiteknight oh, nice 18:54
lucian think it's this one www.mefeedia.com/watch/24163595
carefully watch the persistent data structure bits
whiteknight It seems clojure needs to go on my list of languages to learn
lucian also if you haven't seen clojure before, there are "clojure for lispers" and "clojure for javaers" talks 18:55
yes, it's imo the best lisp out there, closely followed by racket
18:56 |newbie| left
PerlJam woo! Some people are cutting it close with their submissions. 18:57
(gsoc)
whiteknight I have so many topics that I need to research
lucian heh, looks like a blatant python ripoff vimeo.com/11236603 18:58
whiteknight: same, i know 18:59
soh_cah_toa PerlJam: just making some last minute adjustments
benabik Ditto here.
PerlJam soh_cah_toa: yeah, that's fine ... but there have been a couple of new submissions in just the last few minutes.
soh_cah_toa what? really? that's kind of irresponsible 19:00
gsoc is my top priority right now. there's now way i would let something like that go undone until the last minute 19:01
*no
benabik soh_cah_toa: Agreed. I've been treating my GSoC proposal like a job application or research proposal. You don't leave it until the last minute and go "here, pick me." 19:03
soh_cah_toa i know
PerlJam I prefer to give people the benefit of the doubt. There could be all sorts of reasons for such late submissions. It'll all get sorted out in the next week or so. 19:04
plobsing do we even know the people making these submissions? most of the gsocer's I'd consider "legit" have been in this channel for a week or more. 19:05
whiteknight treating GSoC like a job is good. I put mine on my resume, and it did a lot to help me get my first job
soh_cah_toa ohh...really?
whiteknight oh yeah. I didn't do an internship in college, so GSoC was my whole "real world experience" section
soh_cah_toa i suppose you're right b/c they can just go online and see your work 19:06
whiteknight worked with a team, designed and developed new software myself, my work is being used by X people in the real world, etc
KaeseEs "real world experience? *points to github*" - whiteknight, 200x
whiteknight :)
benabik I have contract work and such, but I can't really show off those projects. :-/
whiteknight back in my day, we didn't have github
dukeleto just got access to the OSUOSL Supercell cluster 19:07
whiteknight oh awesome
KaeseEs oi dukeleto i'll try to get some work done on the gsl bindings over the summer even though i'm taking classes instead of doing soc
dukeleto KaeseEs: sounds awesome
19:08 dodathome left
whiteknight KaeseEs++ 19:09
19:10 pjcj left 19:12 dodathome joined
benabik whiteknight: I needed a lot of RAM just to load the github version of that merge diff. Might want to put the warning before the link. Just saying. ;-) 19:26
cotto_work e did
benabik cotto_work: The blog post says "<link> is big. Don't load it without RAM or unless you hate github." I clicked on the link when I ran across it for reference and my computer started bogging down... (Too much crap left open.) 19:28
dukeleto Seems like GSoC student app deadline has passed. 19:30
whiteknight yeah, and not a moment too soon
cotto_work 6 at the last minute 19:31
dukeleto wow!
dukeleto hasn't logged into melange in a while
cotto_work total of 15
benabik All POD parsers?
cotto_work benabik: a couple aren't
dukeleto cotto_work: how many non-overlapping proposals do we have? 19:32
whiteknight I sent out an email this morning to mentors, and we had 11 proposals at that time
dukeleto cotto_work: i.e 2 proposals for POD parser just counts as 1
cotto_work dukeleto: looks like we have 3 19:33
whiteknight yeah, pod is the most interesting thing ever, apparently 19:34
KaeseEs interesting in that the wiki listed it as 2 stars :v
whiteknight What I suspect is that last-minute students are trolling the idea pages looking for easy projects 19:35
what's most annoying is that if those same students had taken 15 minutes to come talk to us, they could have avoided the duplicate, found a different project that would really be beneficial, and have had a much higher chance of getting accepted 19:36
cotto_work whiteknight: not doing that is probably a good indicator
whiteknight that's my thought exactly 19:37
especially if we don't hear a peep from any of those students before the decision deadline
benabik I think they missed the "Would-be student participants discuss application ideas with mentoring organizations" part of the timeline before the application period. 19:38
cotto_work As far as I'm concerned, those students have more to prove than others who've shown the initiative to hang out in #parrot or talk to parrot-dev.
They've still got a chance though.
benabik Although some of my classmates hadn't heard of GSoC until I started mentioning it this week. (Mostly as part of my "ahhh too much to do around midterms" rant.) So giving them some doubt is nice. 19:40
whiteknight cotto_work: exactly right. The students we've been talking to have less unknowns. I *know* that soh_cah_toa and rohit_nsit08 understand their projects, and are familiar with Parrot, and know what's going on
I don't know that about other applicants
er, applicants we haven't talked to 19:41
cotto_work benabik: sure. One of them could well produce a viable POD parser, we just don't know atm.
whiteknight there is always a chance, especially if those students get in here NOW and start talking to us NOW
we can't accept a student sight unseen
cotto_work one of the POD students is on the wiki list of students 19:42
whiteknight right, one of them was on google-melange for a few days and has feedback 19:43
if google gives us 15 slots, no worries
cotto_work I don't know if we could support 15 projects. 19:44
whiteknight maybe not. Definitely not if we have students who need a lot of hand-holding
Some of our students I know are self-sufficient, and others of them I suspect it highly 19:45
darbelo We have at least one proposal claiming not to really have that big a need for a mentor, if that makes you feel better :) 19:46
whiteknight really? which one?
anybody who claims not to need a mentor probably needs it most of all
cotto_work whiteknight: excellent feedback on the sub profiler project. 19:47
whiteknight I'm actually very hopeful about that one. I hope that student does get in touch with us 19:48
I mean, there's potential. It's going to be hard as hell
cotto_work me too, though I'm not sure it'd be a summer's worth of work
whiteknight depends on the student. Can't assume they are all whiz coders
cotto_work true, and parrot guts are a twisty maze of mazes, all alike 19:49
darbelo You are likely to bea eaten by undiscovered and unimagined creatures of dubious existence.
cotto_work darbelo: have you seen any interest in decnum-dynpmcs? 19:51
darbelo If there is, none of it has reached me. Which makes me a bit sad, but not at all surprised. 19:52
cotto_work I'm glad it's part of the ecosystem.
I feel the same way. 19:53
darbelo The number of humans interested it that particular branch of numerical weirdness is small.
cotto_work dukeleto's one of them
but he's known-weird
dukeleto is quite weird
cotto_work: :)
darbelo As am I.
(on both counts...)
benabik whiteknight: I hadn't realized how convoluted IMCC was. Thanks for throwing yourself on that grenade. 19:55
whiteknight benabik: If I spend enough time complaining about something, eventually I need to just suck it up and fix it 19:56
and I've spent plenty of time complaining about IMCC
benabik From the looks of it, you've well earned the right to complain about it. 19:57
tadzik yeah, now when someone says "then do it better" you can say "I did, LOL" :)
cotto_work and we'll all laugh and throw another struct on the fire 19:58
tadzik ( he did it! Now make him complain about calling conventions! ) :P 19:59
whiteknight calling conventions are not nearly so bad as they used to be
I think they can be a hell of a lot better if we use a design that isn't so monolithic
I mean serious, fill_params is a travesty
and slow as can be 20:00
Actually, I bet I could put together a benchmark demo to show how much faster parroy could be without it 20:01
parrot
cotto_work and rakudo wouldn't even notice 20:02
whiteknight If we didn't have get_params opcode at all, and replaced it with a get_sig opcode to return the current sig, the callee could do keyed indexing into the callsig directly to get parameters 20:03
that is what fill_params does now, but in a loop and it has to check every possibility
we can take it out of the loop, and each callee can only search for the things that it knows it needs
we probably still need fill_params for calling methods from C, or calling C-based methods to unpack the signature into a varargs list 20:04
but we could take it out of the PIR invoke hotpath, which is one of the most common
great, now I know what I'm doing this weekend. 20:05
darbelo reviewing GSoC proposals? :)
whiteknight that too
benabik tadzik++ # Getting whiteknight++ to complain about calling conventions :)
NotFound whiteknight: I suppose we can have both.
whiteknight benabik: yeah, like it took him much effort 20:06
benabik whiteknight: Someone still has to have the idea. :-D
whiteknight has to go now. Meeting. 20:07
20:07 whiteknight left
mikehh darbelo: I have played around with it a bit - have a couple of clients who need something like that 20:18
darbelo: although they mostly use C++ type code with the IBM libraries, a nice dynamic language would be good 20:19
darbelo It's a fairly thin wrapper, since the library is already fairly object oriented. 20:20
mikehh darbelo: you need to move it to parrot's git reposirtory :-}
darbelo Good point. I whould probably look into that some time. 20:21
mikehh I like the GMP proposal and I am one of them wierd types who play around with that sort of stuff 20:23
cotto_work We seem to have an unusual population of math nerds. 20:25
mikehh it generally leads to things like parrot and such stuff :-} 20:26
20:32 dodathome left 20:35 dafrito left
darbelo I think that what led me to pick up decnumber wasn't math-nerdness. I saw it as the time as a sort of therapy for the damage that implementing floating point hardware caused to my brain. 20:36
20:37 fperrad left
cotto_work that sounds...ow 20:40
mikehh darbelo: IBM implements it in hardware on the Power series and mainframes 20:41
darbelo mikehh: Yeah. I remember reading about that while preparing for the proposal. 20:42
Decimal math is also very common in COBOL systems, but I tend not to mention it. "COBOL does it" is rarely taken as a good thing by people. 20:44
:)
To be fair, the fp implementation process isn't that traumatic ordinarily, but I was working with seriously bad tools at the time, and the debugging stage was hellish. 20:45
davidfetter decimal math is a very big deal in finance or anything else that counts money 20:46
darbelo Indeed. I had forgotten about the 'telco benchmark' 20:47
20:47 lucian left
darbelo I had plans to throw that at decnum-dynpmcs and see how it fared. 20:48
mikehh decimal arithmetic is very important with certain type of financial institutions 20:51
things like banks, insyrance companies, investment types etc, mybe even gevermint 20:52
mikehh I can't belive I typed that line :-} 20:53
davidfetter tyops to keep mikehh company 20:54
mikehh "a year ago I culdn't even spell ingineer, now I are one" 20:55
NotFound mikehh: I suppose they use it to create global crisis.
mikehh NotFound: all sorts of instruments, hedges, options and such like :-} 20:57
tadzik ano
whoops, ww
21:07 jrtayloriv joined, lucian joined 21:09 ambs left 21:11 lucian left
cotto_work github.com/kevinlawler/kona - suddenly our internals look amazingly good 21:30
I suppose it'd be effective if you could keep the important conventions in your head, but blargh 21:33
bubaflub cotto_work: what is this i don't even 21:34
darbelo I wonder if whitespace's more expensive in his country. I could probably mail him some.
bubaflub darbelo: we should start up a relief effort 21:35
darbelo Or maybe he's surrounded by too many python programmers who are using up all of it.
cotto_work My new goal is to start a project, half of which is written in his style of C and half of which is enterprise-grade java. 21:36
darbelo Having just finished a hideously rushed android app, I think Ive had enough java (of any grade) for a while. 21:37
I can probably help with the C side of things though. 21:38
Heck I'll even get you a free CVS repo for you to host it on :) 21:40
cotto_work I don't trust CVS. 21:41
I'll use differently-named files for version control.
and put it on github
21:41 dafrito joined
darbelo Or maybe we should just use RCS on top of NFS... Those are surely proven technologies by now. 21:41
Distributed network access to source code is important nowadays. 21:43
cotto_work Gah. Some junk at $dayjob went down because nfs is awesome earlier today.
22:09 pjcj joined 22:12 Eduardow left 22:29 rohit_nsit08 left 22:32 particle1 is now known as particle 22:41 darbelo left
bubaflub msg Whiteknight I've been reading your blog posts about Rosella and now i'm sold on it. the project looks great. 22:42
aloha OK. I'll deliver the message.
23:12 bubaflub left 23:19 whiteknight joined
whiteknight good afternoon,#parrot 23:27
23:31 kid51 joined
cotto_work good evening, whiteknight 23:31
whiteknight hello cotto_work, how are you doing?
cotto_work fridayishly 23:32
sorear hello whiteknight 23:37
saw your latest blog post. do you beleive IMCC can be returned to its former genius?
23:37 benabik_ joined
whiteknight sorear: not without taking a hacksaw to the PIR spec 23:38
sorear: the big problem with IMCC is that it's gone from it's humble roots to the everything-for-everyone solution
and I heave to believe that for the same effort we would start from scratch instead of trying to fix IMCC in place 23:39
benabik_ whiteknight: Hence something like pirate? 23:40
whiteknight benabik_: exactly
once we have Lorito, much of Parrot can be rewritten in m0 instead of C. That includes (presumably) the front-end assembler 23:41
plobsing A simplified grammar that didn't have convenience features like heredocs and naked labels would be much easier to parse.
whiteknight PIRATE is that
plobsing: yes, that's true
plobsing in fact, most of IMCC's line number issue stems from heredocs. they just don't fit with lex/yacc, or easily with nqp as bacek witnessed 23:42
although IIRC he did get that working
whiteknight plobsing: if we took out heredocs, naked labels, macros, PASM mode and maybe a few other things, we could clean IMCC up a lot
plobsing see, I don't perceive PASM mode to be much of an issue, and macros are still fairly solidly implemented. 23:43
whiteknight plobsing: I wonder if we could come up with a better syntax for multiline string literals hat was easier to parse
PASM mode isnt much of an issue, but it's something we should be able to abandon at this point
plobsing whiteknight: yeah "line 1\\n line 2 \\n and so on \\n"
whiteknight plobsing: in C#, they have a syntax @" ... "
and that can be multiline
plobsing if you are generating PIR mostly with tools, heredocs are useless anyways.
whiteknight that's true
that's part of the genius that IMCC lost over the years: its focus 23:44
plobsing the whole point of special multiline syntax is to encourage a practice (hand writing code) that we should be actively discouraging in IMCC
whiteknight all these convenience things get added over time, and now IMCC is trash
benabik_ Seems like we need a pir pre-processor 23:45
whiteknight that's probably overkill
we need to start deprecating
either we should slice and dice PIR, or we should create a new assemby language to replace it
benabik_ Heredocs and macros could probably be done with a small purpose built utility. 23:46
cotto_work PIR's macros make the m0 prototyping nicer. I wouldn't mind seeing heredocs go away.
it'd mean rewriting a bunch of test code though. 23:47
NotFound Why on earth do you need heredocs in an assembler? 23:48
cotto_work NotFound: you don't. Discuss.
;)
kid51 If we replace PIR, then what is Parrot? 23:49
What is Parrot if not PIR? 23:50
cotto_work Parrot's a VM that we happen to manipulate through PIR.
kid51 The term VM is used in so many different ways in IT that it's not clear in what sense Parrot is a VM. 23:51
NotFound We can just say its a M.
benabik_ Parrot's main interface would become PBC instead of PIR
no?
kid51 For example, where I work if people say "VM", they mean the sort of thing VMWare sells.
Or like my Linode server. 23:52
cotto_work Parrot's a VM in that sense. It just uses its own instruction set instead of x86 or x86_64
NotFound Long time a go, in a planet not far way, that things were called p-codes. 23:53
23:54 dmalcolm left
kid51 whiteknight: In your blog post you wrote, "IMCC poked directly into the internals of Parrot ..." 23:56
That implies that something *else* constitutes the "internals of Parrot." What is that 'else'?
NotFound Note that we use a preprocessor for heredocs, macros, or whatever, we may need a way to set source line numbers in the generated code, so the small purpose utility puts more work in the back end assembler. 23:57
benabik_ Don't we already have .file and .line annotations? 23:58
sorear NotFound: we already need .annotate for HLLs
NotFound: this "preprocessor" should be thought of as a HLL in its own right, since sane HLLs will target PIR directly
NotFound sorear: then we don't need that preprocessor. 23:59
benabik_ sorear: +1. HumanPIR, Hand-Written PIR
sorear this preprocessor could be called "pirate" or maybe "winxed"
NotFound Then it's not a preprocessor, is a HLL.

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!