Camelia, the Perl 6 bug

IRC log for #parrot, 2009-05-31

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 Infinoid Ok, I've increased my sample size, and... Eh.  It's a wash, no regressions but nothing to write home about either.
00:03 bacek joined #parrot
00:05 jonathan *nod*
00:05 jonathan OK, I need sleep...night
00:28 bacek good night jonathan.
00:28 Austin_Hastings Is there some known behavior (possibly involving exception handlers) that would cause part of a stack trace to go missing when an error occurs?
00:29 bacek good localtime() everyone else
00:29 Austin_Hastings Good morning, Bacek.
00:31 Austin_Hastings Whoops. Never mind. PEBCAK.
00:36 bacek Infinoid: I can't spot what's wrong with t/pmc/annotations.t...
00:51 skids joined #parrot
01:03 Infinoid ok, thanks for checking anyway
01:03 Infinoid I'll probably not have time to dig into it until next week, but I'll see what I can do
01:03 Infinoid since it's intermittant, I guess it must be a race condition somewhere
01:15 ZeroForce joined #parrot
01:20 eternaleye joined #parrot
01:33 Zak joined #parrot
02:06 Theory joined #parrot
02:13 eternaleye joined #parrot
02:35 particle joined #parrot
02:35 whoppix joined #parrot
02:37 zak_ joined #parrot
02:46 snarkyboojum left #parrot
02:47 snarkyboojum joined #parrot
02:47 snarkyboojum left #parrot
02:48 janus joined #parrot
02:57 Ademan joined #parrot
03:01 Whiteknight joined #parrot
03:38 Theory joined #parrot
03:39 kid51 joined #parrot
03:40 kid51 Seen on http://nytimes.com:  "Commencement 2009:  HASH(0x5cfc60)"
03:43 Zak joined #parrot
03:59 dalek parrot: r39282 | pmichaud++ | trunk (2 files):
03:59 dalek parrot: [core]:  Fix TT #24, equivalence of hash keys.
03:59 dalek parrot: * Add a new test for TT #24, the existing test looks wrong to me.
03:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39282/
04:02 dalek parrot: r39283 | pmichaud++ | trunk/t/op/stringu.t:
04:02 dalek parrot: [core]:  Remove incorrect unicode test from t/op/stringu.t .
04:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39283/
04:17 snarkyboojum joined #parrot
04:46 cotto joined #parrot
05:10 snarkyboojum left #parrot
05:23 skids joined #parrot
05:31 cotto joined #parrot
05:32 skids joined #parrot
05:51 david joined #parrot
06:04 dalek parrot: r39284 | pmichaud++ | trunk/t/op/stringu.t:
06:04 dalek parrot: [core]:  Add another (failing, todo) test for TT #24 --
06:04 dalek parrot: the change in r39282 wasn't good enough to solve the overall problem.
06:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39284/
06:12 snarkyboojum joined #parrot
06:38 david joined #parrot
06:59 cotto joined #parrot
07:05 viklund joined #parrot
07:13 patspam joined #parrot
07:31 Tene Anyone awake with much knowledge of Parrot's Makefile system?
07:31 Tene Out of curiosity, anyone awake at all?
07:32 unitxt joined #parrot
07:35 unitxt left #parrot
07:54 Tene pmichaud: please review r39285.
07:57 dalek parrot: r39285 | tene++ | trunk (4 files):
07:57 dalek parrot: Add a 'parrot' compiler object that can be used from HLLs to load
07:57 dalek parrot: properly-configured PIR libraries.
07:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39285/
07:57 Tene http://gist.github.com/120809
08:15 iblechbot joined #parrot
08:56 patspam joined #parrot
09:41 bacek joined #parrot
09:44 bacek oh hai
09:57 viklund joined #parrot
10:17 Ademan joined #parrot
10:35 Infinoid good morning
10:35 purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
10:50 * bacek stopping himself to write mail to parrot-dev with all 3 usual sentence about design of STRING...
10:52 Infinoid oh?  that sounds like an amusing email
10:53 bacek who decided to have zillions of internal string representations inside single interpreter???
10:54 bacek why we can't have simple single string representation and avoid all this bloody checks during runtime about string "compatibility"
10:55 Infinoid even if we flatten the encoding internally, we still need to keep track of different charsets
10:55 bacek (And TT#24 just not closeable. Because every single Hash on earth built on simple idea - if hashvalue is same, then values can be same. But if they different, then values CAN'T BE SAME)
10:55 bacek Why we need different charsets?
10:58 Infinoid Because if we can't handle different charsets, neither can the HLLs.  And being able to turn on and off unicode is a requirement for some languages
10:58 Infinoid (perl5, for instance)
10:59 bacek chromatic>   HELLO FROM THE 21ST CENTURY PLEASE JOIN US THE WATER IS FINE
10:59 bacek "turn off unicode" for output - fine. But it doesn't imply not to use unicode internally
11:00 bacek Ooo...
11:00 bacek chromatic> But we have backwards compatibility with Perl 4 to consider, so we can't change too much.
11:00 * bacek fell in love with ParrotQuotes
11:00 Infinoid :)
11:01 Infinoid actually, I turn off unicode for performance reasons... but it's really utf8 I care about turning off, not unicode itself
11:01 Infinoid the whole bytes vs. chars thing is *completely* useless when you're trying to write high performance network code
11:02 mikehh utf8 should be an external representatiom NOT internal
11:02 bacek utf8 is good. as input/output encoding.
11:03 bacek Not as intern.. As mikehh said
11:04 bacek (high performance) And this is another question - who was so high on cocaine to use STRING* as sequence of bytes? Who???
11:05 Infinoid I dunno, STRING predates my involvement with parrot
11:05 Infinoid But some things *are* sequences of bytes, and it's nice to be able to access those from parrot too
11:06 bacek Yes! As sequence of bytes!
11:06 mikehh but a sequence of bytes should NOT be a STRING
11:06 bacek No one should want to "uppercase this sequence of bytes please"
11:06 Infinoid why not?
11:07 bacek different semantic. totally
11:07 mikehh unless you consider bitstring bytestring and then charstring
11:07 Infinoid the fact that some things are difficult does not mean they are unnecessary
11:09 * bacek vote for new core type BYTE. Among INTVAL, NUMVAL, PMC and STRING.
11:09 Infinoid No thanks.  We already have enough interfaces that require one data type and exclude others that could potentially be useful
11:09 mikehh characters are NOT bytes, ASCII is ab encoding which maps to bytes - Unicode does not
11:10 mikehh s/ab/an/
11:10 bacek Oh. We can have one type 'void*'...
11:10 Infinoid characters *are* bytes, when you're using binary or ascii charsets and fixed_8 encoding
11:10 Infinoid I think PObj is a bit more useful than void*
11:10 bacek characters happens to map to bytes for "single byte encodings"
11:11 Infinoid Here's an example.  If we couldn't make ascii/bytesequence STRINGs, NCI wouldn't be able to look up symbols in the linker table, which means NCI would be more or less useless
11:11 Infinoid And if we had to transcode those to/from UCS4, I think performance would be noticably worse than it is now
11:11 mikehh no - bytrs can represent characters in ASCII or EBCDIC they are not bytes
11:11 bacek It will be faster
11:13 Infinoid mikehh: bytes are not bytes?
11:13 masak joined #parrot
11:15 elmex joined #parrot
11:15 Infinoid The code referenced by pmichaud in TT #24 looks a bit sketchy to me... what's to prevent hash collisions?
11:15 mikehh in general bytes are 8 bits - they can represent many things, 0-255, -128-127 ASCII characters, EBCDIC characters etc
11:15 Whiteknight joined #parrot
11:15 Infinoid they can represent anything, or nothing.  My code tends not to care, as long as length() reports the number of bytes properly
11:16 Infinoid and efficiently
11:16 mikehh as long as you know what is being represented
11:17 Infinoid if I'm making a webserver, I want all my strings to just be bytes.  Some config can give me a "content-encoding" string to give to the client, but I just want to shovel bytes
11:17 Infinoid if I have to deal with strings as utf8, my server performs worse for *no* good reason
11:17 snarkyboojum joined #parrot
11:17 mikehh furthermore the majority of the world uses other languages
11:18 mikehh don't use utf8 as an internal representation
11:18 Infinoid therefore, if parrot did not have the ability to handle non-unicode strings, I've lost the ability to write efficient servers in parrot HLLs.
11:18 Infinoid it's not about utf8; it's about unicode in general
11:19 Infinoid I do want to handle sequences of bytes directly
11:19 Infinoid that's why I like STRING's ability to do so.
11:19 mikehh if you have to deal only with English ok what about Asian languages
11:20 Infinoid asian languages still use strings made of bytes, even if each character may consist of more than one of those bytes
11:20 mikehh or Hebrew, Cyrillic etc
11:20 Infinoid My code does not *care* about your characters.  It just wants to shovel the bytes
11:20 Infinoid Let the user interface deal with charset nonsense
11:20 mikehh thats utf8
11:21 Infinoid what's utf8?
11:21 purl i think utf8 is the One True Encoding or RFC 2044 or statico's test at http://langworth.com/pub/unicode.png (screenshot) and http://langworth.com/pub/unicode.html (source & browserable) or at http://www-950.ibm.com/software/globalizati​on/icu/demo/converters?conv=UTF-8&s=ALL or teh sux0r ( http://sam.zoy.org/writings/utf8/ ) or use the fine 8
11:21 Infinoid You may think I'm crazy for writing web servers and network stacks in perl, but I'd say you're crazy for suggesting things that will prevent me from doing so efficiently
11:22 mikehh I don't think you are crazy :)
11:22 bacek Infinoid: I wrote a lot of web services. And network apps. And clean separation between std::vector<uint8_t> and std::string was always helpful
11:23 Infinoid Lets say you have a text file on disk.  I open the file with a fixed_8 encoding, I read it into a STRING, and I send it to you on a network socket.  Your *client* can interpret it however it wants, but for my purposes, I just want to get the bytes into and out of my server as quickly as possible
11:23 mikehh no one involved in this project is crazy are they?
11:23 Infinoid utf8 really pisses me off, in that length() does not report a value I can use for the Content-Length header
11:23 Infinoid So I turn it off.  It's just useless overhead on this layer
11:24 bacek you read "sequence of bytes" and send "sequence of bytes".
11:24 bacek and "length" and "chars" are different!
11:24 Infinoid So I need to be able to handle strings in stupid, fast, sequence-of-bytes mode
11:24 bacek (Even Parrot's STRING has 2 different methods)
11:25 Infinoid If parrot transcoded those to UCS4 internally and back, that would still be stupid, but less fast
11:25 Austin_Hastings joined #parrot
11:25 bacek You need to be able to handle sequence of bytes in stupid, fast, sequence-of-bytes mode
11:25 Whiteknight so Infinoid, you need he byte length, not the codepoint length?
11:25 bacek You shouldn't convert it to STRING
11:26 bacek That's why I proposed BYTE as core type.
11:26 Infinoid most of the I/O functions only work with STRINGs.  You'd have to double the size of our API for that
11:26 bacek We have 240+ VTABLEs already, who cares? :/
11:27 Infinoid I don't really object to a BYTE, though I think it's a lot of extra work and we already have problems with APIs using the wrong datatype.
11:27 Infinoid What I object to is: [03:54] <@bacek> why we can't have simple single string representation and avoid all this bloody checks during runtime about string "compatibility"
11:28 Infinoid I *like* having encoding plugins for STRINGs, I don't want to transcode everything on input/output
11:29 bacek So, TT#24 isn't closeable. Because to same strings will have different hashvalue
11:29 bacek s/to/two/
11:30 bacek Or we have to translate it on every "hash_put", "hash_exists"
11:30 Infinoid the hashval thingy seems like an optimization, it still falls back on full string compare
11:30 bacek Infinoid: no!
11:30 Infinoid But I still worry about hash collisions, there
11:31 bacek hashval is how hashes works.
11:31 bacek And STRING_compare is for collision detection
11:31 bacek s->hashval is just premature optimisation.
11:32 Infinoid agreed
11:32 bacek You can comment out using it in key_hash_STRING. Result will be same
11:33 Infinoid I know how hashes work.  There's nothing wrong with having multiple entries in the same bucket, it just means your hash function didn't detect a difference in the keys (or maybe your hash is getting full)
11:33 bacek So, pmichaud's patch breaking contract with Hash.
11:33 Infinoid But relying on hashval comparisons seems to violate the documentation of the function: "Compares the two strings, returning 0 if they are identical."
11:34 Infinoid oh, wait, it's only a negative check
11:34 bacek Indeed.
11:34 bacek Collision detection only.
11:34 Infinoid how does pmichaud's patch break the contract?
11:35 bacek For Hashes: if(hash(k1) != hash(k2)) means v1 != v2
11:35 bacek Now, we have two strings A1 and A2, and hash(A1) != hash(A2), but A1==A2
11:36 bacek and hash just blow up
11:36 Infinoid pmichaud's patch fixes that
11:37 Infinoid now it only compares the hashvals if the charsets are the same... otherwise it continues and does the full string comparison
11:37 bacek and on "hash_resize" it crashes
11:38 bacek again.... STRING_compare is for collision detection only.
11:38 Infinoid uh oh
11:49 bacek fixed anyway...
11:50 bacek dalek: ping?
11:50 dalek parrot: r39286 | bacek++ | trunk (3 files):
11:50 dalek parrot: [core] Don't rely on CHARSET for compute STRING hashvalue. Closes TT#24
11:50 dalek parrot: It always bad idea to break contract with Hash. So steal code
11:50 dalek parrot: from unicode/compute_hash to be used for all string.
11:50 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39286/
11:51 Infinoid bacek++
11:54 * bacek hates STRING even more than before...
11:56 bacek housekeeping time.
11:57 * bacek departs to kitchen
12:11 dalek TT #24 closed by bacek++: non-equivalence of equal Hash key strings
12:49 ZuLuuuuuu joined #parrot
13:13 dalek TT #699 closed by coke++: plusthree site down again
13:17 dalek TT #637 reopened by coke++: smolder: server error on submission
13:17 cognominal joined #parrot
13:18 cotto joined #parrot
13:22 dalek parrot: r39287 | bacek++ | trunk/src/string/api.c:
13:22 dalek parrot: [core] Don't use atod in Parrot_str_to_num on non-single-byte encoded strings. Closes TT#724.
13:22 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39287/
13:24 dalek TT #724 closed by bacek++: [bug]  Parrot fails numeric conversion of ucs2 strings
13:28 pmichaud bacek: ping
13:28 bacek pmichaud: pong
13:28 pmichaud I don't think that patch will work in the general case.
13:28 bacek which one?
13:28 pmichaud I don't think you can blindly convert everything to ASCII.
13:29 pmichaud the one for #724
13:29 bacek It's in str_to_num. So string can contain only small subset of characters
13:30 pmichaud converting to a num shouldn't throw an exception, though.
13:30 bacek (I've got handcrafted FSM for parsing. Implemented just for fun :)
13:31 pmichaud nor do we want to be creating more GC-able objects every time we do a str-to-num conversion.
13:31 nopaste "bacek" at 122.110.49.211 pasted "handcrafted float parsing" (161 lines) at http://nopaste.snit.ch/16742
13:32 bacek I can commit patch from no-paste
13:32 pmichaud bacek: I'd like there to be a bit more analysis and discussion, first.
13:32 bacek ok. There is no C-functions to convert string to float for widestrings.
13:33 pmichaud I know that.
13:33 pmichaud It just bugs me a bit that we get "this patch solves this problem" without actually considering all of the use cases.
13:33 bacek 2 solutions: convert to char* or parse it manually. I've got both.
13:34 bacek (And actually prefer second)
13:34 pmichaud yes, but I don't like having the duplicate code.
13:35 bacek "duplicate"?
13:35 purl hmmm... "duplicate" is the working policy here.
13:35 bacek purl: good girl :)
13:35 purl thanks bacek :)
13:35 pmichaud There's already some FSM for parsing/calculating str-to-num in Parrot.  I'd prefer that we not have two of them.
13:35 bacek Ah. Didn't spot this before. Let me check
13:36 pmichaud thus my comment "I'd like there to be a little more discussion/analysis" before we commit a patch and consider a problem "solves".
13:36 pmichaud *"solved"
13:36 pmichaud (src/pmc/string.pmc, btw)
13:37 bacek string.pmc calls Parrot_str_to_num...
13:38 bacek Ah. Parrot_str_to_int have similar FSM.
13:39 bacek And have same problem with widestrings...
13:39 pmichaud agreed, it has the same problem.
13:40 bacek Looks like proper solution is revert previous commit, apply from nopaste, fix str_to_int, and than try to refactor common parts of str_to_num and str_to_int
13:40 pmichaud that might be better.  I'll revert the previous commit if you don't, as it's a serious regression.
13:41 bacek I'll do it in.
13:41 pmichaud you might wait for the test I'm about to add.
13:41 pmichaud (the one that breaks under r39287)
13:43 bacek reverted already...
13:43 pmichaud was my test from #724 added to the suite anywhere...?
13:43 bacek But any new tests will be helpful.
13:44 dalek parrot: r39288 | bacek++ | trunk/src/string/api.c:
13:44 dalek parrot: Revert r39287.
13:44 dalek parrot: This is big regression. pmichaud++ for explanations.
13:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39288/
13:45 bacek pmichaud: adding...
13:45 purl adding is easy
13:46 pmichaud General policy is to not commit changes (such as r39287) without also committing a regression test for whatever has been changed.
13:48 bacek ok
13:48 skids joined #parrot
13:48 * bacek making another note
13:52 bacek Why str_to_int accepts null strings, but str_to_nim doesn't?
13:53 bacek str_to_num
13:57 pmichaud I don't know.
13:58 bacek And str_to_int throws exception on overflow...
13:58 pmichaud I don't mind if it throws and exception on overflow.
13:58 dalek TT #724 reopened by pmichaud++: [bug]  Parrot fails numeric conversion of ucs2 strings
13:59 pmichaud But it shouldn't throw an exception simply because the string happens to have a non-ascii string in it.
13:59 pmichaud er, non-ascii character
13:59 pmichaud see my updated test case in #724
14:02 bacek checking
14:02 purl checking is just different
14:03 bacek expected result is "140"?
14:05 mikehh joined #parrot
14:08 Infinoid I think so
14:09 Infinoid or, I guess, 140\n140\n
14:19 jsut joined #parrot
14:27 bacek I've got 2 spec failures...
14:29 tetragon joined #parrot
14:31 pmichaud expected output would be 140\n140\n, yes.
14:35 bacek ouch... Float.cmp is wrong.
14:36 iblechbot joined #parrot
14:39 bacek Is there is C analogue of std::limits<double>::epsilon?
14:40 bacek ETOOMANYIS...
14:47 Infinoid like DBL_EPSILON?
14:50 bacek O!
14:51 Infinoid float.h has FLT_EPSILON, DBL_EPSILON and LDBL_EPSILON, but I'm having trouble finding out (via google) whether those are C89
14:52 Infinoid ooh.  According to http://www.schweikhardt.net/identifiers.html, they are C89
14:56 nopaste "bacek" at 122.110.49.211 pasted "Proposed patch for FLOAT_IS_ZERO" (18 lines) at http://nopaste.snit.ch/16743
14:56 bacek Any objections?
14:57 pmichaud We need this because....?
14:57 pmichaud fwiw, there were long discussions about FLOAT_IS_ZERO in parrot history
14:58 pmichaud the current implementation was not lightly chosen.
14:58 bacek because of loosing precision.
14:59 Infinoid If you do need to use the epsilon constant, parrot/config.h has definitions for PARROT_FLOATVAL_MIN and PARROT_FLOATVAL_MAX.  I think PARROT_FLOATVAL_EPSILON should be the same kind of thing
14:59 pmichaud I highly recommend reviewing the mailing list discussions on FLOAT_IS_ZERO before committing.
14:59 bacek $N0 = 1; while($N0) { $N0 /= 10 }; will never stop...
14:59 pmichaud and mathematically speaking, it never should.
15:06 Infinoid some discussion of FLOAT_IS_ZERO (and how it was breaking when gcc optimization was turned on) here: http://rt.perl.org/rt3//Publ​ic/Bug/Display.html?id=47397
15:08 Infinoid (The previous version of FLOAT_IS_ZERO casted the float to INTVAL or HUGEINTVAL before doing the comparison.)
15:10 bacek And it was definitely wrong...
15:14 bacek New version not so definitely, but also wrong
15:16 pmichaud Given that chromatic, adougherty, and nclark all ended up advocating the ((f) == 0.0) approach, I'd be reluctant to go against their recommendation.
15:16 pmichaud i.e., those are all people with lots of experience on the issue.
15:18 Infinoid If it's still broken, it would help that discussion to have a test case displaying the brokenness
15:18 pmichaud I totally agree there -- I'd like to see a test that demonstrates the brokenness.
15:44 Infinoid ok, traveling time
15:44 Infinoid back wednesday, have fun all!
15:48 nopaste "bacek" at 122.110.49.211 pasted "FLOAT_IS_ZERO broken." (26 lines) at http://nopaste.snit.ch/16744
15:49 bacek pmichaud: there is a test
15:49 pmichaud bacek: I disagree with that test.
15:50 pmichaud $N0 != e   is an invalid comparison.
15:50 bacek why $N0 == 0.0 valid than?
15:50 pmichaud in some sense, zero is special.
15:51 pmichaud indeed, that's why we have a macro for it.
15:56 Andy joined #parrot
15:58 nopaste "bacek" at 122.110.49.211 pasted "FLOAT_IS_ZERO is broken?" (26 lines) at http://nopaste.snit.ch/16745
15:58 bacek it's.. strange...
16:24 Tene pmichaud: ping
16:26 pmichaud pong
16:28 Tene pmichaud: can you review r39285?
16:28 Tene http://gist.github.com/120809 has a use of it
16:30 pmichaud +    name = request['name']
16:31 pmichaud I don't like that approach.  We have named parameters, we should use them.
16:31 Tene Okay.
16:31 pmichaud background...
16:31 purl background is transparent btw
16:32 Tene I'll change that shortly.
16:32 pmichaud much of the stuff written in the namespace pdd comes from before we had the ability to do method calls on PMC objects
16:32 pmichaud i.e., we couldn't do    ns.'method'(....)
16:32 pmichaud so, the standard way to get around that was to create a Hash, and have an opcode that looked something like
16:32 pmichaud method ns, hash
16:32 pmichaud where the hash held the "named parameters"
16:33 pmichaud you see that today in things like       new $P0, init_hash
16:33 pmichaud er
16:33 pmichaud new $P0, ['Class'], init_hash
16:33 pmichaud however
16:33 pmichaud - we now have the ability to make method calls on PMCs
16:33 pmichaud - HLLCompiler isn't a PMC class
16:34 pmichaud so I vote that we use the calling conventions here rather than what was-once-true-but-is-no-longer-true
16:35 ZuLuuuuuu joined #parrot
16:35 pmichaud (and this is why I've said we need to update the namespace pdd, to redesign it for what-is-available-in-parrot-today as opposed to what-we-were-limited-to-when-it-was-written)
16:35 Tene I think my original motivation was trying to play nicely with languages that didn't support named parameters, but I suspect I made that decision late at night, as it doesn't actually seem relevant anymore.
16:35 pmichaud that's a reasonable motivation
16:36 pmichaud however, I doube that anyone will be calling this directly from the HLL -- more likely it'll be from some internal-PIR-or-PCT thingy
16:36 Tene Yes, agreed.
16:36 pmichaud *doubt
16:37 Tene I'll update it now.
16:37 pmichaud we should use underscores instead of hyphens
16:37 Tene Why?
16:37 pmichaud most languages don't recognize hyphens in identifiers
16:37 pmichaud (including NQP, for now)
16:38 Tene If it's going to be called internal to PIR or PCT anyway, as we just established...
16:38 pmichaud not always, though.
16:38 Tene okay.
16:38 pmichaud at any rate, the *rest* of parrot uses underscores, so we should keep that.
16:39 pmichaud I too totally dislike underscores in names and prefer hyphens.... but in this case I'd hate to add a third convention on top of the others.
16:39 Andy joined #parrot
16:40 pmichaud I'm not sure that fetch-library should catch a load_bytecode failure
16:40 pmichaud I think we should let the caller catch it.
16:40 Tene sure, okay.
16:41 pmichaud other than those, this is a good start.
16:41 pmichaud I rewrote 'import' for Rakudo
16:42 pmichaud you might want to steal some ideas from it
16:42 pmichaud also, I'd like name to accept ::-delimited names
16:42 pmichaud (same as the rest of PCT)
16:43 pmichaud in fact, I don't think we need a named parameter for that
16:43 pmichaud parrot.'load_library'('Foo::Bar')    #  loads Foo/Bar
16:44 Tene pmichaud: the debate around names for this comes from differen tlanguages having different naming conventions... a list of strings seems to be a good compromise that should work for an identifier from any language.
16:44 pmichaud I agree that list of strings should work.
16:44 pmichaud but I'd like 'Foo::Bar' to work also.
16:44 pmichaud (same as rest of pCT)
16:45 Tene The "There's several equivalent ways to call this" has kind of bugged me a bit about some parts of PCT.
16:45 Theory joined #parrot
16:45 pmichaud It's the same principal whereby we can use a class, key, string, or namespace to identify a class.
16:45 pmichaud *principle
16:46 Tene That's exactly the part that's bothered me. :)
16:46 pmichaud fair enough.
16:46 Tene I defer to you, though.
16:46 pmichaud I just know that writing      Parrot::Compiler.load_library('Foo::Bar')  in NQP is much easier than figuring out how to split the string.
16:47 Tene So 'name' should be the first positional argument, and fetch_library methods should accept any other named parameters, any of which it's free to use or ignore?
16:48 pmichaud Yes
16:48 pmichaud that sounds great.
16:48 Tene Okay.
16:48 pmichaud and for consistency I think it should still be called load_library
16:49 Tene Okay, I'll defer on that too. :)
16:50 pmichaud I'm not as strongly attached to that, though, so I'm open for discussion :-)
16:50 pmichaud unfortunately it'll have to be after I fetch lunch for the family here
16:50 Tene I also wanted to be clear about the difference between loading a library into my current program and retrieving a library from a foreign language.
16:51 pmichaud well, we're always telling a specific compiler to load a library
16:51 Tene Just looking at the name, I'd expect 'load_library' to be a method that fetched the appropriate library and loaded it into my local anmespace or lexical pad or whatever.
16:51 pmichaud but we aren't saying anything about importing
16:51 pmichaud I'd think that the operation you describe would be 'import_library'
16:51 pmichaud or 'load_library' followed by 'import'
16:51 Tene 'fetch_library' doesn't do any futzing with the namespace, or anything, it just returns a representation of the library.
16:52 Tene And it's up to whoever called it to actually do something useful with it.
16:52 Tene and 'fetch' sounds sufficiently idempotent.
16:52 pmichaud by way of analogy -- load_library in parrot doesn't do any importing
16:52 pmichaud sorry.
16:52 pmichaud load_bytecode in parrot doesn't do any importing
16:52 pmichaud loadlib in parrot doesn't do any importing
16:52 pmichaud etc.
16:52 pmichaud they just mean "load"
16:53 pmichaud as in "bring into Parrot"
16:53 Tene they often result in things being usefully available, though. :)
16:53 pmichaud sure, but only because the caller then knows where to go look for them.
16:53 Tene sure, okay.
16:53 pmichaud when I do   load_bytecode "PGE.pbc", it doesn't change my current namespace at all
16:53 pmichaud it just loads a bunch of things into the ['parrot';'PGE'] namespace.
16:53 Tene can i check for "It's a string" by comparing the result of typeof_s_p with 'String'?
16:54 pmichaud generally PCT checks for an array
16:54 Tene I don't know the best way to check an argument for stringiness.
16:54 pmichaud and if not an array, treat it as a string.
16:54 pmichaud $I0 = does name, 'array'
16:54 Tene Ah.
16:54 pmichaud i.e., if it's an array, we don't futz with it.
16:54 pmichaud if it's something else, we kinda figure out what it is.
16:55 Tene You want 'export-symbols' to use a _ too, I'd imagine.
16:55 pmichaud that means that arrays continue to be the "primary, absolutely respect what the caller sent us" form of argument
16:56 pmichaud yes, export-symbols should use a _
16:56 Tene Man, all this consistency... :P
16:56 pmichaud and perhaps just call it "export"
16:56 Tene I considered that, but worried about stepping on toes.
16:56 pmichaud it's an object
16:56 pmichaud it's a compiler object :-)
16:57 Tene btw, thanks for being so opinionated.  It helps maintain consistently high quality. :)
16:57 Tene Oh, one more thing...
16:57 purl somebody said one more thing was the fact that I need to write some sort of a template engine
16:57 Tene HLLCompiler defaults to having abunch of stuff inappropriate for this, right?
16:58 pmichaud I don't quite understand
16:58 Tene I thought, at least...
16:59 Tene I'm inheriting from PCt;:hllcompiler.
16:59 pmichaud oh
16:59 pmichaud yes, you're correct.
16:59 pmichaud but the inappropriate stuff is likely to change as part of my hllcompiler refactor
16:59 Tene Should I be removing things, or overriding anything with "Don't call this"?
16:59 Tene Oh, okay.
17:00 pmichaud I think you can leave it for now.
17:00 pmichaud my expectation at this point is that the "parrot" compiler will know how to turn PIR into bytecode, for one.
17:00 Tene Which it doesn't, and I'm not sure how to add that appropriately. :)
17:01 pmichaud right, that's a pretty significant refactor for HLLCompiler
17:01 pmichaud basically the 'parrot' compiler will provide a HLLCompiler interface to the existing PIR comiler
17:01 pmichaud *compiler
17:01 pmichaud (currently the PIR compiler doesn't understand any methods -- you just invoke it on source)
17:02 pmichaud thus    parrot.'compile'('...PIR source...')    will do something similar to what   perl6.'compile'('...Perl6 source...')  would do
17:02 pmichaud including honoring any options
17:02 pmichaud and   parrot.'eval'('...PIR source...')   would compile + eval, etc.
17:02 pmichaud I gotta run, bbl
17:03 Tene seeya, thanks
17:11 dalek parrot: r39289 | tene++ | trunk/runtime/parrot/languages/parrot/parrot.pir:
17:11 dalek parrot: Track changes in HLL library loading API.
17:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39289/
17:13 dalek rakudo: 50ec44e | pmichaud++ |  (3 files):
17:13 dalek rakudo: Use iso-8859-1 (fixed-width) instead of utf8 for parsing when we can.
17:13 dalek rakudo: This improves the "make spectest" performance by about 13%.
17:13 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​0ec44e24c1a0945130331a21d621ef68a97df80
17:13 dalek rakudo: 0b9c9a3 | tene++ |  (2 files):
17:13 dalek rakudo: Track changes in HLL library loading API.
17:13 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​b9c9a357717595deeb1ab7269381e00f0e57376
17:16 dalek cardinal: e3d7404 | tene++ |  (2 files):
17:16 dalek cardinal: Track changes in HLL library loading API.
17:16 dalek cardinal: review: http://github.com/cardinal/cardinal/commit​/e3d7404c384c971dd36a81849792eebfcff9ca26
17:24 dalek parrot: r39290 | tene++ | trunk/runtime/parrot/languages/parrot/parrot.pir:
17:24 dalek parrot: [parrot.pir]: Let other langauges catch our load_bytecode exceptions
17:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39290/
17:49 Tene pmichaud: any reason I should also write a "load a foreign library" method for the 'parrot' compiler?  Think anyone will be using a HLL from PIR?
17:50 Tene PIR on Rails. :)
17:51 particle1 joined #parrot
17:51 Coke has the string-hash-key discussion been resolved?
17:53 Tene Coke: eh?
17:57 pmichaud Tene: The standard mechanism for loading a foreign library should be to ask the foreign library's compiler to do it.
17:57 pmichaud Even from PIR.
17:57 pmichaud Coke: I don't know if string-hash-key discussion is resolved, but bacek++'s latest patch solved the problem I was seeing.
17:57 pmichaud (at least to the level that Rakudo no longer fails when using iso-8859-1 for source)
18:00 Whiteknight joined #parrot
18:12 dalek parrot: r39291 | fperrad++ | trunk/runtime/parrot/languages/parrot/parrot.pir:
18:12 dalek parrot: fix various coding standards
18:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39291/
18:29 mikehh I am getting t/pmc/undef.t passing the tests but failing with a segmentation fault
18:29 mikehh if I run with -v or -t it doesn't
18:31 mikehh ie ./parrot t/pmc/undef.t segfaults but ./parrot -t t/pmc/undef.t does not also -v
18:38 mikehh BTW my last build got sent to smolder but when I tried to connect - it didn't
18:42 mikehh it sent it about 4 hourd ago and I haven't been able to connect to the site since then
18:52 mikehh and furthermore ./parrot t/pmc/packfileannotations.t FAILS test 15 BUT ./parrot -t t/pmc/packfileannotations.t PASSES
18:57 mikehh and ./parrot -v t/pmc/packfileannotations.t PASSES but ./parrot t/pmc/packfileannotations.t FAILS Test 15 if I run again
18:59 mikehh I am running Kubuntu 9.04 Amd64 at r39288
19:32 Maghnus joined #parrot
19:44 Tene pmichaud: ping
19:47 * Coke returns.
20:01 pmichaud Tene: pong
20:01 Tene pmichaud: I was wondering if there could be a scope for PAST::Vars that would translate to a find_name opcode.  I found a workaround, though.
20:02 viklund joined #parrot
20:03 pmichaud I've been thinking about adding such a scope, yes.
20:03 pmichaud But there's always simply   PAST::Op( :pirop('find_name'), ... )
20:03 Tene Yeah.
20:04 pmichaud and perhaps we need to add find_name to piropsig
20:04 Tene it's there
20:04 Tene I'm unsure whether a pirop would be more or less awkward than my workaround.
20:04 pmichaud it doesn't do much good to have find_name in a PAST::Val, because there's no way to bind or lvalue it
20:04 pmichaud er, PAST::Var
20:05 pmichaud PAST::Op.new( :pirop('find_name'), '$var' )    # seems pretty short to me
20:05 pmichaud unless of course you need a viviself
20:05 pmichaud that might be a reason to do it as a PAST::Var
20:07 Eevee joined #parrot
20:18 Whiteknight pmichaud: I was looking at your wiki the other day
20:18 Whiteknight I'm working with a research group who are setting up a wiki application and we looked at PMWiki as one of the potential platforms for it
20:19 pmichaud Whiteknight: I highly recommend it :-) :-) :-)
20:19 Whiteknight I was able to say "I know that guy!"
20:19 pmichaud although it needs a bit more love from me these days -- I've been spending too much time with p6 :-)
20:20 Whiteknight I'm actually surprised you didn't write it in Perl
20:20 pmichaud there are a couple of reasons for that
20:20 pmichaud (1) it's *far* easier to install PHP applications than Perl ones for the typical webhosting environment
20:20 Whiteknight I don't know PHP as well, and we're doing some custom development so I was hoping it would be Perl so I could do it more easily
20:20 pmichaud (2) PHP has a slightly less-steep learning curve for people who might want to customize it
20:21 pmichaud ease-of-installation was the clincher, really.
20:21 Whiteknight I imagine so
20:21 pmichaud The average person can download, untar, and have it running inside of 5 minutes
20:21 pmichaud (often less)
20:22 Whiteknight the group decided on MediaWiki finally, but we definitely looked closely at PMWiki too
20:22 pmichaud sure, MediaWiki is a good choice, especially if very large scalability is important
20:22 * jonathan hopes we can make Perl 6 have a competitive level of ease-of-installation.
20:22 pmichaud jonathan: yes, me too.  mod_parrot helps a bunch there, I hope.
20:23 Whiteknight yeah, we had to go with the platform that the group was more familiar with
20:24 Tene mod_parrot has some of the same issues mod_perl does.
20:25 * Whiteknight has to go catch a plane now. Late!
20:25 Whiteknight later*
20:26 pmichaud well, I suspect mod_php has to deal with those issues as well.  With mod_parrot we have the advantage of not having to be mod_perl :-)
20:27 cotto joined #parrot
20:28 skids Newbie question -- can a PMC move from one class to another gracefully, keeping the same memory address (in-place promote)?  Would it have to be preallocated/presized with that in mind? (The datastructure headers haven't quite gelled in my brain yet.)
20:28 Tene That is, you can't drop a .pl in with a bunch of .html and have it run.  At least, that's not the default configuration.
20:28 Tene We could certainly add that for mod_rakudo, if desired.
20:29 jonathan skids: Yes, that can work.
20:29 pmichaud skids:  In rakudo, we had to write a rebless operator to make that work
20:29 pmichaud skids:  there's also the copy opcode, which can do that a little more destructively
20:29 jonathan Those were the two I was going to mention. :-)
20:30 skids Cool, I'll try to grep around for those.
20:30 jonathan rebless_subclass goes as one of the most evil things I ever wrote.
20:30 * jonathan is terrified of having to ever change it again.
20:31 jonathan otoh, it's not been the source of any problems that I know of, so it appears to be stable. :-)
20:32 skids (Basically asking because I'm weighing the pros/cons of conditionals for compact versions data structures, e.g. hashes with < 4 keys, against having a "nanohash" or something class that upgrades.)
20:33 pmichaud there's also the "morph" opcode
20:33 pmichaud but for what you're talking about, it sounds like it's better to build that switching-behavior into the existing hash class than to create a new one
20:33 pmichaud similar to the way we'd like Integer to start acting like BigInt without changing its type
20:34 skids Just it's messy that way.
20:37 skids That is, if we ever end up with something complexity-wise comparible to say a Judy trie, where there are scores of different node types, all of which can be at the head.  Not that we will, but...
20:38 skids For simple hashes it's not that big a deal, just ugly pointer casting.
20:40 skids On the flip side, big monolithic switch statements don't take up symbol table space.
20:42 eternaleye joined #parrot
20:44 Tene http://gist.github.com/121026 -- language loading support for my scheme compiler
20:46 * Tene happy
20:46 * Tene leaves for a while.
20:52 jonathan lol awesome! Tene++
21:10 Tene Coke: does tcl have libraries?
21:28 pmichaud jonathan: ping (although others will be interested in this as well)
21:28 purl I can't find (although in the DNS.
21:30 jonathan purl: You're looking in the wrong place.
21:30 purl jonathan: what?
21:30 jonathan pmichaud: pong
21:31 pmichaud I'm working on improving the speed of postfix:<++>
21:31 pmichaud I could use someone to bounce ideas off off
21:31 pmichaud *off of
21:31 pmichaud or at least to get reactions
21:31 * jonathan hopes he is sufficiently bouncy
21:31 pmichaud let me establish a base case
21:32 pmichaud I'm doing a basic loop, counting from 1 to 20000
21:32 pmichaud code and timings about to be nopasted
21:32 pmichaud (waiting for compile to finish)
21:33 nopaste "pmichaud" at 72.181.176.220 pasted "incrementing integers, base case (current master)" (10 lines) at http://nopaste.snit.ch/16752
21:34 pmichaud 16752 is my base case
21:34 pmichaud i.e., we currently take 13 seconds.  Lousy.
21:34 pmichaud I've refactored postfix:<++> (and .succ and .pred)
21:35 pmichaud with the refactor, not doing any special optimization for Ints, it now takes 3.222 seconds
21:35 Zak So I have a crazy idea for a language that seems like a good fit for Parrot. Is this a good place to bring it up, or is this more for discussing Parrot internals?
21:35 pmichaud so, my question now (and what I'm playing with) is deciding if/how to optimize the Int case
21:36 jonathan pmichaud: Any chance I can glance at the diff?
21:36 pmichaud sure
21:36 pmichaud just a sec
21:36 jonathan Zak: This is the all-purpose Parrot channel. :-)
21:37 pmichaud easier is if I just show the new postfix:<++> code
21:37 pmichaud (easier to read than the diff)
21:37 jonathan That's fine too. :-)
21:37 Zak Then the next obvious question is, does anybody want to listen to me ramble?
21:37 nopaste "pmichaud" at 72.181.176.220 pasted "new postfix:<++> code" (12 lines) at http://nopaste.snit.ch/16753
21:38 pmichaud very straightforward
21:38 pmichaud to establish a lower bound of what we might expect, I wrote an optimized form of postfix:<++>(Int)
21:38 pmichaud it's semantically wrong in a few areas, but here it is
21:39 bacek joined #parrot
21:39 nopaste "pmichaud" at 72.181.176.220 pasted "postfix:<++> optimized for Int" (6 lines) at http://nopaste.snit.ch/16754
21:39 pmichaud with the optimization from 16754 in place, the benchmark runs in 2.338 seconds
21:39 pmichaud so at present we can't expect to do much better than that
21:39 jonathan One thing I'd be curious to know
21:40 jonathan What happens if you make it a Perl6MultiSub?
21:40 jonathan The MMD cache can do pretty well with a lot of invocations with the same type...
21:40 jonathan And Parrot's MultiSub lacks that.
21:41 pmichaud hmmm.
21:41 pmichaud I could try that.
21:41 jonathan I'm curious where the overhead is in the dispatch, mostly.
21:41 jonathan erm, I mean
21:41 jonathan *if* the overhead is much in the dispatch or not.
21:42 pmichaud wouldn't it be roughly equivalent to the 10000 sub calls benchmark you're doing now?
21:42 jonathan The benchmark I'm doing doesn't try Parrot's MMD.
21:42 pmichaud right
21:42 pmichaud but we know how long 10000 sub calls take, yes?
21:42 jonathan Yes
21:42 pmichaud and that is?
21:43 jonathan Run perl tools/benchmark.pl - the figure has changed over time
21:43 pmichaud (and yes, we could hand-optimize the Perl6MultiSub case a fair bit)
21:43 jonathan And the thing is
21:43 jonathan I was doing for (1..10000) and I suspect that ranges were using infix:++
21:43 pmichaud they do.
21:43 pmichaud yes.
21:43 pmichaud heh
21:43 pmichaud chicken-and-egg
21:44 jonathan So you've probably rather changed the performance profile of the benchmarks now. :-)
21:44 pmichaud correct
21:44 pmichaud well, let me try it
21:44 jonathan Going back to your patch
21:44 pmichaud (and yes, I'm going to re-factor the range code)
21:44 jonathan The main issue I can see is that if somebody subclasses Int and overrides .succ then ++ is not going to be sensitive to that change.
21:45 pmichaud the 10,000 MultiSub invocations takes 5.311 seconds on my box.  But that's not representative, because I don't have your new dispatcher.
21:45 jonathan The new dispatcher doesn't affect MultiSub only method dispatch.
21:46 pmichaud ah
21:46 pmichaud if I make it a arity-1 multisub, it's 4.311 seconds
21:46 pmichaud anyway
21:47 jonathan heh, !SIGNATURE_BIND bites again.
21:47 pmichaud exactly.  And we could avoid that in an optimized Perl6MultiSub version
21:47 pmichaud anyway, the version I have is intended strictly as a lower-bound
21:47 pmichaud do you basically agree we can't easily beat that for Int increment?
21:48 jonathan At the PIR level, I don't think we can do it in any less instructions.
21:48 pmichaud okay.
21:48 pmichaud One thing we *might* be able to do in the compiler is detect when a variable is type-constrainted to Int, and issue inline PIR
21:49 pmichaud that just does an inc
21:49 jonathan Yes.
21:49 jonathan When we have an optimizer. :-)
21:49 pmichaud although yes, that still suffers from the subclass-of-Int issue
21:49 pmichaud although S03 does say that the compiler is allowed to optimize the Int case
21:50 jonathan You're allowed to add methods but not change representation, afaik.
21:50 pmichaud (The optimizer is allowed to assume
21:50 pmichaud that the ordinary increment and decrement operations on integers will
21:50 pmichaud not be overridden.)
21:50 jonathan Ah, OK.
21:50 jonathan That's a nice thing.
21:50 jonathan I can see us being able to optimize that.
21:50 pmichaud anyway
21:51 jonathan That probably means you can legitimately not call .succ
21:51 pmichaud I can adjust my "fastest increment" code so that it checks the operand for (1) readonly, (2) type constraint, (3) overflow  and fall back to the default case if any of those are present
21:51 jonathan Essentially hand-inlining it.
21:52 pmichaud when I do that, I lose some performance, but not much
21:52 jonathan That sounds reasonable yes.
21:52 pmichaud (re-running to get updated time)
21:53 nopaste "pmichaud" at 72.181.176.220 pasted "postfix:<++> optimized for Int, with typechecks and readonly and overflow" (14 lines) at http://nopaste.snit.ch/16755
21:54 dalek parrot: r39292 | bacek++ | branches/tt24_unicode_numifications:
21:54 dalek parrot: Branch for fixing unicode strings numification issues
21:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39292/
21:54 pmichaud with that version (16755), the benchmark runs in 2.444 seconds
21:55 jonathan That does mean my Int $x; $x++ for 1..10000; is isn't going to be so performant...
21:55 pmichaud Correct, that leads up to my next question
21:55 pmichaud adding the type constraint actually makes it slower
21:55 pmichaud think it would be worth checking specifically for the "Int" type constraint ?
21:56 jonathan Maybe we just wave our hands in the air and say "wait until somebody writes a type-based optimizer" ;-)
21:56 pmichaud and at what point do we end up doing so many checks that we might as well default to the general case?
21:56 jonathan You could also do that yet
21:56 pmichaud OTOH, the default case is also slower when a type constraint is present
21:57 pmichaud it takes 5.043 seconds instead of 3.222 secs
21:57 jonathan isa is a pig.
21:57 pmichaud so if we added the explicit check for the Int type constraint, we'd get a Win there.
21:57 pmichaud Oh, we wouldn't have to do isa for that
21:57 jonathan oh, also 'cus we're doing ACCEPTS
21:57 pmichaud we just see if 'type' issame Int
21:57 jonathan Yes, for sure we can here.
21:58 jonathan I meant generally that's why it's slower.
21:58 pmichaud yes.
21:58 pmichaud let's see what happens if I do that
21:58 pmichaud first, the cost of an Int type constraint...
21:59 pmichaud (recompiling)
21:59 jonathan need faster compiler ;-)_
21:59 pmichaud no, I made a typo
21:59 pmichaud need faster programmer :-)
22:00 pmichaud faster compiler wouldn't hurt either, though.
22:00 pmichaud the other question I have:  is it worth optimizing postfix:<--> also?
22:00 pmichaud that's much less common
22:00 jonathan True.
22:00 jonathan I wouldn't for now.
22:00 pmichaud same
22:00 jonathan You've provided the pattern.
22:00 pmichaud I'll optimize prefix:<++> though.
22:01 jonathan It's not much work if somebody cares to duplicate the idea.
22:01 pmichaud okay, with the type constraint it becomes  5.139 seconds on my latest test
22:01 pmichaud now let's check specifically for Int
22:01 jonathan In general on the type stuff, my efforts so far have really been focused on "make it work" than "make it fast"
22:02 pmichaud agreed.
22:02 jonathan Now we're closing in on S12 and S14 though...
22:02 jonathan ...I start on S09!
22:02 jonathan ...eww.
22:03 jonathan I am interested in starting getting a basic first-cut type checker/optimizer into Rakudo at some point.
22:03 nopaste "pmichaud" at 72.181.176.220 pasted "postfix:<++> optimized for Int, with typechecks and specific check for Int" (18 lines) at http://nopaste.snit.ch/16756
22:03 jonathan It'd be an option (-O style) for sure.
22:03 jonathan Not convinced myself we're at the point where it's worth starting ont hat yet though.
22:03 pmichaud it would be good if it could be lexical.
22:03 bacek good morning
22:03 purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
22:04 jonathan That'd be possible.
22:04 pmichaud ooooh, Win
22:04 dukeleto howdy
22:04 purl niihau, dukeleto.
22:04 pmichaud by explicitly checking for Int constraint,  2.475 seconds
22:04 jonathan Nice
22:04 bacek bacek-- # silly typo in branch name
22:04 pmichaud I think I'm keeping that.
22:04 dalek parrot: r39293 | bacek++ | branches/tt24_unicode_numifications/t/op/string.t:
22:04 dalek parrot: [t] Add tests for TT#724
22:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39293/
22:04 dalek parrot: r39294 | bacek++ | branches/tt24_unicode_numifications (3 files):
22:04 dalek parrot: [core] Use handcrafted FSM for parsing float values.
22:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39294/
22:04 pmichaud my Int $x;  $x++   is likely to be a common pattern
22:04 dukeleto has anybody heard from Kevin Tew about his GSoC project ?
22:04 jonathan pmichaud: Yes
22:05 pmichaud okay, thanks.
22:05 pmichaud We go with that.
22:05 jonathan Yay
22:05 jonathan pmichaud++
22:05 jonathan That'll be a decent performance improvement to report back.
22:05 pmichaud I also moved string increment/decrement out of C and into PIR :-)
22:05 jonathan Heh. Did it get faster?
22:05 pmichaud heh, I don't know.
22:05 pmichaud But it'll work with unicode strings now, and we can start to do unicode ranges.
22:05 jonathan Yay
22:06 pmichaud I wasn't doing it for a speed perspective -- mainly because refactoring ++ required some substantial refactors to succ/pred, and that affected Perl6Str
22:06 jonathan Ah, OK.
22:06 pmichaud because Perl6Str implemented string increment as a increment VTABLE, instead of .succ/.pred
22:07 jonathan Ah.
22:07 pmichaud which mean things were kinda backwards
22:07 pmichaud *meant
22:07 jonathan yes
22:07 jonathan One of those probably-right-under-some-version-of-the-spec thing.
22:07 pmichaud okay, now to see if my changes survive spectest
22:07 dalek parrot: r39295 | bacek++ | branches/tt24_unicode_numifications/t/op/string.t:
22:08 dalek parrot: [t] Add more test for unicode string numification. pmichaud++
22:08 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39295/
22:08 dalek parrot: r39296 | bacek++ | branches/tt24_unicode_numif​ications/src/string/api.c:
22:08 dalek parrot: [core] Refactor Parrot_str_to_int to be closer to Parrot_str_to_num.
22:08 dalek parrot: Now it handles unicode strings properly.
22:08 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39296/
22:08 dalek parrot: r39297 | bacek++ | branches/tt24_unicode_numifications/t/op (2 files):
22:08 dalek parrot: [t] Move unicode string tests to t/op/stringu.t
22:08 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39297/
22:13 Tene Zak: I'm rather interested.
22:16 Zak Yay, a taker!
22:17 pmichaud jonathan: okay, this is weird....
22:17 pmichaud I just re-refactored postfix:++ in terms of prefix:++
22:17 Zak Well, the basic premise is that while we have a bunch of single-dispatch languages where everything is an object, and in the more dynamic ones can have methods added to it, we don't have a multiple dispatch language where every function in generic.
22:18 nopaste "pmichaud" at 72.181.176.220 pasted "Refactored postfix:++ and prefix:++" (17 lines) at http://nopaste.snit.ch/16757
22:18 pmichaud this version runs in 2.583 seconds.  *Without* any special casing of Int
22:18 pmichaud (previously it was 3.222)
22:19 Zak When I've mentioned this, most people felt it would be too slow, but I suspect it would not, especially on a VM like Parrot that seems to prefer to optimize by being more dynamic rather than more static.
22:19 Tene zak: interesting
22:20 jonathan pmichaud: That's...odd.
22:20 pmichaud I agree.
22:20 pmichaud maybe because of the tailcall?
22:20 pmichaud and the lack of find_name lookups?
22:20 pmichaud I dunno.
22:20 jonathan Maybe.
22:21 jonathan find_name checks lexpads and then hits the namespace..
22:21 pmichaud yes.
22:21 jonathan Oh, but there's no lexpads here.
22:21 jonathan So that should be cheap.
22:21 pmichaud correct.
22:21 jonathan Hmm. Odd.
22:21 jonathan It does give the correct answer, right? ;-)
22:21 Zak A function defined without dispatch information would be applicable to any object (though it could throw a runtime exception if it did invalid operations internally)
22:21 pmichaud I'll check.
22:22 pmichaud yes, correct answer.
22:22 purl correct answer is "don't do that"
22:22 mikehh Zak: do you hace a proof-of-concept in mind
22:22 Zak In mind? Yes. In code? No.
22:23 pmichaud still worth putting in the special case to avoid the Int typecheck, though.
22:23 Zak Also, method combination like Common Lisp.
22:25 Tene explain?
22:25 Zak The core focus is extensibility. Anyone can extend or override code at any time without modifying the original.
22:25 Zak In Common Lisp, you can define methods of generic functions that are run before, after or around the existing methods.
22:26 Zak So, let's say you have a generic function that handles an incoming HTTP request. You could define an around method that first checks to see if the requestor's IP address is in a list of banned addresses. If it is not, it calls the next method. If it is, it returns a 403 error instead.
22:28 Zak Another example would be to put logging information before and after a function with some hard-to-find runtime bug.
22:31 rg joined #parrot
22:34 Zak Anyway, that's the fundamental idea. Lots of other stuff goes in to making a good language, and I have plenty of ideas along those lines, but none of them are unique.
22:38 bacek Zak: looks like Perl6 from point of view
22:38 tetragon joined #parrot
22:39 Zak Not actually knowing a lot about Perl6, I can't comment.
22:40 bacek Zak: try channel #perl6 at freenode.org
22:41 jonathan Well, many languages look like some subset of Perl 6... ;-)
22:41 bacek usually small :)
22:42 bacek small subset
22:43 Zak The language I have in my head looks like a hybrid of Common Lisp and Clojure, with some influence from Scheme and Haskell, but where all functions are generic.
22:43 dalek parrot: r39298 | bacek++ | branches/tt24_unicode_numif​ications/src/string/api.c:
22:43 dalek parrot: [core] Use integers in Parrot_str_to_num to preserve precision if possible
22:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39298/
22:44 Zak And with that, I must go for a while. If anyone thinks I'm crazy enough to have good ideas, feel free to email me at zak.wilson@gmail.com
22:44 Zak Thanks for listening.
22:47 dalek parrot: r39299 | bacek++ | branches/tt24_unicode_numifications/t/op/number.t:
22:47 dalek parrot: [t] Remove check for lond double in sqrt_n_n results.
22:47 dalek parrot: We now parsing floats more precisely so sqrt(2.0) always equal sqrt(2)
22:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39299/
23:16 Coke joined #parrot
23:26 Coke tene; (libraries) do you mean that in some particular way? Tcl has a standard library, yes. it's setup so that when called from tcl, most of it is auto_load'd when you try to use it.
23:28 Theory joined #parrot
23:31 Coke I'm not sure if I'd expect that to translate nicely to another language, but they're welcome to load the libraries explicitly.
23:32 bacek msg pmichaud Branch (misnamed...) tt24_string_numification is ready for merge. Can you review str_to_num and str_to_int please?
23:32 purl Message for pmichaud stored.
23:33 dalek parrot: r39300 | bacek++ | branches/tt24_unicode_numifications (2 files):
23:33 dalek parrot: [core][t] Handle corner cases of Parrot_str_to_num correctly
23:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39300/
23:33 Coke (so if I call parray, that dispatches to unknown, which tries to auto_load parray, which finds parray.tcl, which loads it, then checks to see if parray is defined now, which it is, and then ends with [uplevel 1 [parray $args]].
23:33 Coke bacek: should I try this out on partcl, too?
23:38 bacek Coke: yes, it will be nice
23:38 Coke bacek: alreayd on it.
23:38 Coke sfsg.
23:38 Coke er, so far, so good.
23:39 Coke bacek: as long as you're working parrot magic, I'd appreciate it if you could look at the bugs linked to from here: http://code.google.com/p/partcl/wiki/ParrotIssues =-)
23:40 Coke bacek: no test failures with partcl in that branch.
23:41 * Coke yays at actually being able to verify that before it hit trunk"!
23:41 Coke (that's a big step for partcl this year. =-)
23:41 bacek :)
23:42 bacek -t1 should work btw
23:42 Coke ORLY?
23:42 purl YA RLY.
23:42 Coke in trunk? (already switching back to trunk)
23:42 bacek in trunk too
23:42 bacek I've fixed couple of issues last week
23:44 Coke hey, parrot tcl.pbc runs a LOT of pir before getting to the % prompt.
23:45 Coke let me try a smaller test. =-)
23:45 bacek :)
23:46 bacek gotta go
23:46 purl EXCUSE ME, I HAVE TO GO WASH MY COMPUTER
23:46 bacek see you soon
23:46 Coke ~~
23:51 snarkyboojum joined #parrot
23:57 Tene Coke: in the sense that use Foo:lang<tcl>; would make sense.

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

Parrot | source cross referenced