Camelia, the Perl 6 bug

IRC log for #parrot, 2011-04-08

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:02 benabik That did, in fact, fail for me.
00:05 bbatha joined #parrot
00:08 takadonet1 joined #parrot
00:12 takadonet1 Can Parrot support reading files  with different 'line' delimiter other then "\n"?
00:12 theory left #parrot
00:14 whiteknight takadonet1: good question
00:14 whiteknight I suspect so, but I've never done that test
00:15 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 takadonet1 I need more then just "\n" :)
00:18 whiteknight IO object, you mean the FileHandle PMC?
00:18 whiteknight or does Rakudo implement something custom?
00:19 takadonet1 whiteknight: something custom I believe
00:19 takadonet1 <--- Rakudo user, not developer
00:19 whiteknight ah, gotcha
00:19 takadonet1 I can look at Perl 6 and understand it very well but PIR.... not so much
00:20 whiteknight well, we'd have to figure out where that particular logic lives
00:20 takadonet1 and that what i'm doing right now
00:20 takadonet1 good old grep :)
00:20 plobsing ack is better
00:21 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)
00:21 takadonet1 i'm just hope it's implemented
00:22 benabik takadonet1: Where are you passing in the "something other than \n"?
00:22 takadonet1 benabik: multi sub lines
00:25 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";
00:25 takadonet1 plobsing: in Rakudo it will be $*FH.input_record_separator() however nyi
00:26 takadonet1 benabik: indeed that is the line
00:26 plobsing not parrot's problem
00:26 benabik takadonet1: Ah, you're trying to remove the NYI problem?
00:26 * benabik misunderstood.
00:26 takadonet1 benabik: that too
00:27 takadonet1 just wonder if parrot support it, if so then I would change it in rakudo
00:32 takadonet1 i think it's hardcoded in parrot :(
00:33 takadonet1 parrot 3.2.0  src/io/api.c line 632
00:34 takadonet1 all well thx guys
00:37 theory joined #parrot
00:38 plobsing takadonet1: um no. Handle has a field called 'record_separator' that is consulted in readline. that's what I told you before.
00:39 plobsing src/io/api.c:632 only applies for StringHandle
00:42 mikehh joined #parrot
00:47 whiteknight holycrap that imcc_compreg_pmc merge diff is huge
00:47 whiteknight that's a pretty big weight off my shoulders
00:48 dalek parrot: 54c4f34 | Whiteknight++ | NEWS:
00:48 dalek parrot: mention IMCC happenings in NEWS
00:48 dalek parrot: review: https://github.com/parrot/parrot/commit/54c4f3425d
00:58 cotto ~
00:58 kid51 left #parrot
01:00 plobsing can we classify the imcc decouple roadmap goal a success now, or are there other criteria that need addressing?
01:02 whiteknight technically, no. It's mostly decoupled, but not completely decoupled
01:02 whiteknight we still only have one libparrot, not a separate libparrot-imcc
01:03 plobsing what else can we do before the deprecation boundary?
01:05 whiteknight that's a very good question
01:05 whiteknight I don't think there are any user-facing changes to come.
01:06 whiteknight 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 whiteknight the parrot.exe frontend is going to handle loading all the necessary libraries
01:06 whiteknight I think we're good for deprecation
01:06 plobsing I thought IMCC was only going to be available *when asked for*
01:10 eternaleye left #parrot
01:10 eternaleye joined #parrot
01:10 dalek parrot: 443ce3a | (Michael Hind)++ | compilers/imcc/reg_alloc.c:
01:10 dalek parrot: fix codetest failure - trailing spaces
01:10 dalek parrot: review: https://github.com/parrot/parrot/commit/443ce3a98e
01:13 whiteknight plobsing: the parrot.exe frontend is the user "Asking for it"
01:13 whiteknight alternate frontends will have different behaviors
01:14 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
01:14 whiteknight that's the same frontend, it will provide the same environment
01:15 plobsing still IMCC availability from NQP is user visible
01:16 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
01:17 whiteknight pbc2exe can be extended with an option to omit it
01:17 whiteknight NotFound: ping
01:32 bbatha left #parrot
01:34 eternaleye left #parrot
01:34 eternaleye joined #parrot
01:38 whiteknight on the bright side, I just figured out why ExceptionHandlers can't be subclassed
01:39 whiteknight Object.pmc--
01:44 cotto why not?
01:48 Tene whiteknight: I don't think that's the only reason, if you found what I think you found.
01:49 Tene ... 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 Tene I haven't even merged my exceptions refactor work.
01:51 whiteknight Tene: That's what I'm working on right now, a rewrite of your exceptions stuff
01:51 Tene whiteknight: nice
01:51 Tene whiteknight: feel free to ask me if you have any questions about it.
01:51 whiteknight where I'm stuck now is a part of it which was added after you started work
01:51 whiteknight the finalize_p opcode is causing me trouble
01:51 whiteknight Tene: don't worry, I will
01:52 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
01:52 whiteknight I already merged in the stuff you did subclassing Exceptions
01:52 whiteknight it's ExceptionHandlers that are causing problems now
01:52 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.
01:52 Tene that's why I didn't merge it before.
01:52 whiteknight yeah, that's what I'm seeing now
01:53 whiteknight Object["proxy"] stores an instance of the superclass to delegate to. Both objects have separate attribute stores and don't sync
01:54 whiteknight 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?
01:54 whiteknight yeah
01:54 Tene Ah.  What for?  What does it use attribute parents for?
01:54 Tene erm
01:54 Tene attributes of the superclass isntance?
01:55 Tene 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
01:55 whiteknight so that's two PMCs for the price of one
01:55 dalek tracwiki: v4 | whiteknight++ | ExceptionRefactor
01:55 dalek tracwiki: add a quick note about why ExceptionHandler cannot be subclassed
01:55 whiteknight or, one PMC for the price of two
01:55 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Exce​ptionRefactor?version=4&amp;action=diff
01:55 whiteknight whichever makes the least sense
01:56 petdance joined #parrot
01:56 Tene like: class A { has $!x; method a { say $!x } }; class B is A { has $!x; method b { say $!x } }
01:57 Tene 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
01:57 Tene so that was getting the Exception attributes, instead of the subclass attributes
01:57 whiteknight right
01:57 whiteknight don't worry if you don't understand it. There's nothing to understand
01:58 whiteknight it's the worst design ever
01:59 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.
02:00 Tene 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
02:00 Tene I've never understood wtf a PMCProxy is
02:00 whiteknight 3 is obviously the best, but is probably the most wok
02:01 whiteknight Tene: it's shit
02:01 whiteknight (that's the short answer) :)
02:01 Tene If I were doing it, I'd do 2.
02:01 whiteknight Tene: yeah, that's where I
02:01 whiteknight 'm leaning
02:02 whiteknight I don't want to play with the object model if we have 6model on the horizon
02:03 whiteknight of course, we need to make sure we don't implement this same insanity when 6model lands
02:04 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:05 whiteknight Tene: right now, ExceptionHandler.set_pointer falls back to Continuation.set_pointer.
02:06 whiteknight Continuation.set_pointer sets both the address and runloop_id attributes
02:06 whiteknight anyway, it's time for bed. we can talk about this more later
02:06 whiteknight goodnight
02:07 whiteknight left #parrot
02:08 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:22 mtk left #parrot
02:29 mtk joined #parrot
02:32 takadonet1 left #parrot
02:33 dngor_ joined #parrot
02:35 sorear +1
02:37 dngor left #parrot
02:54 petdance left #parrot
02:54 hudnix left #parrot
03:00 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:02 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:03 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.
03:03 Tene plobsing: Perhaps.  That's where subclasses of ExceptionHandler come in to play.
03:04 Tene 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
03:05 plobsing 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.
03:06 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.
03:07 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.
03:07 plobsing ie the payload is PMCNULL
03:08 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?
03:10 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:11 Tene 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)?
03:11 Tene plobsing: the other issue is that moving functionality into the payload places restrictions on what can be put in the payload.
03:12 plobsing Tene: how does it restrict the payload?
03:14 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 Tene so, you're right, it's not necessarily a restriction.
03:15 Tene (I hadn't thought of the last option until I was responding)
03:16 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:17 plobsing 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.
03:17 plobsing I realize that getting a backtrace could be tricky.
03:18 plobsing 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 ...
03:18 Tene ... thrown exception?
03:19 Tene 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:20 Tene plobsing: additionally, if we're doing dispatch based on the type of the payload, that has similarly nontrivial interactions with other HLLs.
03:21 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"
03:22 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)
03:22 Tene 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.
03:23 Tene right now, can_handle does several checks because we have just one EH class
03:23 Tene (it skips the checks if none of the filtering attributes are set)
03:23 Tene we can filter based on positive or negative matches on the type attribute, the severity, and I think something else.
03:24 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:25 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 Tene I would not want parrot to have an exception hierarchy that it expected everyone else to conform to.
03:25 plobsing and if I have created an exception type that has no analog in Parrot? what role do I apply then?
03:26 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 Tene I think I must be missing something about your question.
03:27 plobsing so I could dispatch between IOError and NullPointerException, but not from eg: InvalidXMLException and InvalidDBConnectionString
03:28 plobsing because those have either no analog, or the same "Parsing Error" type behaviour
03:29 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 Eduardow left #parrot
03:30 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
03:30 Tene plobsing: I'm looking for specific examples right now... 'sec
03:31 Tene 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
03:31 Tene plobsing: if I want to catch DivideByZero errors, or IO errors, how can I detect those from any language?
03:32 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?
03:32 Tene plobsing: Sure, it certainly could.
03:32 Tene plobsing: that would make it awkward for non-pct languages to interoperate there, though.
03:34 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 plobsing But the case for making core exceptions visible to HLLs does seem legit.
03:35 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:36 plobsing Tene: they likely cannot in general. The general case should be served with check-and-'rethrow'.
03:36 plobsing but for specific exceptions, matching on class is a good idea
03:36 plobsing because many HLLs do that
03:36 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.
03:37 plobsing no. and a static list of exception roles is no better.
03:38 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:39 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 http://www.google-melange.com/gsoc/prop​osal/review/google/gsoc2011/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
03:39 cotto soh_cah_toa, great.
03:39 petdance joined #parrot
03:39 plobsing what are the odds that you will be doing IO operations from different HLLs?
03:40 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?
03:41 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?
03:41 plobsing what we need is an *interoperable* exception system
03:41 petdance There are many args in the funcs that are entirely unused.
03:41 petdance I'm eitehr going to keep them SHIMmed up, or I'd prefer to remove them entirely.
03:42 cotto petdance, start a branch and go nuts
03:42 petdance Not even gonna start a branch. :)
03:42 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.
03:42 cotto or that
03:42 petdance Didn't know if there was future work impending.
03:44 plobsing Tene: that's easily remedied. Use something like what Winxed does - read the constant.pasm and fill your constants appropriately.
03:45 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!"
03:45 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.
03:46 plobsing Tene: yes, I agree the constant types are stupid.
03:46 cotto Tene, sigh
03:46 plobsing and I'm not defending them
03:46 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.
03:46 Tene plobsing: :)
03:47 Tene 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
03:47 Tene plobsing: I expect you feel similarly about exception severity, resumability, etc?
03:48 plobsing I think we need some mechanism for resumability. I'm not really sure what severity is for.
03:48 plobsing but I think that the thrower can work that out and tell parrot's bookkeeping about it.
03:49 plobsing 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"
03:49 Tene plobsing: well, at that point, what's the point of the exception object at all?
03:49 plobsing Tene: if we used prophashes, there would be no exception object.
03:49 plobsing that's the beauty
03:50 plobsing 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
03:52 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 plobsing Tene: I'm not sure we could fully drop exception.pmc. What would core parrot throw?
03:53 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?
03:57 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:58 Tene (printing out a warning to stderr including the text of the exception if present)
03:58 Tene Ahh, right, the "msg" attribute which is also used for get_str and set_str on parrot's exception objects.
03:59 Tene 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?
04:00 Tene ;)
04:02 dalek parrot: e71a7ff | petdance++ | src/p (2 files):
04:02 dalek parrot: consting pointers, and annotating function pointers
04:02 dalek parrot: review: https://github.com/parrot/parrot/commit/e71a7ff591
04:08 petdance anyone else have t/perl/Parrot_Test.t failing?
04:08 petdance I am, but nobody on taptinder is
04:11 cotto petdance, whiteknight or dukeleto might have seen failures earlier today
04:18 petdance and my t/src/extend_vtable.t has been failing for days as well
04:19 plobsing Tene: thanks for explaining subclassable exceptions. I think I now see how they make the state of parrot exceptions better.
04:21 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 Tene Not entirely convinced, though.
04:22 Tene I'm pretty sure that real type information is going to be a better option than the type and severity attributes, though.
04:23 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 #parrot
04:23 plobsing I thought you were talking about me when you said "still not convinced"
04:24 Tene Ahh.
04:24 Tene No, I was saying that I'm not entirely convinced that HLLs subclassing Exception would be bad.
04:26 Tene 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 parrot: ffb5e90 | petdance++ | / (2 files):
04:26 dalek parrot: removed the unused arguments from all the packfile functions and their function pointer types
04:26 dalek parrot: review: https://github.com/parrot/parrot/commit/ffb5e90977
04:27 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.
04:27 Tene It's also possible that there's multiple inter-related concepts here that could be disentangled.
04:28 plobsing if we ever get a JIT with tracing, type-dispatch will be king
04:29 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.
04:30 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 Tene afk; going home
04:31 plobsing Tene: you are the most qualified. be afraid.
04:31 plobsing ;)
04:31 dngor_ left #parrot
04:31 dngor joined #parrot
04:41 petdance Dropping those function pointers makes me happy.
04:47 Eduardow2 joined #parrot
04:50 woosley joined #parrot
04:52 Kulag left #parrot
04:53 Kulag joined #parrot
04:59 Kulag left #parrot
05:06 dalek parrot: ae4f8e1 | petdance++ | / (2 files):
05:06 dalek parrot: properly annotated some function pointers, and cleaned up 16 splint errors
05:06 dalek parrot: review: https://github.com/parrot/parrot/commit/ae4f8e1135
05:08 Eduardow2 is now known as Eduardow
05:08 Kulag joined #parrot
05:14 Kulag left #parrot
05:16 Kulag joined #parrot
05:20 jrtayloriv joined #parrot
05:38 petdance left #parrot
06:17 UltraDM joined #parrot
06:39 ShaneC left #parrot
06:41 theory left #parrot
06:49 ShaneC joined #parrot
06:58 cotto left #parrot
07:31 mj41 joined #parrot
07:35 UltraDM left #parrot
07:49 ShaneC left #parrot
08:20 jevin left #parrot
08:21 contingencyplan left #parrot
08:43 mikehh got an error in t/examples/pod.t - Parse errors: Tests out of sequence.  Found (336) but expected (335)...
08:43 jrtayloriv left #parrot
08:44 mikehh never seen this before - Displayed the first 5 of 279 TAP syntax errors.
08:45 mikehh Re-run prove with the -p option to see them all.
08:48 mikehh running prove -p t/examples/pod.t - t/examples/pod.t .. Failed 1/613 subtests ->
08:48 mikehh Parse errors: Tests out of sequence.  Found (336) but expected (335)
08:49 mikehh Tests out of sequence.  Found (337) but expected (336)
08:49 mikehh then lists up to
08:49 mikehh Tests out of sequence.  Found (613) but expected (612)
08:49 mikehh Bad plan.  You planned 613 tests but ran 612.
08:51 mikehh the Parse errors: etc. was in the Test Summary Report
09:07 Kulag left #parrot
09:11 Kulag joined #parrot
09:39 JimmyZ joined #parrot
09:39 JimmyZ left #parrot
09:47 mikehh left #parrot
09:55 woosley left #parrot
10:10 mtk left #parrot
10:16 mtk joined #parrot
10:56 bacek left #parrot
11:32 mikehh joined #parrot
11:38 darbelo joined #parrot
11:54 darbelo left #parrot
11:55 Patterner left #parrot
12:01 Psyche^ joined #parrot
12:01 Psyche^ is now known as Patterner
12:02 UltraDM joined #parrot
12:10 bubaflub joined #parrot
12:39 plobsing left #parrot
13:06 ambs joined #parrot
13:08 whiteknight joined #parrot
13:16 whiteknight good morning, #parrot
13:25 bubaflub morning whiteknight
13:25 darbelo joined #parrot
13:47 hudnix joined #parrot
13:48 Eduardow left #parrot
13:49 Eduardow joined #parrot
13:52 JimmyZ joined #parrot
14:01 whiteknight hello  bubaflub, how are you today?
14:01 bubaflub whiteknight: not bad, a little tired but workin' nonetheless
14:01 bubaflub whiteknight: you?
14:02 whiteknight pretty damn good, actually. Got a full night of sleep, and I've finally merged in my huge imcc refactors branch
14:03 JimmyZ whiteknight++ for huage mcc refactors branch
14:06 NotFound whiteknight: pong
14:07 NotFound (pong from the past)
14:09 bubaflub whiteknight: i saw that.  need any testing? i've got Mac OS X 10.6
14:12 JimmyZ tests are always welcome
14:18 darbelo left #parrot
14:18 darbelo joined #parrot
14:22 moritz last call for GSOC proposals: about 4 hours left until submission deadline
14:28 whiteknight NotFound: I was digging into problems with the finalize opcode, but I figured out what was going wrong
14:29 whiteknight NotFound: so, unpong
14:32 NotFound Ok
14:42 JimmyZ left #parrot
15:05 theory joined #parrot
15:09 dod left #parrot
15:22 whiteknight benabik: ping
15:27 mj41 left #parrot
15:28 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 #parrot
15:39 cotto joined #parrot
15:41 PerlJam whiteknight:  re Java bytecode for Parrot proposal, it's at the gist: https://gist.github.com/889846
15:41 bacek joined #parrot
15:42 whiteknight PerlJam: okay, but we're getting close to the deadline when it needs to be on the google-melange website
15:43 whiteknight I would hate to see the proposal get screwed up because of the deadline
15:45 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:50 NotFound PerlJam: I don't know but I guess a contest have its rules.
15:51 PerlJam NotFound: I guess I'm more a "spirit of the law" than a "letter of the law" kind of person then.
15:52 NotFound PerlJam: a deadline is kinda letter.
15:53 NotFound Anyway, both the spirit and the letter come from google, not from us.
15:58 plobsing joined #parrot
16:02 JimmyZ joined #parrot
16:04 rohit_nsit08 joined #parrot
16:04 rohit_nsit08 hello #parrot
16:04 whiteknight hello rohit_nsit08
16:05 nnunley joined #parrot
16:05 rohit_nsit08 whiteknight: so today is the last day for the proposal submission :-)
16:06 rohit_nsit08 I've made some more improvements in mine and added the javascript object model in it
16:06 rohit_nsit08 whiteknight: how will students know about their status ?
16:07 |newbie| joined #parrot
16:07 |newbie| hi
16:07 PerlJam hello |newbie|
16:08 |newbie| nto os new
16:08 |newbie| not so new
16:08 |newbie| load_language" couldn't find a compiler module for the language 'perl6'
16:08 |newbie| Could someone help?
16:08 |newbie| What path do I need to set?
16:08 |newbie| What is it looking for?
16:11 |newbie| this is what is given back by parrot.
16:17 cotto_work ~
16:34 whiteknight rohit_nsit08: we make comments if there is anything to change. Your proposal is good right now :)
16:35 whiteknight |newbie| do you have perl6 compiled and available on your machine?
16:36 |newbie| yes
16:36 whiteknight |newbie|: where is the .pbc file loaded? Do you know where it is on your machine?
16:36 |newbie| which one?
16:36 |newbie| yes
16:36 whiteknight |newbie|: the perl6.pbc file
16:36 |newbie| yes
16:37 whiteknight |newbie|: you should be able to use the -L option to parrot to add in a new search path
16:37 whiteknight parrot -L/my/path/to/perl6.pbc/ myprogram.whatever
16:38 |newbie| no space after L?
16:38 whiteknight I don't think it's necessary
16:38 |newbie| it does not make any difference, anyway
16:38 whiteknight weird
16:39 whiteknight |newbie|: can you nopaste the code you are running and the error message you are getting?
16:39 whiteknight aloha, nopaste?
16:39 aloha whiteknight: nopaste is is http://nopaste.snit.ch (works with the script in $_PARROT/tools/dev/nopaste.pl)
16:42 cotto_work |newbie|: what's the process you went through to get Rakudo onto your system?
16:43 |newbie| http://nopaste.snit.ch/39705.
16:43 |newbie| I got the binaires
16:43 |newbie| from sourceforge
16:45 dukeleto ~~
16:45 * Coke boggles. we have binaries on SF?
16:46 cotto_work I think rurban provides them.
16:46 whiteknight yeah, that makes me nervous
16:46 whiteknight are they current?
16:46 cotto_work or fperrad
16:46 whiteknight fperrad was doing it for a while I know
16:46 |newbie| 3.2.0
16:46 whiteknight well I'll be damned
16:46 whiteknight fperrad++
16:47 |newbie| 3.2.0 , is it current version?
16:47 cotto_work seen fperrad
16:47 aloha fperrad was last seen in #parrot 1 days 1 hours ago joining the channel.
16:49 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 whiteknight I suspect Parrot is doing something weird with search paths on windows
16:50 |newbie| it does not help
16:51 whiteknight blah. Damn
16:51 whiteknight |newbie|: what are you working on?
16:51 plobsing perhaps parrot was compiled with weird paths. parrot_config libdir should show where libraries are expected.
16:51 |newbie| just trying to measure the execution speed of Perl6 program
16:52 |newbie| which is compiled into pbc
16:52 plobsing I don't think Rakudo supports compilation to PBC
16:52 plobsing it didn't last time I checked
16:53 |newbie| but parrot does
16:53 whiteknight Parrot has more features than any compiler or language uses
16:54 NotFound You can compile to pbc... but maybe the pbc doesn't work stand alone.
16:54 dukeleto |newbie|: howdy
16:55 dukeleto |newbie|: what are you trying to do?
16:55 |newbie| well, somebody tried it already under Linux
16:55 |newbie| and claimed that the method works
16:55 |newbie| I am under Windows.
16:56 Coke the usual answer to this question on *nix is that the person only built perl6, but didn't install it.
16:56 Coke s/perl6/rakudo/
16:58 |newbie| not sure
16:58 |newbie| what you are getting at.
17:00 NotFound That binary packages are supposed to be used together?
17:00 NotFound I guess the rakudo package includes its own parrot.
17:03 Coke I'm on windows at work. lemme try.
17:04 Coke |newbie|: did you just install "parrot-win32" ?
17:04 Coke or "rakudoport", or...?
17:05 |newbie| there is rakudo package
17:05 |newbie| and a parrot package
17:06 |newbie| both need to be installed in the same directory
17:06 Coke what is the name of the rakudo package?
17:06 |newbie| setup-parrot-3.2.0.exe
17:06 |newbie| and  setup-parrot-3.2.0.exe-rakudo-39.exe
17:09 lucian joined #parrot
17:09 contingencyplan joined #parrot
17:09 Coke ah, it's buried under the files dir of the parrot-win32 project... downloading...
17:11 Coke it concerns me that you reference both parrot-3.2.0 and parrot-1.4.0 in your script there.
17:12 Coke s/script/nopaste
17:13 Coke where is your "array.p6" file?
17:14 JimmyZ left #parrot
17:15 nopaste "coke" at 192.168.1.3 pasted "works with no changes to path here..." (5 lines) at http://nopaste.snit.ch/39709
17:16 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;
17:16 |newbie| that is the content of the file
17:16 Coke "which parrot" says no.
17:17 Coke so, what happens when you run "perl6.exe /path/to/array.h" ?
17:17 Coke either when c:\parrot-3.2.0\bin is in your path, or you specify it directly.
17:18 |newbie| nothing special
17:18 |newbie| it executes properly
17:18 Coke cotto_work: er, and which which says D:\bin\which.bat, which is going through my %PATH% looking for executable things.
17:18 Coke ok. so what is it you're trying to do?
17:19 |newbie| convert into pbc and run it as pbc
17:19 Coke compile to pbc?
17:19 Coke k.
17:21 Coke so, I can use perl6 --target=pir to generate the PIR, but then cannot run the pir (ignoring the compilation to pbc)
17:22 Coke and adding the -L doesn't help, right.
17:22 Coke I have to run to a meeting, but "bug confirmed"
17:24 dalek winxed: r941 | NotFound++ | trunk/winxedst0.cpp:
17:24 dalek winxed: minimal refactor of some op emisions in stage 0
17:24 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=941
17:25 mikehh whiteknight: ping
17:31 dodathome joined #parrot
17:43 cotto_work http://benlynn.blogspot.com/2011/​04/list-comprehensions-in-c.html (just because)
17:43 fperrad left #parrot
17:44 benabik whiteknight: pong (delay: 2h 16m)
17:47 benabik ETIMEOUT  :-(
17:47 plobsing left #parrot
17:48 fperrad joined #parrot
17:53 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.
17:54 whiteknight benabik: I don't know about editing either
17:54 whiteknight benabik: have you read my blog post from today about the IMCC work?
17:55 benabik whiteknight ohai, didn't see you there. ;-)  Haven't seen it, no.
17:55 benabik whiteknight: Knew you merged the compreg branch, but hadn't looked at it in detail.
17:56 lucian DEADLINE IN 4min! :)
17:56 lucian wait 1h4min
17:56 moritz THE END IS NEAR
17:56 whiteknight zomg
17:57 whiteknight 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
17:58 whiteknight benabik: an interesting project might be to implement a new Parrot frontend executable with PIRATE instead of IMCC
17:58 whiteknight more than interesting, it's something on our roadmap
17:58 mtk left #parrot
17:59 mtk joined #parrot
18:00 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
18:00 whiteknight PIRATE needs newPOST to replace IMCC. Once you have that part of it merged, you can follow the project to its logical conclusion
18:01 whiteknight Merge in newPOST, update PIRATE to use it effectively, write a new frontend for Parrot without IMCC
18:02 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
18:02 whiteknight but we want a second frontend which does not use it
18:04 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
18:05 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
18:05 whiteknight and, in a wider sense, allow more compilers to avoid IMCC
18:06 whiteknight 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.)
18:06 whiteknight that's the big, ultimate goal
18:07 whiteknight 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.
18:08 whiteknight is that lacking in PAST?
18:08 whiteknight I mean, it's not a fast moving target
18:08 ShaneC joined #parrot
18:08 whiteknight benabik: I suspect you will be able to translate PAST to NQP in a week or less
18:09 benabik whiteknight: I do tend to be somewhat pessimistic on time estimates.
18:10 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 whiteknight there's no thumb twiddling in GSoC
18:10 whiteknight 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
18:11 whiteknight 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?
18:11 whiteknight benabik: here is a blog post I wrote on a similar idea: http://whiteknight.github.com/2011/01/​20/parrot_in_parrot_new_frontend.html
18:11 whiteknight cotto_work: as part of the immutable strings refactor
18:11 dalek TT #2088 created by mikehh++: strange error in t/examples/pod.t
18:11 dalek TT #2088: http://trac.parrot.org/parrot/ticket/2088
18:12 whiteknight cotto_work: I don't remember when that was. 2.7ish?
18:13 mtk left #parrot
18:13 cotto_work whiteknight: ok
18:14 whiteknight cotto_work: why, are we reconsidering that change?
18:15 cotto_work whiteknight: no, I just want to get a handle on how cow works.
18:16 whiteknight oh, okay. the more I learn about cow, the less I like it
18:16 whiteknight at least, in a parrot setting
18:17 dmalcolm joined #parrot
18:17 whiteknight from everything I've seen COW + threads = bad
18:17 mtk joined #parrot
18:19 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.
18:19 lucian whiteknight: your COW can however be good enough to work with threads
18:19 whiteknight benabik: an "if time allows" entry would be ideal
18:19 plobsing joined #parrot
18:20 cotto_work I'm thinking about it as a way to share variables between m0 contexts
18:21 whiteknight is an m0 context like a thread or a green thread? both? neither?
18:22 moritz wow, why do all those people want to write Pod6 parsers for parrot?
18:23 whiteknight no idea
18:23 whiteknight it is curious
18:23 moritz was it on the parrot ideas page?
18:23 whiteknight yes
18:23 whiteknight I suspect last-minute students are trolling the list for something that appears easiest to do
18:23 cotto_work whiteknight: it's close to what PARROT_INTERP is now.
18:23 * moritz could understand it if parrot folks wanted a p5 pod processor, for reducing th p5 dependency
18:24 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
18:25 lucian but i don't know if that'd work
18:25 soh_cah_toa joined #parrot
18:25 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
18:25 whiteknight hell, Rosella can do that today
18:25 lucian thread B sees pmc1 as immutable
18:25 lucian pmc1 uses a persistent data structure
18:25 whiteknight the problem with that kind of system is that thread B can't easily communicate changes to pmc1 back to thread A
18:26 lucian to modify, thread B gets a clone of pmc1 with COW, and structura sharing
18:26 davidfetter joined #parrot
18:26 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
18:26 whiteknight lucian: okay, so a message-passing system?
18:26 whiteknight that's fine by me
18:26 lucian whiteknight: a bit. do you know clojure?
18:26 whiteknight no. but I know other made-up words
18:26 whiteknight frabulate
18:27 lucian if your data structures (in this case pmcs) use structural sharing, you can treat them as immutable
18:27 lucian when you return pmc1.1 to thread A, it's transparently diffed over pmc1 (easy with structural sharing)
18:27 lucian you then get pmc1.2 in thread A
18:27 lucian no memory waste, completely safe, few locks
18:28 lucian but it's a bit intrusive (all data with COW must use this system)
18:28 lucian but this system doesn't easily work for certain data structures you might want
18:29 lucian 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
18:29 lucian clojure works around this by "sharding" arrays into trees with a constant depth
18:29 lucian i'm quite sure "classical" concurrency primitives will be necessary
18:29 lucian threads and locks and monitors and all that evil
18:30 lucian necessary to be exposed to HLLs that is
18:30 lucian i'm not sure it can be worked around, even if that'd be very nice
18:31 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 whiteknight or extension projects
18:32 lucian but as soon as you allow threads with full memory sharing + locks, you're kinda fucked
18:32 lucian can't cooperate with evil like that very well
18:32 whiteknight right, that's where I keep coming back to. I don't think we want full data sharing
18:33 whiteknight I would rather have some kind of system that could provide the illusion of sharing, without the headaches
18:33 lucian http://en.wikipedia.org/wik​i/Persistent_data_structure in case you're not familiar
18:33 lucian whiteknight: you can, with a little breakage
18:33 whiteknight what do you mean breakage?
18:33 lucian you need great async APIs and very, very, very fast greenlets
18:33 benabik whiteknight: I added a note about a new frontend to deliverables and project details, but left the timeline alone.
18:33 whiteknight benabik++
18:33 lucian whiteknight: HLLs will introspect the actual treads
18:34 lucian 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
18:34 lucian ah, but N:M is HARD
18:34 whiteknight not necessarily, especially if we're not sharing data
18:35 lucian have you looked at how erlang does it?
18:35 lucian they just have all APIs async + no sharing
18:35 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
18:35 whiteknight and greenlets are basically parrot continuations, maybe with a little overhead, so that's mostly ready to go
18:35 lucian however, you'll need to be able to break the abstraction every now and then
18:36 lucian from M1 or something
18:36 whiteknight internally, sure. I don't think the user would ever need it broken
18:36 lucian i would hope so, but i'm not sure
18:36 lucian after Python3 works (wink wink, nudge nudge), i should have a more informed opinion
18:37 lucian whiteknight: there are some videos on clojure's structural sharing, quite interesting
18:38 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 whiteknight and if we have both a class threading api, and a message-based greenlets API, we should be able to build anything on that
18:39 lucian yes, but the classic threading api will leak non-posix-ness
18:39 lucian anyway, it's a very good idea
18:40 lucian and it'd make parallelism folks' eyes gleam
18:43 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
18:43 lucian whiteknight: well, it'd have to be close enough for HLLs to be fooled
18:43 whiteknight there's no reason to expect that a high-level VM like Parrot would simply duplicate that low-level standard
18:44 whiteknight lucian: sounds like a very interesting research project. You interesting in gradschool? :)
18:44 lucian whiteknight: is that USspeak for postgraduate?
18:44 lucian i am interested in a PhD, yes. few ideas too
18:45 whiteknight I keep looking for places to go back for my PhD.
18:45 lucian yeah, i have 1year to do that
18:45 lucian (i'll be working in Paraguay for one year, starting this summer)
18:45 whiteknight My MS is in EE, but I'm much more interested in software stuff.
18:45 whiteknight Paraguay? That's quite an interesting destination. What are you doing there?
18:45 lucian i see. that's an ongoing trend
18:46 lucian Activity Central have hired me to work on Sugar activities
18:46 lucian well, haven't signed contracts yet
18:47 whiteknight is that going to interfere with GSoC?
18:47 whiteknight and, are there any good universities in Paraguay?
18:47 lucian no, it's after
18:47 lucian uh, i don't know. i was sort of planning to come back to the UK
18:48 particle1 joined #parrot
18:50 whiteknight I saw a draft of Allison's dissertation proposal at one point that was extremely interesting to me
18:50 whiteknight of course, it would probably be rude to steal it for myself :)
18:50 lucian possibly, yes
18:51 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 whiteknight that would be killer
18:51 lucian heh
18:52 particle left #parrot
18:52 lucian i could think of a few, ranging from unlikely to UNFRIGGINGPOSSIBLEGOAWAYANDCRYNOW
18:53 lucian whiteknight: this is interesting, but not the one i wanted http://blip.tv/file/812787
18:54 whiteknight oh, nice
18:54 lucian think it's this one http://www.mefeedia.com/watch/24163595
18:54 lucian carefully watch the persistent data structure bits
18:54 whiteknight It seems clojure needs to go on my list of languages to learn
18:55 lucian also if you haven't seen clojure before, there are "clojure for lispers" and "clojure for javaers" talks
18:55 lucian yes, it's imo the best lisp out there, closely followed by racket
18:56 |newbie| left #parrot
18:57 PerlJam woo!  Some people are cutting it close with their submissions.
18:57 PerlJam (gsoc)
18:57 whiteknight I have so many topics that I need to research
18:58 lucian heh, looks like a blatant python ripoff http://vimeo.com/11236603
18:59 lucian whiteknight: same, i know
18:59 soh_cah_toa PerlJam: just making some last minute adjustments
18:59 benabik Ditto here.
18:59 PerlJam soh_cah_toa: yeah, that's fine ... but there have been a couple of new submissions in just the last few minutes.
19:00 soh_cah_toa what? really? that's kind of irresponsible
19:01 soh_cah_toa 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 soh_cah_toa *no
19:03 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
19:04 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:05 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
19:05 soh_cah_toa ohh...really?
19:05 whiteknight oh yeah. I didn't do an internship in college, so GSoC was my whole "real world experience" section
19:06 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
19:06 KaeseEs "real world experience? *points to github*" - whiteknight, 200x
19:06 whiteknight :)
19:06 benabik I have contract work and such, but I can't really show off those projects. :-/
19:06 whiteknight back in my day, we didn't have github
19:07 * dukeleto just got access to the OSUOSL Supercell cluster
19:07 whiteknight oh awesome
19:07 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
19:07 dukeleto KaeseEs: sounds awesome
19:08 dodathome left #parrot
19:09 whiteknight KaeseEs++
19:10 pjcj left #parrot
19:12 dodathome joined #parrot
19:26 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
19:28 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:30 dukeleto Seems like GSoC student app deadline has passed.
19:30 whiteknight yeah, and not a moment too soon
19:31 cotto_work 6 at the last minute
19:31 dukeleto wow!
19:31 * dukeleto hasn't logged into melange in a while
19:31 cotto_work total of 15
19:31 benabik All POD parsers?
19:31 cotto_work benabik: a couple aren't
19:32 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
19:32 dukeleto cotto_work: i.e 2 proposals for POD parser just counts as 1
19:33 cotto_work dukeleto: looks like we have 3
19:34 whiteknight yeah, pod is the most interesting thing ever, apparently
19:34 KaeseEs interesting in that the wiki listed it as 2 stars :v
19:35 whiteknight What I suspect is that last-minute students are trolling the idea pages looking for easy projects
19:36 whiteknight 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
19:37 whiteknight that's my thought exactly
19:37 whiteknight especially if we don't hear a peep from any of those students before the decision deadline
19:38 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.
19:38 cotto_work They've still got a chance though.
19:40 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
19:40 whiteknight I don't know that about other applicants
19:41 whiteknight 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.
19:41 whiteknight there is always a chance, especially if those students get in here NOW and start talking to us NOW
19:41 whiteknight we can't accept a student sight unseen
19:42 cotto_work one of the POD students is on the wiki list of students
19:43 whiteknight right, one of them was on google-melange for a few days and has feedback
19:43 whiteknight if google gives us 15 slots, no worries
19:44 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
19:45 whiteknight Some of our students I know are self-sufficient, and others of them I suspect it highly
19:46 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?
19:46 whiteknight anybody who claims not to need a mentor probably needs it most of all
19:47 cotto_work whiteknight: excellent feedback on the sub profiler project.
19:48 whiteknight I'm actually very hopeful about that one. I hope that student does get in touch with us
19:48 whiteknight I mean, there's potential. It's going to be hard as hell
19:48 cotto_work me too, though I'm not sure it'd be a summer's worth of work
19:48 whiteknight depends on the student. Can't assume they are all whiz coders
19:49 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.
19:51 cotto_work darbelo: have you seen any interest in decnum-dynpmcs?
19:52 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.
19:53 cotto_work I feel the same way.
19:53 darbelo The number of humans interested it that particular branch of numerical weirdness is small.
19:53 cotto_work dukeleto's one of them
19:53 cotto_work but he's known-weird
19:53 * dukeleto is quite weird
19:53 dukeleto cotto_work: :)
19:53 darbelo As am I.
19:53 darbelo (on both counts...)
19:55 benabik whiteknight: I hadn't realized how convoluted IMCC was.  Thanks for throwing yourself on that grenade.
19:56 whiteknight benabik: If I spend enough time complaining about something, eventually I need to just suck it up and fix it
19:56 whiteknight and I've spent plenty of time complaining about IMCC
19:57 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" :)
19:58 cotto_work and we'll all laugh and throw another struct on the fire
19:59 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
19:59 whiteknight I think they can be a hell of a lot better if we use a design that isn't so monolithic
19:59 whiteknight I mean serious, fill_params is a travesty
20:00 whiteknight and slow as can be
20:01 whiteknight Actually, I bet I could put together a benchmark demo to show how much faster parroy could be without it
20:01 whiteknight parrot
20:02 cotto_work and rakudo wouldn't even notice
20:03 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 whiteknight that is what fill_params does now, but in a loop and it has to check every possibility
20:03 whiteknight we can take it out of the loop, and each callee can only search for the things that it knows it needs
20:04 whiteknight 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 whiteknight but we could take it out of the PIR invoke hotpath, which is one of the most common
20:05 whiteknight great, now I know what I'm doing this weekend.
20:05 darbelo reviewing GSoC proposals? :)
20:05 whiteknight that too
20:05 benabik tadzik++ # Getting whiteknight++ to complain about calling conventions :)
20:05 NotFound whiteknight: I suppose we can have both.
20:06 whiteknight benabik: yeah, like it took him much effort
20:06 benabik whiteknight: Someone still has to have the idea.  :-D
20:07 * whiteknight has to go now. Meeting.
20:07 whiteknight left #parrot
20:18 mikehh darbelo: I have played around with it a bit - have a couple of clients who need something like that
20:19 mikehh darbelo: although they mostly use C++ type code with the IBM libraries, a nice dynamic language would be good
20:20 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 :-}
20:21 darbelo Good point. I whould probably look into that some time.
20:23 mikehh I like the GMP proposal and I am one of them wierd types who play around with that sort of stuff
20:25 cotto_work We seem to have an unusual population of math nerds.
20:26 mikehh it generally leads to things like parrot and such stuff :-}
20:32 dodathome left #parrot
20:35 dafrito left #parrot
20:36 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:37 fperrad left #parrot
20:40 cotto_work that sounds...ow
20:41 mikehh darbelo: IBM implements it in hardware on the Power series and mainframes
20:42 darbelo mikehh: Yeah. I remember reading about that while preparing for the proposal.
20:44 darbelo 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 darbelo :)
20:45 darbelo 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:46 davidfetter decimal math is a very big deal in finance or anything else that counts money
20:47 darbelo Indeed. I had forgotten about the 'telco benchmark'
20:47 lucian left #parrot
20:48 darbelo I had plans to throw that at decnum-dynpmcs and see how it fared.
20:51 mikehh decimal arithmetic is very important with certain type of financial institutions
20:52 mikehh things like banks, insyrance companies, investment types etc, mybe even gevermint
20:53 * mikehh I can't belive I typed that line :-}
20:54 * davidfetter tyops to keep mikehh company
20:55 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.
20:57 mikehh NotFound: all sorts of instruments, hedges, options and such like :-}
20:57 tadzik ano
20:57 tadzik whoops, ww
21:07 jrtayloriv joined #parrot
21:07 lucian joined #parrot
21:09 ambs left #parrot
21:11 lucian left #parrot
21:30 cotto_work https://github.com/kevinlawler/kona - suddenly our internals look amazingly good
21:33 cotto_work I suppose it'd be effective if you could keep the important conventions in your head, but blargh
21:34 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.
21:35 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.
21:36 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:37 darbelo Having just finished a hideously rushed android app, I think Ive had enough java (of any grade) for a while.
21:38 darbelo I can probably help with the C side of things though.
21:40 darbelo Heck I'll even get you a free CVS repo for you to host it on :)
21:41 cotto_work I don't trust CVS.
21:41 cotto_work I'll use differently-named files for version control.
21:41 cotto_work and put it on github
21:41 dafrito joined #parrot
21:41 darbelo Or maybe we should just use RCS on top of NFS... Those are surely proven technologies by now.
21:43 darbelo 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 #parrot
22:12 Eduardow left #parrot
22:29 rohit_nsit08 left #parrot
22:32 particle1 is now known as particle
22:41 darbelo left #parrot
22:42 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 #parrot
23:19 whiteknight joined #parrot
23:27 whiteknight good afternoon,#parrot
23:31 kid51 joined #parrot
23:31 cotto_work good evening, whiteknight
23:31 whiteknight hello cotto_work, how are you doing?
23:32 cotto_work fridayishly
23:37 sorear hello whiteknight
23:37 sorear saw your latest blog post.  do you beleive IMCC can be returned to its former genius?
23:37 benabik_ joined #parrot
23:38 whiteknight sorear: not without taking a hacksaw to the PIR spec
23:38 whiteknight sorear: the big problem with IMCC is that it's gone from it's humble roots to the everything-for-everyone solution
23:39 whiteknight and I heave to believe that for the same effort we would start from scratch instead of trying to fix IMCC in place
23:40 benabik_ whiteknight: Hence something like pirate?
23:40 whiteknight benabik_: exactly
23:41 whiteknight 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.
23:41 whiteknight PIRATE is that
23:41 whiteknight plobsing: yes, that's true
23:42 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 plobsing although IIRC he did get that working
23:42 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
23:43 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
23:43 whiteknight PASM mode isnt much of an issue, but it's something we should be able to abandon at this point
23:43 plobsing whiteknight: yeah "line 1\n line 2 \n and so on \n"
23:43 whiteknight plobsing: in C#, they have a syntax @" ... "
23:43 whiteknight and that can be multiline
23:43 plobsing if you are generating PIR mostly with tools, heredocs are useless anyways.
23:43 whiteknight that's true
23:44 whiteknight 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
23:44 whiteknight all these convenience things get added over time, and now IMCC is trash
23:45 benabik_ Seems like we need a pir pre-processor
23:45 whiteknight that's probably overkill
23:45 whiteknight we need to start deprecating
23:45 whiteknight either we should slice and dice PIR, or we should create a new assemby language to replace it
23:46 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.
23:47 cotto_work it'd mean rewriting a bunch of test code though.
23:48 NotFound Why on earth do you need heredocs in an assembler?
23:48 cotto_work NotFound: you don't.  Discuss.
23:48 cotto_work ;)
23:49 kid51 If we replace PIR, then what is Parrot?
23:50 kid51 What is Parrot if not PIR?
23:50 cotto_work Parrot's a VM that we happen to manipulate through PIR.
23:51 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.
23:51 benabik_ Parrot's main interface would become PBC instead of PIR
23:51 benabik_ no?
23:51 kid51 For example, where I work if people say "VM", they mean the sort of thing VMWare sells.
23:52 kid51 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
23:53 NotFound Long time a go, in a planet not far way, that things were called p-codes.
23:54 dmalcolm left #parrot
23:56 kid51 whiteknight: In your blog post you wrote, "IMCC poked directly into the internals of Parrot ..."
23:56 kid51 That implies that something *else* constitutes the "internals of Parrot."  What is that 'else'?
23:57 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:58 benabik_ Don't we already have .file and .line annotations?
23:58 sorear NotFound: we already need .annotate for HLLs
23:58 sorear NotFound: this "preprocessor" should be thought of as a HLL in its own right, since sane HLLs will target PIR directly
23:59 NotFound sorear: then we don't need that preprocessor.
23:59 benabik_ sorear: +1. HumanPIR, Hand-Written PIR
23:59 sorear this preprocessor could be called "pirate" or maybe "winxed"
23:59 NotFound Then it's not a preprocessor, is a HLL.

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced