Parrot 0.6.0 "P&P" released | Please mentor for SoC | parrotcode.org/
Set by moderator on 7 April 2008.
dalek r26934 | chromatic++ | trunk: 00:49
: [PMC] Added fullname cache to list of PObjs to mark in Class PMC. A little
: caution is a good thing (see r26928 for the culprit).
diff: www.parrotvm.org/svn/parrot/revision?rev=26934
r26935 | chromatic++ | trunk: 01:00
: [PMC] Added a string_copy() missed in the previous two commits to Class PMC's
: get_string() vtable entry.
diff: www.parrotvm.org/svn/parrot/revision?rev=26935
01:00 darbelo left 01:22 kid51 joined
cotto_work seen jks 01:53
purl jks was last seen on #poe 5 years and 10 days ago, saying: hachi: :-( [Apr 3 17:08:32 2003]
cotto_work seen kjs
purl kjs was last seen on #parrot 83 days and 10 hours ago, saying: but that's not entirely true actually.. [Jan 19 08:11:04 2008]
cotto_work seen kj 01:57
purl kj was last seen on #parrot 6 days and 14 hours ago, saying: these tasks are typically not completed in short time unfortunately, but it takes time for brains to find patterns. In my experience anyway [Apr 5 04:27:33 2008]
cotto_work msg kj There's a 'lt&' in the second paragraph under "And...Action" in episode 3 of your tutorial 01:58
purl Message for kj stored.
cotto_work msg kj ..er in the third paragraph 01:59
purl Message for kj stored.
02:12 afbach joined 03:03 guru joined 03:31 CAB joined, CAB left 03:32 AndyA joined 04:10 guru left 04:42 mj41 joined 04:59 Psyche^ joined
dalek r26936 | infinoid++ | trunk: 05:14
: [rakudo] fix Capture.pir's POD to pass t/doc/pod.t.
diff: www.parrotvm.org/svn/parrot/revision?rev=26936
13:44 ilbot2 joined
moderator Parrot 0.6.0 "P&P" released | Please mentor for SoC | parrotcode.org/
ambs back 14:06
erm
purl says I have one message wayting
purl ambs: what?
ambs purl: messages 14:07
kid51 you collect them by going into a room with purl (what an exciting prospect!) and saying: messages
ambs hehehe 14:08
thanks
Senaka hi all 14:13
I'm supposed to give a report on the features of Parrot GC
can someone give some hints on starting points etc. 14:14
??
ambs Senaka: I think there are some documents about it on the parrot source, but not sure
Senaka I see 14:15
pdd05 and some within GC source
ambs pdd09 has something about GC, I think
Senaka in addition to that are there anything else?
yes 09 not 05 14:16
:)
ambs lol
ok
do not know, then
Senaka ok thanks 14:17
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? 14:18
Senaka to Harmony, the SoC project I work on
Harmony is an Apache project
ambs kid51: can I install intltool or do you want to use me as a test case? :) 14:19
kid51 ambs: Am just about to post to list on what I've found; suggest hold off till you read that. 14:27
ambs ok
kid51: you James Keenan? 14:29
yup 14:30
kid51 agrees with abms on that
s/abms/ambs/
ambs kid51: can you please check if you have a libintl on your fink installation dir?
(ls /usr/local/lib/libintl* I would say) 14:33
kid51 ambs: Just posted some more data. Fink installs under sw/, not /usr/local. 14:38
ambs kid51: yes, /sw. sorry
using macports for too long
: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. 14:39
ambs yes 14:41
I realled that fink used a different dir
but missed it :D 14:42
kid51 On my Linux, I'm going to install gettext from Debian and see what difference it makes.
14:43 tg joined
ambs at the moment I am installing intltool and check if things change 14:43
14:44 askie joined 14:45 Senaka left
kid51 Installing gettext simply reinstalled the version I already had; made no difference to Configure.pl. Now trying to install intltool. 14:49
ambs kid51: intltool does not include libintl 14:50
it is a library used by some versions of gettext
:-/
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. 14:55
nopaste "ambs" at 77.54.92.255 pasted "Simple patch (not)" (13 lines) at nopaste.snit.ch/12681 14:57
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. 14:58
how do we detect GNU systems? 14:59
that's from www.gnu.org/software/gettext/manual...l#Overview
shorten particle's url is at xrl.us/bjbov
ambs particle: right
that's why my patch works for linux
hehehe
particle i need libintl on windows
ambs try to link the sample code without -lintl 15:00
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?
particle: I mean, do that on the configure step 15:01
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 15:02
ambs and, do we know that?
particle that's what im trying to figure out 15:03
if you use gcc, does that make you a gnu system?
if you have gnu libc, then you don't need libintl
ambs no
particle so, how do we detect whether you have gnu libc? 15:04
ambs if you use cygwin or mac, you have gcc and need libintl
particle and, is that detection done *before* gettext detection?
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 15:05
particle: Determining whether libc has the backtrace* functions (glibc only).....yes. 15:06
nopaste "kid51" at 71.247.58.244 pasted "Applying ambs's patch on both Linux and Darwin" (17 lines) at nopaste.snit.ch/12682
ambs this test might help
particle is auto::backtrace done before auto::gettext?
ambs yes 15:07
particle great, so we can add a flag to backtrace
$conf->data->set( glibc => 1 ); 15:08
if we have glibc, otherwise set to 0
then we can look it up later 15:09
ambs it seems that there is something like 15:10
#ifdef __GLIBC__
that might be handy
particle definitely!
purl definitely! are you here?
ambs purl: no, he isn't 15:11
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 nopaste.snit.ch/12683
particle wishes Parrot::Configure::Step::List allowed each step to take params 15:13
ambs hmms 15:15
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.
So we've lived without them for 7 months. 15:16
particle kid51: it allows cross-compilation scripts to be written
atm we don't have anybody trying to compile to ps3, but we need that someday
(or iphone, or whatever)
it'd sure be nice to have somebody that can test our config system with a cross-compiler 15:17
ambs perl Configure.pl --cc="$CC" --ld="$CC" --link="$CC"
this is kind of b oring :) 15:18
kid51 ambs: That's what I do on Darwin every time I configure. So I have it in a shell script.
ambs :)
looking for a $ENV{CC} might help 15:19
kid51 config/auto/backtrace/test_c.in: There's no 'glibc' string in this file. What makes it glibc-specific? 15:20
ambs if there is a __GLIBC__ define, I would create a new step just for that 15:21
nice.. (1 subtest UNEXPECTEDLY SUCCEEDED)
:D
particle Determining whether you have GNU libc......yes/no
ambs nods 15:22
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)? 15:24
particle the hints are there to tell configure that you know something about your platform before the config process begins in earnest 15:25
basically, it should be 1) defaults 2) hints 3) detect whatever you can
of course there may be other stuff, like manicheck there 15:26
it seems to me that init::install should be after hints 15:27
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. 15:28
particle can solaris's init::hints call auto::gcc? 15:29
kid51 One of its 3 callback functions is concerned with auto::gcc. 15:31
ambs and there goes another complain about the configure script
particle yes. so, inside init::hints, call auto::gcc
configure steps *should* be able to call each other 15:32
15:32 tetragon joined
kid51 That certainly adds to the complexity of the configuration system. 15:32
... and to its testability. 15:33
particle it's a plugin system. plugins should be able to call each other. see qpsmtpd for an example 15:34
(or many others)
kid51 Is that consistent with our 'Parrot::Configure object is a singleton' model?
particle sure 15:35
the parrot configure object contains the data
we only want one instance of that
the path we take to get the data varies depending on the platform 15:36
e.g. plugins may be called in a different order depending on platform
some may not be called at all 15:37
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. 15:39
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 15:40
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
it'll go something like this:
when a plugin starts, it asks "has my purpose been fulfilled already?"
if so, don't run again. if not, run. 15:41
so, it's possible config steps might be called more than once
say solaris' init::hints calls into auto::gcc
auto::gcc fulfills its purpose
init::hints fulfills its purpose 15:42
later, auto::gcc is asked to run again
but it recognizes that it doesn't have to
.
ambs now, is anybody working on auto::glibc? 15:43
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
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. 15:45
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 15:49
ambs needs to go direct a choir, and will be back in two hours 15:50
later, folks
particle we're not looking precisely whether a step has been run already, but that's a good approximation 15:51
good enough for the next few months, for sure 15:52
kid51: is it possible currently to modify the step list at runtime? 15:54
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. 15:55
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. 15:56
particle sure 15:57
it would be nice if our plugins weren't so verbose. there's a lot of repeated code
15:58 Ivatar joined, Theory joined
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. 15:58
particle for example, if we had a step called auto::find_library, and we could call it with params like glibc, libintl etc
15:58 PacoLinux joined
particle i think we'll add file-based, but keep interactive. 15:59
kid51 So I eliminated as much as I could that we weren't actually using .
Hey do you/I/we have enough tuits to maintain 3 different approaches to configuration (command-line options being #1)? 16:00
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. 16:01
particle i can't imagine perl 5's configure without interactive mode 16:02
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 16:03
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. 16:04
particle some folks can't (or don't) do that. 16:05
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. 16:06
particle there are only a few hundred people worldwide using parrot atm.
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. 16:07
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 16:08
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. 16:10
I think our config system is mature enough and upstream enough that changes to it should be posted first. 16:11
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 16:12
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.
Since I knew nothing when I joined the project, I took the list of config steps as given. 16:13
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. 16:14
Which is 'cause I can only get Dan to go out for beers with me 2x/year ;-) 16:15
particle well, i think we basically have everything we need in config for 1.0 now. 16:16
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.
16:17 ruoso joined
particle we haven't targeted writing a design doc for those subsystems, since we only have so much bandwidth 16:18
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.
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? 16:19
particle right
gnu m4 for example
that shouldn't be in parrot's configure
it should be in languages/eclectus's configure 16:20
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.
I also wondered about python. I can't find any use of it in 'make', so I never understood why it was in configure. 16:21
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 16:22
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 16:23
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 16:24
but now we rely on perl 5's config
kid51: can we switch up to the config tests? 16:25
they're too resource-intensive. i think you're checking for the same thing multiple times 16:26
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.
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? 16:27
particle sometime later, yes 16:28
kid51 k
particle enjoy
16:43 Senaka joined
dalek r26942 | jonathan++ | trunk: 16:51
: [rakudo] Refactor the scoped_declarator action somewhat, fixing 'has $.foo' in the process.
diff: www.parrotvm.org/svn/parrot/revision?rev=26942
17:01 japhb joined
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? 17:02
Senaka what could cause parrot/blib/lib/libparrot.so: undefined reference to `data_types' ?? 17:03
Tene japhb: I use it. 17:04
dalek r26943 | fperrad++ | trunk: 17:05
: [uuid]
: - add a minimalist uuid library
: - and tests
diff: www.parrotvm.org/svn/parrot/revision?rev=26943
r26944 | fperrad++ | trunk: 17:09
: [Lua]
: - add uuid library
: - and tests
diff: www.parrotvm.org/svn/parrot/revision?rev=26944
17:10 chromatic joined
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 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? 17:18
Tene japhb: I just used the -r argument to git-svn fetch to avoid fetching all of the history. 17:23
git-svn init url/ ; git-svn fetch -r 26944
oslt
Of course, if you're nto committing directly from git-svn, it won't make much difference. 17:24
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. 17:27
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. 17:28
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. 17:29
17:32 Senaka joined
Senaka chromatic:ping 17:32
: ping
chromatic Howdy.
jonathan Could we generate an array of invokable objects for each vtable entry and instantiaton time?
That is, the array index matches the index we'd use into the VTABLE.
And it tells us what to invoke, right away. 17:33
Senaka chromatic: C++ build can be patched w/o any prob
jonathan When I say instantiation time, I mean the first instantiation of the class.
chromatic Excellent, Senaka.
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 17:34
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.
Invalidation is a little trickier. 17:35
jonathan Well, if we flatten all into vtable_overrides then introspection on that maybe becomes fun. :-)
As you can't tell exactly what was overridden by that specific class.
Senaka chromatic "extern C" is required I guess
will add those to headers
and try 17:36
#ifdef __cplusplus
extern "C"
{
#endif
purl i think extern "C" is already in there
chromatic Ahh, that should do it.
Senaka chromatic: yes
chromatic Do we need that level of introspection? 17:37
In theory, we can look at the sub and tell where we defined it.
Or at least its attached namespace.
japhb Tene: thank you
jonathan That's true. 17:38
We could even work these out lazily rather than all up-front. 17:39
First ask, does the current class' vtable_overrides hash have an entry for this vtable method?
chromatic That was my theory as well.
jonathan If so, invoke it, done.
If not, go and do the search, then when we find it stick what we found into the hash.
chromatic Mostly that's what Parrot_oo_find_vtable_override does.
dalek r26945 | fperrad++ | trunk: 17:41
: [Lua]
: - minor refactor
diff: www.parrotvm.org/svn/parrot/revision?rev=26945
jonathan Lots of auto-generated methods in the Object PMC instead have a similar code-path, doing a similar thing. 17:42
I guess both would want the changes. 17:44
17:44 tetragon joined 18:05 barney joined 18:21 ambs joined
dalek r26946 | particle++ | trunk: 18:22
: [config] add auto::glibc step to detect GNU libc
diff: www.parrotvm.org/svn/parrot/revision?rev=26946
ambs particle++ 18:23
Seeing if GNU libc is installed........................................yes. 18:24
particle ambs++ 18:25
i'm modifying gettext.pm now
ambs Seeing if your configuration includes gettext...........................no.
thanks
particle++ :)
dalek r26947 | bernhard++ | trunk: 18:26
: #50616: [PATCH] add lists to pynie
: Forgot to add 09-list.t
diff: www.parrotvm.org/svn/parrot/revision?rev=26947
ambs Seeing if GNU libc is installed.........................................no. --> darwin 18:27
particle svn up and try again please
ambs doing that
dalek r26948 | particle++ | trunk:
: [config] modifying auto::gettext to work properly with GNU libc
diff: www.parrotvm.org/svn/parrot/revision?rev=26948
particle Seeing if GNU libc is installed.........................................no.
Seeing if your configuration includes gettext..........................yes.
that's msvc 18:28
ambs Seeing if your configuration includes gettext..........................yes.
particle \\o/
ambs both under darwin and linux
ambs hugs particle.
particle feel free to study the diffs, so you can write your own in the future :)
ambs :D
18:33 kid51 joined
particle ok, now that gettext detection is done, i can finally someday move on towards implementing it. 18:35
ambs hehehe 18:37
kid51 Is dalek not working properly? Last revision I see on scrollback is 26944; we're up to 26948. 18:45
ambs kid51: I have here r26948 18:49
dalek: r26948 | particle++ | trunk:
[7:27pm] dalek: : [config] modifying auto::gettext to work properly with GNU libc
particle kid51: you left the room and came back
(11:32:46) kid51 [~jkeen@pool-71-247-58-244.nycmny.east.verizon.net] entered the room.
kid51 Yeah, but I didn't see anything at www.parrotcode.org/misc/parrotsketc...t.20080412 18:50
So maybe it's piper that's the problem. 18:51
moritz irclog.perlgeek.de/parrot/2008-04-12#i_259645
ambs piper is missing, yes 18:52
thanks God!
particle (10:40:51) Piper left the room (quit: Ping timeout: 360 seconds).
ambs \\o/ 18:53
anybody knows what is the local autoconf macro directory for a autoconf/automake package? 18:58
kid51 particle: In config/auto/glibc.pm, you make no use of $verbose. Hence, I'm going to cut it out. 18:59
particle oops, kid51++
19:02 Senaka left 19:03 chromatic_away joined 19:07 teknomunk joined
dalek r26949 | jkeenan++ | trunk: 19:12
: config/auto/glibc.pm: Deleting unused $verbose. Adding 1 test file to test
: if-else branches in _evalutate_glibc().
diff: www.parrotvm.org/svn/parrot/revision?rev=26949
kid51 particle: Could you add a summary of what you did to rt.perl.org/rt3/Ticket/Display.html?id=52788, i.e., why it was necessary to add one config step to solve problem in another? 19:16
19:16 liona29 joined
particle sure 19:17
19:20 guru joined
kid51 guru: What URL for smoke testing were you referring to in email? 19:24
19:25 chromatic joined
ambs particle++ 19:28
kid51 Yes, gettext now being detected for me on both darwin and linux. 19:29
19:33 ambs_ joined
guru kid51 check #tpm 19:51
20:04 ambs joined
guru kid51_afk Go to #tpm? 20:20
20:27 mj41 joined
chromatic Looks like I just fixed RT #52398. 20:31
tetragon Anything for me to test? 20:35
chromatic Making a patch now... 20:36
nopaste "chromatic" at 63.105.17.30 pasted "Fix RT #52398" (60 lines) at nopaste.snit.ch/12685 20:38
chromatic There you go.
Debolaz Yay, git mirror of parrot complete. 20:41
Now for the daunting task of packing a git repository with over 200k objects. 20:45
tetragon chromatic: No crash here 20:49
20:50 guru left
Debolaz git.andersberle.com/?p=parrot.git # But don't try to clone it yet. 20:52
nopaste "particle" at 24.19.3.148 pasted "chromatic: how does these look..." (25 lines) at nopaste.snit.ch/12686 20:53
20:53 chromatic joined
particle (13:52:34) nopaste: "particle" at 24.19.3.148 pasted "chromatic: how does these look..." (25 lines) at nopaste.snit.ch/12686 20:54
chromatic particle, looks reasonable 20:55
particle fab. ta for the sanity check
chromatic Do you know how Coke was setting dependencies? 20:57
particle i know he has a script to detect missing deps
dunno if he ci'd it
and i'm not sure how he was changing the deps, i'd have to check svn log
chromatic looks like config/auto/pmc.pm 20:58
I just don't see how he did it though. 20:59
purl, msg Coke The ParrotInterpreter PMC now depends on pmc_class.h (generated from the Class PMC). How do we add that to the root Makefile? 21:00
purl Message for coke stored.
particle does config/gen/makefiles/root.in offer any clues? 21:01
chromatic Not really.
None that mean anything to me.
particle config: 1; chromatic: 0 21:05
dalek r26950 | chromatic++ | trunk: 21:06
: [PMC] Made Parrot_clone() call clone vtable entry. Now there's a default clone
: vtable entry which calls Parrot_freeze/Parrot_thaw.
: With a little bit of massaging in the ParrotInterpreter PMC, we now clone
: classes correctly between threads, so RT #52398 no longer crashes, and in fact,
: passes.
: There is a little bit of ugliness here in that the interpreter immediately
: clones the source interpreter's class's name and namespace directly, but that's
ambs readline 3 ; ambs 0
dalek : something to address within the Class PMC.
diff: www.parrotvm.org/svn/parrot/revision?rev=26950
particle chromatic: r26855 and 26850 seem related 21:08
chromatic That's just in the past hour. Lifetime, it's config: MAXINT; chromatic: 2.
... now let's see how dalek responds to my missives.
ambs can't understand ldd :-S 21:09
chromatic Yeah, but my approach would be hideous if I did things that way. 21:10
particle chromatic: did you #include pmc_class.h? 21:14
vim config/auto/pmc +117 # this should take care of it, if you did 21:15
chromatic Ah, that might do it. 21:16
Meanwhile, I'm going to reward myself for fixing a threading problem with lunch. 21:20
and I'm not going to touch IMCC this weekend without a very good reason. You can quote me on that!
tetragon And now my Darwin box is down to six usual crashes
particle eats lunch single-threaded
21:21 ambs joined
jonathan continues to put off the work he needs to do on IMCC 21:23
chromatic The PBC stuff? 21:24
moritz jonathan++ # types in Rakudo 21:25
jonathan chromatic: Yeah, especially annotations stuff. 21:27
I'll bring myself to diving into it sometime soonish. 21:28
21:28 guru joined
chromatic That should improve a lot of things. 21:29
jonathan It took me a while to realize why you'd changed the pmc_new to SUPER() in that last patch. :-) 21:30
tetragon Hrm... one of the tests under t/pmc/*.t is unexpectedly passing
chromatic tetragon, jonathan made a change to assign the other day which made it work. 21:33
jonathan I accidentally fixed a test?
tetragon Which test?
jonathan Bonus! 21:34
ambs AHAHAHA
jonathan++
mj41 tt.perl6.cz/?ac=ttest&trun_id1=...esult_id=4
tt.perl6.cz/
tetragon That log matches what I'm seeing 21:35
purl somebody said seeing was believing
21:39 paco joined
ambs purl: somebody? 21:41
purl i guess somebody is supposed to be working on a dbix::class tutorial >:
ambs hope so 21:42
21:53 IllvilJa joined
ambs and, a good night 21:55
purl sleep well too
ambs purl: thanks
21:59 kid51 joined 22:11 kid51 joined
kid51 arises from sickbed 22:14
22:32 anna30 joined
kid51 Latest coverage stats for configure and build tools: thenceforward.net/parrot/coverage/c...erage.html 22:51
shorten kid51's url is at xrl.us/bjbts
dalek r26951 | particle++ | trunk: 22:56
: [gettext] define some macros to (eventually) use with gettext
diff: www.parrotvm.org/svn/parrot/revision?rev=26951
23:11 Limbic_Region joined 23:22 Theory joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!