Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2008-09-09

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

All times shown according to UTC.

Time Nick Message
01:25 particle1 joined #parrotsketch
03:13 particle joined #parrotsketch
13:43 rdice joined #parrotsketch
13:58 clinton joined #parrotsketch
13:58 clinton left #parrotsketch
14:09 DietCoke_ joined #parrotsketch
14:09 DietCoke_ KJS's report:
14:09 DietCoke_ * many cleanups and code refactoring for pirc/new
14:09 DietCoke_ * linking to libparrot is now possible (after figuring out link flags); see README for details for windows (no access to linux; and parrot on cygwin doesn't build). This is a huge step forward.
14:09 DietCoke_ * this means that all Parrot functions are now accessible, allowing for checking whether an identifier is an op
14:09 DietCoke_ * also implemented .loadlib, which can be used to load a dynamic oplib: this works as well.
14:13 davidfetter joined #parrotsketch
15:16 pmichaud joined #parrotsketch
15:25 rdice joined #parrotsketch
15:56 rurban joined #parrotsketch
16:35 NotFound joined #parrotsketch
17:04 paco joined #parrotsketch
17:14 rurban_ joined #parrotsketch
18:20 dmknopp joined #parrotsketch
18:22 jhorwitz joined #parrotsketch
18:26 Tene * More work on Cardinal
18:26 chromatic joined #parrotsketch
18:26 Tene * I want to get a commit bit for dmknopp. He has a CLA ready to send in.  What does everyone else think?
18:27 cotto_work I think you're a little early ;)
18:27 Tene * A few experiments on HLL compatibility for P6object and HLLcompiler, but nothing good enough to commit
18:27 NotFound Say hello at least ;)
18:28 Tene * EOR, now I run away to drive in to work
18:28 * Tene is a bit late getting in to the office.
18:28 * pmichaud notes that Tene also added 'hll_map' to the interpreter object, which is *hugely* important.
18:28 pmichaud (and was committed)
18:30 moritz DietCoke pre-posted KJS' report earlier
18:30 * jhorwitz materializes
18:30 chromatic aloha
18:31 rurban hello
18:31 NotFound H
18:31 cotto_work i
18:32 allison joined #parrotsketch
18:32 chromatic Alphabetical order?
18:32 moritz that would be allison first
18:33 moritz *hilight*
18:33 allison - Mostly working on the multiple dispatch branch, for code consistency and fixing failing tests.
18:33 allison - Migrated the 'infix' virtual opcodes over to real opcodes.
18:33 allison - Deprecated 'cmodulus' vtable functions.
18:34 allison - The old 'n_*' versions of the opcodes are gone, and the regular versions now create a new PMC for the result by default.
18:34 allison - Made it possible for new pcc_invoke function to invoke PIR subs as well as NCI subs.
18:35 allison EOR
18:35 chromatic I fixed a bunch of bugs, some in the MMD branch but most in trunk.
18:35 rdice joined #parrotsketch
18:35 chromatic cotto_work?
18:35 cotto_work *not much specific, mostly just tickets necromancy
18:36 cotto_work *found several to close, some to raise for discussion and a couple I can work on
18:36 cotto_work eor
18:36 chromatic japhb?
18:37 barney joined #parrotsketch
18:37 chromatic jhorwitz?
18:37 jhorwitz submitted mod_perl6 talk for pittsburgh next month.
18:37 jhorwitz due to a design flaw in mod_parrot, i increasingly found myself writing code to provide functionality that Apache already has.  sparing the details, i'm now refactoring all HLL layers into their own Apache modules.  this eases the burden on mod_parrot by forcing HLLs to manage their own configuration data and Apache hook registration.  but it's difficult work and is taking some time.
18:38 jhorwitz (that was a mouthful)
18:38 jhorwitz EOR
18:38 chromatic barney?
18:38 barney nothing to report.
18:39 barney .eor
18:39 chromatic moritz?
18:39 moritz * usual testing/patching work
18:39 moritz * hacked the PGE tests into Perl 6 tests, with help from Larry got us a few hundred more tests, another 250 depend on  infix:<where> and parsing q/.../
18:39 moritz * hacked a bit on nqp and rakudo NCI examples (NotFound++ for them)
18:39 moritz KTHXBY
18:40 chromatic NotFound?
18:40 NotFound * Some work in debugger
18:40 NotFound * Created Xlib and Mysql modules and test programs in examples/nci/
18:40 NotFound * Fix some nci and UnManagedStruct problems in the process
18:40 NotFound * Applied patch from mhelix that solves several parameter passing problems
18:40 NotFound * Some others patches applied
18:40 NotFound * Renamed PMC attributes structs, RT#48014, pdd17
18:40 NotFound Three questions
18:40 NotFound EOR
18:40 chromatic particle?
18:41 chromatic pmichaud?
18:42 pmichaud PCT:
18:42 pmichaud * Fixed 'loadinit' attribute for PAST::Block in PCT
18:42 pmichaud * Discussions on dynamic HLL type mapping
18:42 pmichaud Rakudo:
18:42 pmichaud * Removed ':immediate' blocks from Rakudo code generation
18:42 pmichaud * ./parrot perl6.pbc --target=pir   now generates standalone executable PIR
18:42 pmichaud * Updated Failure type to generate warnings when used as a value
18:42 pmichaud * Added '!FAIL' and 'fail' builtin functions
18:42 pmichaud * Fixed bug in Code.REJECTS
18:42 pmichaud * Figured out a way to do inline PIR in Perl 6 source, so we can write builtins in Perl 6.
18:42 pmichaud Misc:
18:42 pmichaud * Working on my Mozilla Foundation grant final report
18:42 pmichaud * Answered lots of questions here, there, and on the mailing list
18:42 pmichaud * Reminder that Parrot release is next Tuesday
18:42 pmichaud * Please update NEWS, CREDITS, PLATFORMS, etc.
18:42 pmichaud eor
18:42 chromatic rurban?
18:42 rurban * particle gave me a commit bit, thanks. Need a mentor. For jvm I need jonathan. dotnet will get something back hopefully.
18:42 rurban * Worked with allison on pdd30_install.
18:42 rurban * Updated cygwin070patches with more make install tuning and cleanup: make installable creates now runtime/parrot/library/$HLLNAME.pbc for HLL interop.
18:42 rurban * "make languages" works now also with already installed shared libparrot, just win32 not yet.
18:42 rurban * A few langs need a runtime/parrot/library/$HLLNAME subdir: WMLScript and forth
18:42 rurban * Change: "make all" is for all, "make build" is for the default target only.
18:42 rurban * cygwin070patches should be ready to merge.
18:42 rurban * Added a new language to my branch: jvm (20%) and a new perl5 lib lib/SRM, moved over from dotnet. SRM is for stack-bytecode => register mapping. It is now generalized and can be used for dotnet + jvm; later probably WMLScript also.
18:42 rurban two questions
18:42 rurban EOR
18:44 moritz Tene posted his report earlier
18:45 pmichaud tewk?
18:46 chromatic Did we miss anyone?
18:46 chromatic Alright, rurban.  Question time.
18:47 rurban * runtime/parrot/library/$HLLNAME.pbc and subdir ? For me this sounds most natural and needs no additional libpath entry. See forth and WMLScript in the cygwin070patches branch.
18:47 rurban 2nd: * Should I try to be jvm cleanroom compatible or with Sun's recent GPL step should I not care? I need some simple external classreader sources in C, like KAFFE or Hotspot.
18:47 rurban KAFFE is good enough IMHO, but I want to compare it to the original. Google's new v8 is in C++, so I guess Hotspot is also in C++. They have a Sun License, which looks good to me.
18:48 chromatic As long as you don't include code directly, any OSI-approved license should be fine as source material for ideas.
18:48 pmichaud runtime/parrot/library/$HLLNAME.pbc works good for me.  It might be good to explore how we decide the values of HLLNAME (perhaps on list is better)
18:48 allison runtime/parrot/library/$HLLNAME.pbc and runtime/parrot/library/$HLLNAME/... is a fine place to start
18:48 rurban ok, that's in my branch now.
18:48 pmichaud for example, is it "Perl6", "perl6", or "rakudo"?
18:49 allison and, as chromatic said, linking is fine, copying is not
18:49 rurban perl6 is different :) the existing p6 pbc's just
18:49 pmichaud "Ruby", "ruby", "cardinal", ...?
18:49 rurban cardinal.pbc
18:49 rurban the HLLNAMEis the name of the languages dir
18:49 moritz whatever the current directory name under languages/ is?
18:49 rurban exactly
18:50 pmichaud I ask because it might also impact the names we use for 'compreg' and 'load_bytecode'
18:50 rurban that will also be the name which is registered with compreg and the pbc name
18:50 rurban and load_bytecode of course, thanks
18:50 allison eventually we will need to allow languages to register and be used under multiple names
18:50 pmichaud so, it would be     load_bytecode 'cardinal.pbc'   and   $P0 = compreg 'cardinal'     ?
18:50 rurban yes. different from that are the various frontend executables, like net2pbc
18:50 allison but, that can be later
18:51 pmichaud well, languages can already register under multiple names for compreg
18:51 rurban ok, like an alias
18:51 pmichaud it's the load_bytecode one that is tricky :-)
18:51 allison rurban: yes language aliasing
18:51 pmichaud although if compreg could also automatically load the corresponding bytecode, that would be cool too
18:51 rurban please not too much magic
18:52 rurban I'm only worried about HLLNAME changes as with pipp lately
18:52 pmichaud we know there needs to be some magic if    "parrot --prog=cardinal"  is to work
18:52 allison I don't see much need to monkey with the name of the bytecode file, at least not now (maybe Parrot 2.0)
18:53 rurban this coudl work via symlink and $0 resolution
18:53 allison on platforms that support symlinks, yes
18:53 pmichaud would it be fair to say then that  "parrot --prog=foo"  automatically grabs foo.pbc from runtime/parrot/library  ?
18:53 chromatic Not all platforms or filesystems support symlinks.
18:53 jhorwitz and we need to consider embedded apps
18:53 allison pmichaud: yes, but --language=foo instead of --prog
18:54 rurban --language++
18:54 pmichaud we'll treat all symlinked applications as languages, then?
18:54 pmichaud parrot -language=apache ...   ?
18:54 jhorwitz that doesn't seem right...
18:54 pmichaud or, more likely
18:54 pmichaud parrot --language=httpd ... ?
18:55 allison you mean a case of making parrot pretend to be apache or httpd?
18:55 pmichaud yes
18:55 pmichaud i.e., something other than a language translator
18:55 rurban but note that the pbc is mainly a HLL lib, not a language
18:55 allison if it's ever used for something other than languages, we can introduce another flag
18:55 pmichaud i.e., we have $0 set to run a program from parrot
18:56 allison How about "parrot --language=foo" automatically grabs foo.pbc from runtime/parrot/library/language
18:56 allison (note the added subdirectory)
18:56 rurban also not bad.
18:56 pmichaud with runtime/parrot/library/language/$HLLNAME ?
18:56 chromatic Why not runtime/parrot/language ?
18:56 NotFound One can even imagine a minmalistic linux distribution whith parrot where most commands are parrot symlinks.
18:56 pmichaud yes, I think I like runtime/parrot/language
18:56 rurban that woudl need a library.c and libpatch change
18:57 jhorwitz +1
18:57 rurban libpath
18:57 allison and then, if at some point we need to add some other semantics besides languages, then we have a sensible hook for a different location
18:57 allison yes runtime/parrot/language is sensible
18:57 pmichaud but I agree with NotFound -- if we think along the lines of busybox type stuff (very reasonable with Parrot), then --language may be a bit too narrow in scope
18:57 pmichaud I like having runtime/parrot/language... except then we'd want load_bytecode to be able to easily get to stuff from there as well
18:58 Tene queue one question from me
18:58 pmichaud although perhaps load_bytecode "language/perl6.pbc" might work
18:58 pmichaud (with current implementation)
18:58 allison too much magic, better is load_language "perl6"
18:58 allison which could do the compreg bit too
18:58 pmichaud well, that already happens.  :-)
18:59 pmichaud load_bytecode 'perl6.pbc' causes the :load subs to execute (which register the compiler)
18:59 rurban I like the load_language "perl6" idea
18:59 pmichaud I do have some qualms about introducing a separate opcode, though
18:59 pmichaud it's nicer if we think of languages as being libraries (which, in a sense, they really are)
18:59 rurban then we need no addiitonal libpath entry, which would slow the other load_bytecode calls down
19:00 pmichaud otherwise when I say   "use Python;"   there has to be something that knows whether to call "load_bytecode" or "load_language"
19:00 allison languages are more than libraries, and down the road they're likely to diverge further
19:00 NotFound load_bytecode time is mainly disk access, a little cpu time will never be noticed.
19:00 pmichaud and, going back to our discussion at YAPC::EU, we're also looking at "run_bytecode" and "load_bytecode" ops
19:01 pmichaud which means we'd want "run_language" and "load_language"?
19:01 allison pmichaud: saying "use Python;" to load a language library is a pretty uniquely Perl6-ish thing
19:02 pmichaud allison: fair enough.
19:02 rurban well for now the languages occupy the general lib namespace in library. let's see how crowded it will get there I would suggest.
19:02 allison and, you're already doing magic, because Python.pbc /Python.pir doesn't actually exist in the Perl 6 namespace
19:02 pmichaud I still think it's better if we treat languages as libraries, but I'll not push it.
19:02 allison didn't we decide we didn't need 'run_bytecode'?
19:02 allison well, they'll still be libraries
19:02 pmichaud I said I could work around it.
19:03 NotFound We can have a minimal lib that loads the language in his init, if some language need that.
19:03 allison and, you can still load them with load_bytecode "path/to/wherever/foo.pbc"
19:04 rurban note the analogue to compilers. nqp was formerly a language, now it's library, and now even one without installed pbc
19:04 pmichaud (run_bytecode)  it's still the case that we'd like to be able to specify functions that run after everything else is loaded
19:04 pmichaud currently the only way to do that is to put the function at the end with a :load flag
19:04 allison pmichaud: okay, we should probably start a ticket for 'run_ bytecode', then
19:04 chromatic Tene had a question (and rurban still has one queued)
19:04 pmichaud which gets complicated if it has any nested lexical blocks (which would have to be after that)
19:05 NotFound Don't forget my questions!
19:05 Tene I want to get a commit bit for dmknopp to help him work on cardinal.
19:05 NotFound They are short, I promise X-)
19:05 chromatic Tene, can you mentor him?
19:05 allison pmichaud: (a separate :flag that marks subs to be run after everything else has been loaded might also be a possibility)
19:05 Tene Yes.
19:06 chromatic Any objections?
19:06 pmichaud allison: yes -- this is effectively what :main does now for running from command line
19:06 pmichaud no objection
19:07 pmichaud (and yes, if we had such a flag we don't need run_bytecode)
19:07 pmichaud (assuming we always wanted it run with load_bytecode)
19:08 allison re: dmknopp: no objections
19:08 allison pmichaud: yes, I like having one load function, and leaving the decision of what routines to run when to the module author
19:09 pmichaud allison: meaning the caller never gets to decide, except by some agreed-upon out-of-band convention
19:09 pmichaud (which is okay, just pointing it out.  Sometimes we want to load-but-not-run)
19:11 Tene dmknopp: You have the address to mail the CLA?
19:11 dmknopp 7456 SW Baseline Road #220
19:11 dmknopp Hillsboro, OR 97123
19:11 dmknopp USA
19:11 dmknopp is listed on the form
19:11 allison dmknopp: that's correct
19:12 dmknopp ill send it off then. :-)
19:12 pmichaud allison:  I'll send a description of the current workaround that Rakudo is having to use to the mailing list so you can think about it there.
19:12 allison pmichaud: sounds good
19:13 rurban My 2nd question was answered I guess, if I may look at the Hotspot source.
19:13 rurban (Because to paste the structs from the pdf specs is awful)
19:14 NotFound My first question: some languages have docs/ and some have doc/. Shall we open a TODO to standarize on docs/?
19:14 allison rurban: yes you can look at the source, but you can't copy from it
19:14 Tene NotFound: why standardize on docs instead of on doc?
19:14 rurban May I copy from KAFFE? This is GPL.
19:15 NotFound Tene: because the root tree has docs/
19:15 allison rurban: no, Parrot is Artistic, not GPL
19:15 moritz unix as doc/
19:15 rurban ok.
19:15 moritz *has
19:15 rurban I'm for doc
19:15 moritz rurban: maybe you can ask the KAFEE folks if they can release the headers also under Artistic
19:16 NotFound If not docs, add rename the base docs to whatever.
19:16 allison rurban: It's unlikely we'll be able to use anyone else's source directly anyway, they're all stack-based
19:16 rurban ok, I'll do. What I really want is to copy the classfile reader source (because of the stupid zip uncompression)
19:16 moritz allison: for parsing jvm bytecode, I think
19:16 rurban yes.
19:17 allison rurban: we can link to an external library
19:17 allison we just can't copy it into the source tree
19:17 rurban ok.
19:19 moritz any comments on NotFound's question?
19:19 pmichaud is consistency of doc/ vs. docs/ terribly important?
19:19 pmichaud I'd hate to rename the source tree and break a number of (external) links
19:19 NotFound pmichaud: that is the question, precisely.
19:19 allison standardizing on one (doc/docs) for languages in the parrot repository seems sensible
19:19 allison not critical
19:20 rurban I would only rename the languages docs to doc
19:20 allison and for languages outside the parrot repository we won't impose any standard
19:20 rurban make it easier to podlink L<> to other langs (as I do from jvm to dotnet e.g.)
19:20 pmichaud rakudo went with "docs/" because that's what parrot trunk was using.
19:21 allison rurban: you can't assume any one standard across all languages
19:21 pmichaud and there are links in various articles and blog posts directly into the svn repository
19:21 rurban it's just a nice to have if done early enough
19:21 NotFound We can put a recommendation for new languages, no ticket for anow.
19:21 rurban good point
19:21 pmichaud so renaming docs/ to doc/ would break all of those links
19:22 moritz does tools/dev/mk_language_shell.pl generate doc/ or docs/
19:22 moritz ?
19:22 pmichaud (and yes, they'll break *anyway* when rakudo moves out of the parrot repo, but that's a different sort of breakage.)
19:22 particle moritz: neither iirc
19:22 moritz pmichaud: is that planned?
19:22 allison docs/ is the parrot standard, I can't think of any particular other standard we're trying to meet
19:22 moritz then it might be a good idea to generate a stub directory with the "right" name
19:23 pmichaud moritz: is what planned?
19:23 rurban I want a docs/running.pod for every language which has no good man page.
19:23 allison mortiz: yes, all the languages will be moving out of trunk at some point
19:23 allison moritz: or, at least all HLLs
19:23 NotFound Second questions: integer overflows: we have some guide about what to do, throw an exception or something? Both for int registers and for pmc.
19:23 particle "all" except examples like abc
19:23 rurban which point? in 2008?
19:23 pmichaud not likely in 2008.
19:23 moritz allison: before 1.0?
19:24 particle yes, before 1.0
19:24 allison moritz: at some point soon after we get a language install process that works
19:24 * particle heard rurban is working on that ;)
19:24 pmichaud ...and (hopefully) when Parrot is a bit more stable?
19:25 pmichaud the primary reason for having languages in the trunk is to keep close coordination between Parrot changes and languages
19:25 allison pmichaud: that too, which will also be quite soon
19:25 rurban I did no install lib for all the langs. I copied the same for all langs.
19:25 Tene rurban: is there a doc in parrot that specifies what pod files a language should have?
19:25 allison rurban: come again?
19:26 Tene rurban: all I have is you mentioning some pod file names on IRC a few times.  Can you write up what you want, what each pod file needs, etc and add it as a doc somewhere?
19:26 rurban I thought about a make install framework to make it easier an consistent. For now the same steps are just copied to all makefiles.
19:26 barney MAINTAINER should be there for all HLLs as well
19:26 rurban this pod is pdd30_install.pod
19:26 rurban in pdds/draft
19:27 pmichaud since languages are eventually moving out of trunk, I would expect individual languages to maintain their own 'make install' target.
19:27 particle yep, languages must be self-contained
19:27 rurban But to make future installations easier for external libs and langs we need a lib as perl5 MM
19:27 particle their own configure (if needed), build, test, and install
19:27 rurban Or Module::Build (shudder)
19:28 allison rurban: a manual copy between makefiles is fine for now (the makefiles are all generated anyway), but yes, they will all need their own ability to install
19:29 allison rurban: we may need to go that far eventually, but to start with all we need is to define what steps the language will need to take to install
19:29 rurban That's defined in my draft. Almost
19:29 allison rurban: and include that in the default makefile template generated for new languages
19:29 rurban the wanted pods and the name of the docs dir are not defined yet
19:29 rurban ok, will do.
19:30 particle we've just hit the 1h mark. anything else that can't be disussed in #parrot or via email?
19:30 pmichaud did we decide on parrot/runtime/languages ?
19:30 allison pmichaud: yes
19:30 pmichaud okay.
19:30 NotFound Repeat second question: integer overflows: we have some guide about what to do, throw an exception or something? Both for int registers and for pmc.
19:31 particle wait. is that runtime/parrot/languages?
19:31 pmichaud particle: yes, I had it backwards.
19:31 allison for PMCs, integer overflows go to BigInts
19:31 particle r/p/l++
19:31 allison well, it should be parrot/runtime/languages :)
19:31 pmichaud and --language=foo automatically runs parrot/runtime/languages/foo.pbc ?
19:32 allison runtime/parrot was designed with the intention of runtime/perl runtime/python
19:32 particle it can be runtime/languages/. we don't need parrot/ in the source tree
19:32 rurban parrot/runtime/languages makes no sense. runtime will be dropped when installed
19:32 rurban runtime/parrot => lib/parrot
19:32 allison so, maybe, instead of whatever/runtime/languages, it should just be runtime/mylanguage/mylanguage.pbc
19:33 pmichaud keep in mind that I expect nqp.pbc and perl6grammar.pbc to follow suit
19:33 particle allison: that's how runtime/ was originally designed
19:33 rurban uh. pollution
19:33 NotFound Last question: must I move Xlib and Mysql from examples to runtime library?
19:33 particle parrot is just another hll name
19:33 allison let's move the path conversation to further discussion on the list and in pdd30
19:33 rurban parrot should be the base of all. perl6 is just a HLL imho
19:34 pmichaud (on list)++
19:34 rurban :)
19:34 allison NotFound: why would you need to?
19:34 particle notfound: if you intend to make full libraries out of them, it makes sense
19:34 NotFound allison: easier to test
19:34 rurban I would like to see a mysql and Xlib library as OpenGL and Pg
19:34 particle if they're intended not to grow beyond their current state, they're fine as examples
19:34 pmichaud (because load_bytecode doesn't look in examples/)
19:35 allison seems more like a problem with load_bytecode than anything else
19:35 NotFound To test for other people interested, not by me, of course.
19:35 allison we don't currently have a way of adding to the parrot equivalent of @INC, but need one
19:35 rurban @INC hook++
19:36 allison (it will not be called @INC :)
19:36 rurban pushlib <dir>
19:36 NotFound The intention is to grow both, but they are big things, don't know how fast will be the process, or how many people will help.
19:37 allison NotFound: move them out if they grow big enough to be part of the "standard" library, but don't move them out just to make testing easier
19:37 particle push_library_path/unshift_library_path
19:37 NotFound allison: ok
19:38 pmichaud NotFound: Note that Rakudo *does* have @*INC, and you can use that.
19:38 allison mostly, I'll like the core install to grow smaller, not larger, and work out the installation process for other modules
19:39 NotFound particle: as methods for the interpreter pmc?
19:39 allison steer clear of "push" and "pop", use more general words like "add_library_path"
19:39 allison NotFound: as opcodes
19:40 pmichaud speaking as a HLL implementer, opcodes are evil.
19:40 pmichaud methods are much easier to work with.
19:40 allison they may modify the interpreter, or they may bodify a sandbox
19:41 allison except that methods on the interpreter mean you're modifying the interpreter directly, which is also evil
19:41 pmichaud fair enough.
19:41 allison and if opcodes are evil, we have a serious problem
19:41 pmichaud opcodes aren't modifying the interpreter, then?
19:41 chromatic The search paths *are* attributes of the interpreter.
19:42 allison the opcode is an interface, it can do anything behind the scenes
19:42 rurban sidenote - I'll make 2nd branch with the 2nd path suggestion, language libs parallel to parrot. runtime/HLLNAME/library/HLLNAME.pbc runtime/HLLNAME/dynext/HLLNAME_group.dll and such. This will need library.c changes and a new opcode/method
19:42 pmichaud that sounds to me like a method :-)
19:42 chromatic That's fine, but these opcodes are going to modify interpreter attributes behind the scenes.
19:42 allison it may modify the interpreter, but it may also run it through security filters, or capture it in a sandbox
19:42 pmichaud "a method is an interface, it can do anything behind the scenes"
19:43 allison yes, but a method is an interface where you've already selected what object to modify
19:43 pmichaud anyway, the only "evil" part is that HLLs end up having to wrap opcodes with subroutines or method calls anyway
19:43 allison an opcode gets to select the object too
19:43 NotFound The pmc method can just call the same function than the opcode, as a helper to hll
19:43 chromatic That object is going to be the interpreter.
19:43 allison not necessarily, it may be a sandboxed COW interpreter
19:44 * particle moos
19:44 chromatic It's not going to be an interpreter, it may be an interpreter!
19:44 allison or, it may be a thread
19:44 NotFound allison: in that case, getinterpreter will return the same, it isn't?
19:44 pmichaud even if it's a sandboxed COW interp, I would expect getinter..... right
19:45 particle anyway, we need a way of adding paths (or code objects) to the list of library search paths both at beginning and end
19:45 allison yes, but getinterpreter is just an opcode
19:45 particle *getinterp
19:45 allison so, you'd rather call an opcode and a method than just an opcode?
19:45 chromatic Yes.
19:45 pmichaud from a HLL perspective, it ends up being a Parrot sub that calls an opcode.
19:45 chromatic I might not want to change the library paths on the current interpreter.
19:45 pmichaud it's never "just an opcode".
19:46 pmichaud (except for opcodes that tend to map directly to hll operations)
19:47 NotFound The question for integer overflow on registers is pending.
19:47 pmichaud so, my choice is either (1) fetch an interpreter object and call a method on it, or (2) call a wrapper sub that invokes the opcode.
19:47 allison we're getting too tied up in the small details, especially considering we don't even know what the proposed method/opcode will do yet
19:48 pmichaud yes, but I'm speaking somewhat in generalized terms.  From an HLL perspective, having lots of specialized opcodes isn't as useful as having methods.
19:48 pmichaud Use that for whatever it's worth.  :-)
19:48 rurban load_language
19:48 allison pmichaud: okay, that's useful information
19:48 chromatic It modifies the array stored in IGLOBALS_LIB_PATHS.
19:48 NotFound We can start by adding a function, and a command line option to set it.
19:48 NotFound A C function, I mean.
19:49 pmichaud a good example of the principal is in the compiler objects we're creating (and registering with compreg).... calling methods on those objects is much more useful than specialized opcodes for it
19:49 allison NotFound: good potential starting point
19:49 pmichaud another example is ParrotIO -- methods on an object are much more useful than specialized opcodes
19:49 allison ParrotIO is moving in that direction
19:49 pmichaud yes
19:50 rurban but other HLLs need to load this language at first somehow.
19:50 allison NotFound: on overflowing integers, if they can't be converted to BigInt PMCs (the context doesn't allow for that kind of change), then it's an exception
19:52 particle of course, it's probably an exception of type Inf or NaN, which isn't really specced
19:52 pmichaud I would think it's a range exception
19:53 particle pmichaud: does your expectation change if we substitute num for int?
19:53 NotFound Is useful to not mix integer overflow with float or bigint ones, I think.
19:53 NotFound Some languages may need to catch it to do whay their standard mandates.
19:54 particle ok, so int overflow is a range exception, and the maxint value is dependent on configuration parameters
19:54 pmichaud particle:  if the question is "are we generating values that can't be stored in the available types", that sounds like a range exception to me
19:54 allison how about an integer overflow exception
19:55 NotFound ++
19:55 pmichaud the canonical examples are probably:    add $I2, $I0, $I1     and    add $N2, $N0, $N1
19:56 particle yes, but with NREG, Inf and NaN representations are built in to the data type
19:56 particle we may differentiate between NaN and NaNQ
19:57 particle where the former throws an exception as well as sets the value in the NREG
19:57 pmichaud Inf doesn't sound right to me -- I think of that as being fundamentally different than simply "out of range"
19:57 particle the latter just sets the value
19:57 pmichaud but we're at the edge of my expertise on the issue, so I'll shut up now.  :-)
19:58 particle well, it doesn't need to be settled today anyway
19:58 allison I think we've generally run to the end of what can be done in IRC discussion on these topics, any further questions before we wrap up?
19:59 * moritz counts that as a "no"
19:59 allison Sounds like a no. Thanks for joining us, tty next week!
20:00 rurban bye
20:00 moritz bye
20:00 NotFound B
20:00 chromatic left #parrotsketch
20:01 NotFound left #parrotsketch
20:01 rurban left #parrotsketch
20:04 dmknopp left #parrotsketch
20:58 jhorwitz left #parrotsketch
21:34 paco left #parrotsketch
22:00 particle joined #parrotsketch
23:05 davidfetter joined #parrotsketch
23:52 wknight8111 joined #parrotsketch

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