[perl #35824] [TODO] Remove .cvsignore files
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #35824] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35824 This was posted on the perl6-internals list by Jrgen Bmmels: In the current SVN repository are 76 .cvsignore files. In SVN they aren't used any more. SVN uses the property 'svn:ignore' on a directory instead. During the cvs = svn transition the svn:ignore properties were set but in the recent weeks they started to diverge. Currently (r8078) 22 .cvsignore differ from svn:ignore (see attached cvsignore.diff) I think we should remove .cvsignore files entirly. I noticed that .cvsignore is still used in tool/dev/manicheck.pl and Autrius Tang suggested to use 'svn propget svn:ignore' or 'svk propget svn:ignore'. So that's the plan: i. Migrate the changes in .cvsignore file into the svn:ignore property ii. Tell manicheck.pl to query the SVN properties iii. remove the .cvsignore files
Re: Python on parrot
Re: Pyrate( Sam's stub code ) I've taken the code from http://www.intertwingly.net/stories/2004/10/05/pyrate.zip, which I assume to be Sam's code. It was basically stubs with a few AST nodes implemented when I started with it. And am working to generate a python to pir translator/compiler that uses Sam's python pmc's I've attached the source as it stands now. I'm just an aspiring parrot hacker. I'm sure that there are a lot of things I'm doing wrong or inefficiently. I'm looking for feedback and suggestions for improvement. Please comment. I want to get my patches on top of Sam's initial work imported into the parrot SVN tree. I believe that having the python compiler code in parrots svn tree is imperative to build a python/parrot community. A python compiler in the parrot tree will lead to more widespread exposure to other parrot developers, increased peer review, testing by more people on a greater variety of platforms, etc. Michal could you expound on your thoughts here, they sound interesting. I'm not sure what Kevin meant by self hosted but I've been thinking about this lately, and what we can do today is creating a back-end for the compiler that emits simplified python code in a way that would give us things like continuations (though with some loss of speed) without the need to duplicate the python library. I meant a python to pir translator/compiler written in python. I've looked at the PyPy project. They are doing cool stuff. I would eventually like to use their work to emit optimized pir for python, but they still have work to do. Kevin Sam Ruby wrote: Michal wrote: On Sat, 16 Apr 2005, Sam Ruby wrote: [I hope you don't mind me putting this back on the list - I would prefer that everybody who is interested can follow along and/or participate] Kevin Tew wrote: Sam Ruby wrote: Hey guys, I didn't see this until just now. Kevin Tew wrote: Sam, Just wondering what the status is on python/parrot/pirate/pyrate. These both look outdated. http://www.intertwingly.net/stories/2004/10/05/pyrate.zip http://pirate.versionhost.com/viewcvs.cgi/pirate/ I haven't looked at it for a few months now. I do plan to revisit it enough to get the Pie-thon tests completed by the time of OSCON (in August). Sam, are you still interested in this? I had better be: http://conferences.oreillynet.com/cs/os2005/view/e_sess/6833 Is there a up to date cvs repo? http://pirate.tangentcode.com/ Can we get this code checked into the parrot svn repo? Unfortunately, no. Much of this code is copyright Michal Wallace. The good news is that the good stuff is in the parrot repo already. What is left - a simple translator - can and should, IMHO, be recoded into Perl6 once enough of that is running. - Sam Ruby So why won't Michal Wallace sign over the copyright? I talked to Michal briefly about this a while back. My impression was that he wanted to sign over the copyright to the Python foundation. Which makes a bit of sense - Pirate is based on code created by Andrew Kuchling and the copyright on that work already belongs to the Python foundation. Mostly I think pirate is just a different project from parrot and I don't want to hand over control of which patches to apply, etc. So far, I've never rejected a patch or turned down anyone for cvs access, but I'd like to reserve the right. (Also, Dan and the parrot team had other ideas about how to implement python.) the goal of having everything run on a single runtime does not necessarily imply that everything has to be owned by a single organization and put into a single repository. Yes. That was the other main idea. I was hoping that we could leverage the objects that the python team had already created. Do PMC's still have to be compiled inside the parrot source tree? To me, the problem is that the PMC's are in the parrot tree, not that the compiler isn't in there with it. Parrot (including the build system) is a moving target. Long term, the answer is no. Short term, the answer is yes. My own opinions is that Michal thinks too much. ;-) This is almost certainly true. :) My impression is that everybody here is reasonable, and if it made sense for further development to be transferred to another organization, then some reasonable arrangement would be made. I hope this is true, too. :) Also, I believe that much of the initial work is throwaway work anyway. Build one to throw away, and all that. I've never really bought that logic. :) It works, and (especially after your last batch of refactorings) the code is pretty clean. I would like to see the emitter code separated out into a builder object though. Cool I did notice all the python pmcs. By translator I assume you mean a interpreter/compiler to parrot byte code. At the moment, it is to Python to IMC, but eventually going directly to bytecode would be a good idea. That's fine with me, as long as parrots imc compiler does the work. :) Why would you do it in Perl6, why
Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32
parrot (r8016): no change. hangs w/98% cpu. here's the -t output:
parrot -t test_b.pasm
0 find_global P5, _foo - P5=SArray=PMC(0x7d5a50),
3 new P2, 18 - P2=PMCNULL,
6 find_method P0, P2, thread3- P0=PMCNULL,
P2=ParrotThread=PMC(0x7d5a08),
10 new P6, 54 - P6=PMCNULL,
13 set I3, 2- I3=1,
16 invoke
17 set I5, P2 - I5=0, P2=ParrotThread=PMC(0x7d5a08)
20 getinterp P2 - P2=ParrotThread=PMC(0x7d5a08)
22 find_method P0, P2, detach - P0=NCI=PMC(0x638620), P2=ParrotInterpr
eter=PMC(0x637dc8),
26 invoke
27 defined I0, P6 - I0=1, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
27 defined I0, P6 - I0=0, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
27 defined I0, P6 - I0=0, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
27 defined I0, P6 - I0=0, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
27 defined I0, P6 - I0=0, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
27 defined I0, P6 - I0=0, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
etc
On 5/15/05, Vladimir Lipsky [EMAIL PROTECTED] wrote:
the 'detatch' threads test hangs on win32. this small patch skips one
Could you try the following code('the detatch' threads test with one tweak)
and tell me if it hangs either and what output you get?
find_global P5, _foo
new P2, .ParrotThread
find_method P0, P2, thread3
new P6, .TQueue # need a flag that thread is done
set I3, 2
invoke # start the thread
set I5, P2
getinterp P2
find_method P0, P2, detach
invoke
wait:
defined I0, P6
unless I0, wait
print done\n
sleep 5 # Maybe a race condition?
end
.pcc_sub _foo:
print thread\n
new P2, .Integer
push P6, P2 # push item on queue
returncc
Re: Python on parrot
On Sun, 15 May 2005, Kevin Tew wrote: I've taken the code from http://www.intertwingly.net/stories/2004/10/05/pyrate.zip, which I assume to be Sam's code. It was basically stubs with a few AST nodes implemented when I started with it. Er. Yes. I can't speak for Sam, but I interpreted his post as a spike of how a pirate refactoring could go, not a call to start a whole new incompatible project. And am working to generate a python to pir translator/compiler that uses Sam's python pmc's I've attached the source as it stands now. I'm just an aspiring parrot hacker. I'm sure that there are a lot of things I'm doing wrong or inefficiently. I'm looking for feedback and suggestions for improvement. Please comment. Well, one thing that's innefficient is to write your own compiler when there are already two mostly working examples out there. I want to get my patches on top of Sam's initial work imported into the parrot SVN tree. I believe that having the python compiler code in parrots svn tree is imperative to build a python/parrot community. I'm absolutely bewildered that you would take that route in order to build a community. Between pie-thon and pirate there already are two python compilers, and pie-thon already *is* in the parrot tree... As far as I can tell, you didn't approach either existing group and see if you could help. You just went off and did your own thing. You're not building a community, you're creating yet another faction. A python compiler in the parrot tree will lead to more widespread exposure to other parrot developers, increased peer review, testing by more people on a greater variety of platforms, etc. This is a great goal, but I'm not sure it follows that having it in the source tree would lead to more exposure. To me, if you want exposure, a much better idea would be to *talk* to people, either on mailing lists or blogs or whatever. In other words, market the project. You need things like documentation and a website. Where the code lives is a fairly trivial concern. It sounds like you just want parrot developers to stumble on to your code in the tree and pitch in. In my mind, the target audience for pirate is python developers (like yourself). People who might have heard about parrot, but don't necessarily know much about it or how it works. But if you can tell all the nice things we get: - this buys us continuations without the genius-level hacks required by stackless - we'll be able to leverage CPAN and code written in other languages... - we'll have a native call interface - (etc) ... then maybe python hackers will be interested. So they should be able to download a python file and run it. The python file should work like every other python file, and leverage the distutils. It should have a setup.py install script and if necessary, a windows installer and rpms. There should be a link to download a binary version of parrot so that the first step isn't to compile a virtual machine they know nothing about - especially if they're developing on windows without a compiler. To me, having the code burried in the middle of the parrot tree is a huge barrier to entry to new developers. Of course if you're targeting parrot developers who may or may not know python, that's another story... But from what I can tell, the other compilers in the parrot svn tree just aren't getting the kind of exposure you're talking about. I don't know, maybe I'm just rambling, but I don't see how putting the source in the parrot repository is either necessary or sufficient for widespread exposure. :/ Michal could you expound on your thoughts here, they sound interesting. I'm not sure what Kevin meant by self hosted but I've been thinking about this lately, and what we can do today is creating a back-end for the compiler that emits simplified python code in a way that would give us things like continuations (though with some loss of speed) without the need to duplicate the python library. Sure. This is kind of off topic for the parrot list. I posted a blog entry here: http://sabren.com/index.php?p=62 I meant a python to pir translator/compiler written in python. Like this one: http://pirate.tangentcode.com/ ?? I've looked at the PyPy project. They are doing cool stuff. I would eventually like to use their work to emit optimized pir for python, but they still have work to do. So why don't you want to help them with that work? Right now you're just reinventing the wheel. If you were writing a backend for pypy, that would be one thing. That would actually be useful. Better yet, not write up a little report about what it would take to get pirate to work with pypy? We could almost certainly leverage their type inference engine. I'd love to see pirate become just another backend for pypy. It seems to me that would do a lot more to build community than the approach you're taking. - Michal http://withoutane.com/
[perl #35836] [PATCH] Dynclasses make pathquote
# New Ticket Created by Ron Blaschke # Please include the string: [perl #35836] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35836 Attached patch quotes some paths. Otherwise Parrot won't built if living below a directory containing spaces (eg C:/Documents and Settings). Ron dynclasses_make_pathquote.patch Description: Binary data
[PATCH] more ws.t tests, fixed
I left something uncommented in my prior patch, causing failure. Fixed.
This is additional tests for :w using (), [], \b and :: for separation.
-Dino
--
.~.Dino Morelli
/V\email: [EMAIL PROTECTED]
/( )\ weblog: http://categorically.net/d/blog/
^^-^^ preferred distro: Debian GNU/Linux http://www.debian.orgIndex: t/p6rules/ws.t
===
--- t/p6rules/ws.t (revision 8109)
+++ t/p6rules/ws.t (working copy)
@@ -1,6 +1,6 @@
use strict;
use warnings;
-use Parrot::Test tests = 15;
+use Parrot::Test tests = 17;
use Parrot::Test::PGE;
@@ -23,6 +23,15 @@
p6rule_is ('foo-bar', ':w foo -? bar', 'basic ws match \s* \s*');
p6rule_isnt('foobar', ':w foo -? bar', 'basic ws non-match');
+# with :w not separated by a space
+# XXX: These forms of modifier separation do not yet work
+#p6rule_is ('foo - bar', ':w()foo -? bar', 'basic ws match');
+#p6rule_is ('foo - bar', ':w[]foo -? bar', 'basic ws match');
+p6rule_is ('foo - bar', ':w\bfoo -? bar',
+'basic ws match with boundary modifier separation');
+p6rule_is ('foo - bar', ':w::foo -? bar',
+'basic ws match with backtrack no-op modifier separation');
+
# XXX: When available, add tests for full form :words modifier
-# dont forget to change the number of tests :-)
+# Don't forget to change the number of tests :-)
