% moritz has left moritz!moritz@ssh.faui2k3.org
% ilbot2 has left ilbot2!moritz@faui2k3.org
% ilbot2 has joined #parrot
% ilbot2 has left ilbot2!moritz@faui2k3.org
% moritz has joined #parrot
% iblechbot has joined #parrot
<dalek> r26937 | fperrad++ | trunk:
<dalek> : [digest]
<dalek> : - rename methods without prefixe (more 00)
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26937
% barney has joined #parrot
<dalek> r26938 | bernhard++ | trunk:
<dalek> : Make pairs work. 
<dalek> : Courtesy of rotty.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26938
<barney> https://rt.perl.org/rt3/ seems to be down
<dalek> r26939 | bernhard++ | trunk:
<dalek> : [Eclectus]
<dalek> : Allow easier dumping of the PIR.
<dalek> : Courtesy of rotty.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26939
% cognominal has left #parrot
% wknight8111 has joined #parrot
% cognominal has joined #parrot
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% jan has left jan!~chatzilla@90-229-128-103-no52.tbcn.telia.com
% rdice has joined #parrot
% Unavowed has joined #parrot
% jan has joined #parrot
% AndyA has left AndyA!~andy@82.152.157.85
<dalek> r26940 | bernhard++ | trunk:
<dalek> : #50616: [PATCH] add lists to pynie
<dalek> : Courtesy of Arcady Goldmints-Orlov
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26940
<dalek> r26941 | bernhard++ | trunk:
<dalek> : Give credit to Arcady Goldmints-Orlov
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26941
% kid51 has joined #parrot
% barney has left barney!~bernhard@dslb-084-058-159-208.pools.arcor-ip.net
% AndyA has joined #parrot
% ambs has joined #parrot
<kid51> ambs ping
<ambs> poing
<kid51> Saw your ticket re auto::gettext.
<kid51> This step was added to configuration fairly recently by particle.  
<kid51> I'm not very familiar with gettext myself.
<ambs> neither do I
<kid51> We don't have a formal configuration log.
<kid51> Could you do something like:  perl Configure.pl --verbose-step=auto::gettext 2>&1 | tee ambs.configure.log      
<ambs> I need to look into the gettext.pm file and check what it is tring to do
<ambs> give me a secong
% ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt
% ambs has joined #parrot
<Debolaz> Oooh, my git mirror has almost reached 2006 now.
<ambs> kid51: /usr/bin/ld: cannot find -lintl
<kid51> And you're on Linux, correct?
<ambs> yes
<ambs> I can install intltool and it will pass
<kid51> What is intltool?
<ambs> not sure :D
<ambs> extra/intltool 0.37.1-1
<ambs>     The internationalization tool collection
<ambs> if intl is used, probably the test should be split on two different tests
<kid51> Let me see what I get on Linux.
<ambs> I need to get away for about 30 minutes. BRB
% Senaka has joined #parrot
% ilbot2 has joined #parrot
<ambs> back
<ambs> erm
<ambs> purl says I have one message wayting
<purl> ambs: what?
<ambs> purl: messages
<kid51> you collect them by going into a room with purl (what an exciting prospect!) and saying:  messages
<ambs> hehehe
<ambs> thanks
<Senaka> hi all
<Senaka> I'm supposed to give a report on the features of Parrot GC
<Senaka> can someone give some hints on starting points etc.
<Senaka> ??
<ambs> Senaka: I think there are some documents about it on the parrot source, but not sure
<Senaka> I see
<Senaka> pdd05 and some within GC source
<ambs> pdd09 has something about GC, I think
<Senaka> in addition to that are there anything else?
<Senaka> yes 09 not 05
<Senaka> :)
<ambs> lol
<ambs> ok
<ambs> do not know, then
<Senaka> ok thanks
<Senaka> infinoid is on holiday so kinda need to get someone else's help for the time being
<kid51> Senaka: where do you have to give this report?
<Senaka> to Harmony, the SoC project I work on
<Senaka> Harmony is an Apache project
<ambs> kid51: can I install intltool or do you want to use me as a test case? :)
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
<kid51> ambs:  Am just about to post to list on what I've found; suggest hold off till you read that.
<ambs> ok
<ambs> kid51: you James Keenan?
<ambs> yup
* kid51 agrees with abms on that
<kid51> s/abms/ambs/
<ambs> kid51: can you please check if you have a libintl on your fink installation dir? 
<ambs> (ls /usr/local/lib/libintl* I would say)
% askie has left askie!~askie@81.171.100.207
<kid51> ambs:  Just posted some more data.  Fink installs under sw/, not /usr/local.
<ambs> kid51: yes, /sw. sorry
<ambs> using macports for too long
<ambs> :D
<kid51> But doesn't macports install under /opt/local?   That's what I/we were assuming with the recent creation of config/auto/macports.pm.
<ambs> yes
<ambs> I realled that fink used a different dir
<ambs> but missed it :D
<kid51> On my Linux, I'm going to install gettext from Debian and see what difference it makes.
% tg has joined #parrot
<ambs> at the moment I am installing intltool and check if things change
% askie has joined #parrot
% Senaka has left #parrot
<kid51> Installing gettext simply reinstalled the version I already had; made no difference to Configure.pl.  Now trying to install intltool.
<ambs> kid51: intltool does not include libintl
<ambs> it is a library used by some versions of gettext
<ambs> :-/
<kid51> Ah.  I installed it and it made no difference to Configure.pl
<ambs> probably gettext should be tested with and without -lintl
<kid51> On Linux:  also just installed libintl-perl.  It didn't make any difference, either.  Configure.pl still not finding gettext.
<nopaste> "ambs" at 77.54.92.255 pasted "Simple patch (not)" (13 lines) at http://nopaste.snit.ch/12681
<ambs> kid51: that patch is making it work under linux
<particle> ...and link against libintl.a or libintl.so.  Note that on GNU systems, you don't need to link with libintl because the gettext library functions are already contained in GNU libc.  That is all you have to change.
<particle> how do we detect GNU systems?
<particle> that's from http://www.gnu.org/software/gettext/manual/gettext.html#Overview
<shorten> particle's url is at http://xrl.us/bjbov
<ambs> particle: right
<ambs> that's why my patch works for linux
<ambs> hehehe
<particle> i need libintl on windows
<ambs> try to link the sample code without -lintl
<particle> ...where i developed the step
<ambs> if it doen't work, try with it
<particle> then non-gnu pay a penalty
<ambs> can't it be done this way?
<ambs> particle: I mean, do that on the configure step
<ambs> non-gnu pay a penalty of compiling the sample code twice.. just that
<particle> if we already know if the platform is gnu, we should take advantage of that
<ambs> and, do we know that?
<particle> that's what im trying to figure out
<particle> if you use gcc, does that make you a gnu system?
<particle> if you have gnu libc, then you don't need libintl
<ambs> no
<particle> so, how do we detect whether you have gnu libc?
<ambs> if you use cygwin or mac, you have gcc and need libintl
<particle> and, is that detection done *before* gettext detection?
<particle> it must be, for this to work
<kid51> ambs:  Applying your patch on Linux -> Configure.pl recognizes gettext.  But applying same patch on Darwin leads to problems.
<ambs> kid51: yes, I know :D
<ambs> particle: Determining whether libc has the backtrace* functions (glibc only).....yes.
<nopaste> "kid51" at 71.247.58.244 pasted "Applying ambs's patch on both Linux and Darwin" (17 lines) at http://nopaste.snit.ch/12682
<ambs> this test might help
<particle> is auto::backtrace done before auto::gettext?
<ambs> yes
<particle> great, so we can add a flag to backtrace
<particle> $conf->data->set( glibc => 1 );
<particle> if we have glibc, otherwise set to 0
<particle> then we can look it up later
<ambs> it seems that there is something like
<ambs> #ifdef __GLIBC__
<ambs> that might be handy
<particle> definitely!
<purl> definitely! are you here?
<ambs> purl: no, he isn't
<purl> ambs: excuse me?
* ambs slaps purl.
<purl> o/` Hit me baby, one more time o/`
<nopaste> "kid51" at 71.247.58.244 pasted "grepping for 'libc' under config/" (13 lines) at http://nopaste.snit.ch/12683
* particle wishes Parrot::Configure::Step::List allowed each step to take params
<ambs> hmms
<ambs> parrot configure.pl system should be sensible to the usual CC environment variable.
<kid51> particle:  It used to, but not a single step used those params in any meaningful way.  And when I proposed patch eliminating them, no one objected ... and that was back in September.
<kid51> So we've lived without them for 7 months.
<particle> kid51: it allows cross-compilation scripts to be written
<particle> atm we don't have anybody trying to compile to ps3, but we need that someday
<particle> (or iphone, or whatever)
<particle> it'd sure be nice to have somebody that can test our config system with a cross-compiler
<ambs> perl Configure.pl --cc="$CC" --ld="$CC" --link="$CC"
<ambs> this is kind of b oring :)
<kid51> ambs:  That's what I do on Darwin every time I configure.   So I have it in a shell script.
<ambs> :)
<ambs> looking for a $ENV{CC} might help
<kid51> config/auto/backtrace/test_c.in:  There's no 'glibc' string in this file.  What makes it glibc-specific?
<ambs> if there is a __GLIBC__ define, I would create a new step just for that
<ambs> nice.. (1 subtest UNEXPECTEDLY SUCCEEDED)
<ambs> :D
<particle> Determining whether you have GNU libc......yes/no
* ambs nods
<kid51> Yes, it would seem that we should do that before something more specific like backtrace
<particle> yep
<kid51> Slight tangent:  particle:  What would be the harm/benefits of moving auto::gcc (currently step 11) up before init::hints (step 5)?
<particle> the hints are there to tell configure that you know something about your platform before the config process begins in earnest
<particle> basically, it should be 1) defaults 2) hints 3) detect whatever you can
<particle> of course there may be other stuff, like manicheck there
<particle> it seems to me that init::install should be after hints
<particle> probably same for ::miniparrot
<kid51> Would there be any other way to handle the triggers in config/init/hints/solaris.pm?  That's the only place in the configuration system which uses those gettrigger, settrigger functions.  I was wondering if doing some detecting of gcc could eliminate some of that.
<particle> can solaris's init::hints call auto::gcc?
<kid51> One of its 3 callback functions is concerned with auto::gcc.
<ambs> and there goes another complain about the configure script
<particle> yes. so, inside init::hints, call auto::gcc
<particle> configure steps *should* be able to call each other
% tetragon has joined #parrot
<kid51> That certainly adds to the complexity of the configuration system.
% paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net
<kid51> ... and to its testability.
<particle> it's a plugin system. plugins should be able to call each other. see qpsmtpd for an example
<particle> (or many others)
<kid51> Is that consistent with our 'Parrot::Configure object is a singleton' model?
<particle> sure
<particle> the parrot configure object contains the data
<particle> we only want one instance of that
<particle> the path we take to get the data varies depending on the platform
<particle> e.g. plugins may be called in a different order depending on platform
<particle> some may not be called at all
<particle> some may call others
<kid51> The "some many not be called at all" we basically have now (e.g., 2 darwin-specific steps, 1 win32-specific).  So I grok that.
<particle> right-o
<kid51> But the "called in different order" seems to suggest a potentially much more complex configuration system.
<particle> i don't think it's more complex
<kid51> Since, at least as long as I've been in the project, there has been a single, linear list of config steps.
<particle> *much more
<particle> it'll go something like this:
<particle> when a plugin starts, it asks "has my purpose been fulfilled already?"
<particle> if so, don't run again. if not, run.
<particle> so, it's possible config steps might be called more than once
<particle> say solaris' init::hints calls into auto::gcc
<particle> auto::gcc fulfills its purpose
<particle> init::hints fulfills its purpose
<particle> later, auto::gcc is asked to run again
<particle> but it recognizes that it doesn't have to
<particle> .
<ambs> now, is anybody working on auto::glibc?
<particle> it's a matter of storing the 'fulfillment' flags somewhere and checking them before running the step
<kid51> Okay, but that's not the way we have it now, right?  No step currently has the ability to determine that it has already been run.
<particle> ambs: i thought you were :P
<particle> kid51: i'm not sure. probably not.
<ambs> particle: well, I never wrote a test step on my life,
<kid51> particle:  I think the 3 triggers in config/init/hints/solaris.pm are the only instance where *parts* of config steps are run in a non-specified-in-Step::List time.
<kid51> And I can't recall any code that asks if a *step* has been run -- though of course steps consult the P::C object for the data resulting from steps.
<particle> i think you're correct
* ambs needs to go direct a choir, and will be back in two hours
<ambs> later, folks
% ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt
<particle> we're not looking precisely whether a step has been run already, but that's a good approximation
<particle> good enough for the next few months, for sure
<particle> kid51: is it possible currently to modify the step list at runtime?
<particle> something like add_config_step, delete_config_step
<kid51> No.  Has not been since I've been involved in the project.  Can't say what happened before then.
<particle> probably not before, either.
<kid51> You get something like @steps_list and that's that.
<particle> my rewrite allowed for that, although i'm not sure i got as far as implementing it
<kid51> I saved what you wrote on my disk.  It was interesting, but couldn't sustain other changes we were making in configuration at that time.
<particle> sure
<particle> it would be nice if our plugins weren't so verbose. there's a lot of repeated code
% Ivatar has joined #parrot
% Theory has joined #parrot
<kid51> Everything I've been doing re testing of config steps, refactoring them, has been on the premise that at some future point we will (a) drop interactive configuration and (b) substitute file-based configuration -- and that in preparation for that we should maximize the degree to which we have the current config system tested.
<particle> for example, if we had a step called auto::find_library, and we could call it with params like glibc, libintl etc
% PacoLinux has joined #parrot
<particle> i think we'll add file-based, but keep interactive.
% PacoLinux has left PacoLinux!~paco@139.Red-80-36-122.staticIP.rima-tde.net
<kid51> So I eliminated as much as I could that we weren't actually using .
<kid51> Hey do you/I/we have enough tuits to maintain 3 different approaches to configuration (command-line options being #1)?
<kid51> I vaguely recall asking on list who used interactive prompts during configuration.  Only Andy D said he did, and even he hinted he could probably live without them at some point.
<particle> i can't imagine perl 5's configure without interactive mode
<particle> and the same goes for parrot
<kid51> How often do you use the interactive prompts?  Under what circumstances?  (I've never had to use them.)
<particle> when sysadmins in antarctica are installing parrot 1.0 on some arcane hardware, they may want a hand-holding
<kid51> I suspect that they are only useful to very high-level config experts like Andy D and you.  The rest of us wouldn't know what selections to make at prompts.
<particle> have you build perl 5 from source?
<kid51> Yes.  But, I concede, I just take default options or set options at command-line.
<particle> some folks can't (or don't) do that.
<kid51> Granted, I have not been involved in Parrot as long as/to the same depth as you.  And I have never been a Perl 5 porter.  But I'm starting to feel that in Parrot there's a lot of feature creep.
<particle> there are only a few hundred people worldwide using parrot atm.
<particle> that needs to scale to millions
<kid51> Someone says, "I'd like this."  And, if the person is smart enough to figure out how to do it, it gets done -- whether we really *need* it or not.
<particle> i've never been a perl 5 porter. never want to. yuck.
<kid51> The more complex our configuration or build gets, the more people we need to maintain it.
<particle> it's true that not all the design of parrot is done up front, so you can see some things as feature creep
<particle> and there's currently no design document for our config, build, or test systems
<kid51> I've been thinking of posting about that.  For example, both auto::gettext and auto::crypto were recently added to the step list.  In neither case was there an RT posted saying, "I think we need this.  Please evaluate the need, then evaluate my implementation."  In both cases, they were simply committed to trunk.  Not surprisingly, the first implementations broke.
% tetragon has left tetragon!~seneca@CPE0040d001f62f-CM000a736592a8.cpe.net.cable.rogers.com
<kid51> I think our config system is mature enough and upstream enough that changes to it should be posted first.
<kid51> And (this being kid51), the implementations should come with tests as well as code.
<particle> well, we need gettext for internationalization, which is a requirement for parrot 1.0
<particle> crypto is not a requirement afaik
<kid51> When I was leading the build test in Toronto, I was asked why we have particular config steps.  I couldn't answer.
<kid51> Since I knew nothing when I joined the project, I took the list of config steps as given.
<particle> i understand where you're coming from, and what you're saying.
<kid51> I've refactored some into new steps, split some, joined some -- but haven't myself added steps which seek new information about the system.
<particle> do you want to?
<kid51> No, because I don't have a deep enough understanding of what a virtual machine *must* have.
<kid51> Which is 'cause I can only get Dan to go out for beers with me 2x/year ;-)
<particle> well, i think we basically have everything we need in config for 1.0 now.
<particle> there may be a lib here or there that we need to look for, but i can't think of any offhand
<kid51> Among other things, if we had a better design document for our config/build/systems, it would provide better guidance for someone like me who is (retrospectively) writing tests for one of those systems.
% ruoso has joined #parrot
<particle> we haven't targeted writing a design doc for those subsystems, since we only have so much bandwidth
<particle> it may happen down the road, but i don't expect anything until fall
<kid51> And, of course, that lack of bandwidth/tuits, is why feature creep should be avoided.
<kid51> Perhaps we should be asking:  What do we currently have in configure/build that we *don't* need for 1.0 -- and can we take it out?
<particle> right
<particle> gnu m4 for example
<particle> that shouldn't be in parrot's configure
<particle> it should be in languages/eclectus's configure
<particle> probably same with python
<kid51> I tend to agree.  Among other things, I haven't been able to figure out how to write meaningful tests for it -- and for me that's a sign that code is either unnecessary or unmaintainable.
<kid51> I also wondered about python.  I can't find any use of it in 'make', so I never understood why it was in configure.
<kid51> I would certainly welcome it if you posted RTs asking whether those steps could be excised.
<particle> barney added those steps during his hll development
<particle> instead, they should be hoisted into the languages that need them. languages/dotnet has its own Configure.pl, which is the right way to do it
<kid51> I've come to realize there are a number of issues in the configure system.  (1) What needs to be probed for?  (2) How those probes are conducted?  (2a) Whether those probes are to be conducted in C or in Perl 5 (or what mixture)?
<particle> eventually, all probes should be in c
<particle> but now we rely on perl 5's config
<particle> kid51: can we switch up to the config tests?
<particle> they're too resource-intensive. i think you're checking for the same thing multiple times
<kid51> I wasn't referring to the reliance on P5 config.  What I meant was:  I can take responsibility for the soundness of the Perl 5 code in the config steps, but I don't have the understanding of what should be probed for, nor I can I write the C test.in files.
<kid51> What do you mean 'switch up to'
<particle> switch the conversation over to
<kid51> Well, I welcome that conversation, but I haven't had any breakfast yet.  It's after noon ET.  So are yuou going to be around later?
<particle> sometime later, yes
<kid51> k
<particle> enjoy
% kid51 is now known as kid51_afk
% Senaka has joined #parrot
<dalek> r26942 | jonathan++ | trunk:
<dalek> : [rakudo] Refactor the scoped_declarator action somewhat, fixing 'has $.foo' in the process.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26942
% japhb has joined #parrot
<japhb> I'm thinking of using git-svn to work on Parrot, but I'm new to it ... any git-svn users on this morning?
<Senaka> what could cause parrot/blib/lib/libparrot.so: undefined reference to `data_types' ??
<Tene> japhb: I use it.
<dalek> r26943 | fperrad++ | trunk:
<dalek> : [uuid]
<dalek> : - add a minimalist uuid library
<dalek> : - and tests
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26943
<dalek> r26944 | fperrad++ | trunk:
<dalek> : [Lua]
<dalek> : - add uuid library
<dalek> : - and tests
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26944
% Senaka has left Senaka!~senaka@124.43.200.33
% chromatic has joined #parrot
<japhb> Tene: sorry for delay, just when I thought I had a few minutes, I get pulled away.  Anyway, is Sam Vilain's tutorial at http://utsl.gen.nz/talks/git-svn/intro.html still "correct" in the sense that the advice there is reasonably accurate now that a year has passed?  And is cloning from repo.or.cz still the best choice?
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
<Tene> japhb: I just used the -r argument to git-svn fetch to avoid fetching all of the history.
<Tene> git-svn init https://url/ ; git-svn fetch -r 26944
<Tene> oslt
<Tene> Of course, if you're nto committing directly from git-svn, it won't make much difference.
<Tene> There's some delay going through repo.or.cz, as I understand.
<jonathan> chromatic: You note that "We have a dynamic system such that we can add and remove parents as well", but actually once a class is instantiated that's not true any more.
<jonathan> You have to clone it to then be able to make changes, but then it's a different class.
<chromatic> I'm not sure that restriction will last in the face of Perl 6 or Perl 5 though.
<jonathan> I thought Perl 6 classes had these semantics? Perl 5, I agree with though.
<chromatic> I don't remember exactly what P6 specifies there.
<jonathan> But even then, we could build some kind of cache and invalidate it/rebuild it if needed.
<chromatic> Yeah, I've been fiddling with how to do that.
% kid51_afk has left kid51_afk!~jkeen@pool-71-247-58-244.nycmny.east.verizon.net
% Senaka has joined #parrot
<Senaka> chromatic:ping
<Senaka> : ping
<chromatic> Howdy.
<jonathan> Could we generate an array of invokable objects for each vtable entry and instantiaton time?
<jonathan> That is, the array index matches the index we'd use into the VTABLE.
<jonathan> And it tells us what to invoke, right away.
<Senaka> chromatic: C++ build can be patched w/o any prob
<chromatic> Excellent, Senaka.
<jonathan> When I say instantiation time, I mean the first instantiation of the class.
<Senaka> but, at the end I get /blib/lib/libparrot.so: undefined reference to `data_types'
<chromatic> I don't exactly follow.
<Senaka> so this is some linking issue i guess
<chromatic> Senaka, include/parrot/datatypes.h
<jonathan> Essentially, I mean we just pre-compute what things we call for each v-table method.
<Senaka> yep so y not in C but in C++
<chromatic> line 126?  Is there a warning?
<jonathan> On the condition that we re-compute it if the class hierarchy changes.
<chromatic> Pre-computing isn't difficult.  I think we can flatten everything into the vtable_overrides slot when we instantiate things.
<chromatic> Invalidation is a little trickier.
<jonathan> Well, if we flatten all into vtable_overrides then introspection on that maybe becomes fun. :-)
<jonathan> As you can't tell exactly what was overridden by that specific class.
<Senaka> chromatic "extern C" is required I guess
<Senaka> will add those to headers
<Senaka> and try