PDD20, Tcl
With patches from myself (to tcl) and leo (to parrot), partcl is once again passing 100% of the tests, using PDD20. The biggest hurdle was having some arbitrary (non :lex-ified) parrot sub issue our find_lex and store_lex for us to ease transition. As more of tcl becomes compiled, we can probably eliminate this code path entirely, but that's a ways off. Regards. .sub find_lex_pdd20 .param string variable_name .local pmc interp, lexpad, variable .local int depth interp = getinterp depth = 2 # we know it's not us or our direct caller. get_lexpad: # Is there a lexpad at this depth? lexpad = interp["lexpad";depth] unless_null lexpad, got_lexpad # try again inc depth goto get_lexpad got_lexpad: variable = lexpad[variable_name] .return(variable) .end
Re: PDD20, Tcl
On Mon, Nov 28, 2005 at 01:16:49PM -0500, Will Coleda wrote: > With patches from myself (to tcl) and leo (to parrot), partcl is once > again passing 100% of the tests, using PDD20. Yay! > The biggest hurdle was having some arbitrary (non :lex-ified) parrot > sub issue our find_lex and store_lex for us to ease transition. As > more of tcl becomes compiled, we can probably eliminate this code > path entirely, but that's a ways off. Yow. The below code looks a bunch like what the find_lex opcode is supposed to do. What made it necessary? > .sub find_lex_pdd20 > .param string variable_name > > .local pmc interp, lexpad, variable > .local int depth > interp = getinterp > depth = 2 # we know it's not us or our direct caller. > > get_lexpad: > # Is there a lexpad at this depth? > lexpad = interp["lexpad";depth] > unless_null lexpad, got_lexpad > > # try again > inc depth > goto get_lexpad > got_lexpad: > variable = lexpad[variable_name] > .return(variable) > .end > > -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: PDD20, Tcl
On Nov 28, 2005, at 2:46 PM, Chip Salzenberg wrote: On Mon, Nov 28, 2005 at 01:16:49PM -0500, Will Coleda wrote: With patches from myself (to tcl) and leo (to parrot), partcl is once again passing 100% of the tests, using PDD20. Yay! The biggest hurdle was having some arbitrary (non :lex-ified) parrot sub issue our find_lex and store_lex for us to ease transition. As more of tcl becomes compiled, we can probably eliminate this code path entirely, but that's a ways off. Yow. The below code looks a bunch like what the find_lex opcode is supposed to do. What made it necessary? Tcl variables can be either globals or lexicals (inside a [proc]). So, all the code to get a PMC from a varname was factored out to a single routine that returns the right PMC (global or lexical) depending on call level. So, our "find_lex" was no where near where we'd tack on a :lex to the sub. pre-pdd20, this worked because there was a global stack of lexpads. I could just say "new_pad" at the appropriate spot, and any find_lex from that point out would find the right lex, regardless of whether or not it was in the same parrot sub. However, with the current implementation (and design, as I understand it), you can only use "find_lex" *in* the sub that has the :lex definition. Since this was in a helper sub that had no :lex, the find_lex failed to find anything. As the compiler gets smarter, we can probably avoid most uses of this .sub. But for now, this made the transition far less painful than doing a major rewrite. .sub find_lex_pdd20 .param string variable_name .local pmc interp, lexpad, variable .local int depth interp = getinterp depth = 2 # we know it's not us or our direct caller. get_lexpad: # Is there a lexpad at this depth? lexpad = interp["lexpad";depth] unless_null lexpad, got_lexpad # try again inc depth goto get_lexpad got_lexpad: variable = lexpad[variable_name] .return(variable) .end -- Chip Salzenberg <[EMAIL PROTECTED]>
testing Javascript applications ?
It used to be that WWW::Mechanize was a "good enough" testing tool for my web applications. It doesn't do Javascript, but I used very minimal Javascript and thus worked around that limitation. Along comes AJAX. It offers benefits that make JavaScript seem worth using. But now how I can test the application? I have a link that uses AJAX to pull in some content that gets displayed in a new layer, including a form I'd like to submit. Mozilla::Mechanize seems like a potential answer here, but so far I haven't run across people who are actually using it to test sites with Javascript. (It has enough dependencies that I'm putting off installing it myself just yet. :) What are other folks doing to test web applications that make heavy use of JavaScript? Mark
Re: testing Javascript applications ?
On Mon, Nov 28, 2005 at 08:25:48PM +, Mark Stosberg wrote: > It used to be that WWW::Mechanize was a "good enough" testing tool for > my web applications. > > It doesn't do Javascript, but I used very minimal > Javascript and thus worked around that limitation. > > Along comes AJAX. It offers benefits that make JavaScript seem worth > using. > > But now how I can test the application? I have a link that uses AJAX to > pull in some content that gets displayed in a new layer, including a > form I'd like to submit. > > Mozilla::Mechanize seems like a potential answer here, but so far I > haven't run across people who are actually using it to test sites with > Javascript. (It has enough dependencies that I'm putting off installing > it myself just yet. :) > > What are other folks doing to test web applications that make heavy use > of JavaScript? > > Mark Oh, my juggling friend, you've asked this question at the exact right time. Over here at Sophos, we've recently started using Selenium, a browser based web testing tool. It's all written in Javascript, so it runs entirely in the browser, which means that all of the javascript in your application is run just like what the user sees. And (you're super lucky), I've JUST created a screencast that shows just how easy it is to get started with selenium: http://www.yi.org/~luke/selenium-intro.mov I was interviewed by qapodcast.com about Selenium recently: http://tinyurl.com/9k242 Our web manager uses lots of ajax and javascript, and we're able to use selenium to test on all our supported browsers (IE, FF, Safari). The selenium website is here: http://selenium.thoughtworks.com HTH, Luke -- Luke Closs PureMessage Developer There is always time to juggle in the Sophos Zone.
Re: testing Javascript applications ?
--- Mark Stosberg <[EMAIL PROTECTED]> wrote: > What are other folks doing to test web applications that make heavy > use > of JavaScript? If you want to leverage your Perl testing knowledge, you can check out Test.Simple from JSAN: http://openjsan.org/doc/t/th/theory/Test/Simple/0.21/index.html I've been using it and once you get it set up, it's fairly straight forward. You can see a sample in my journal: http://use.perl.org/~Ovid/journal/27229 Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: testing Javascript applications ?
On Mon, Nov 28, 2005 at 20:25:48 +, Mark Stosberg wrote: > But now how I can test the application? I have a link that uses AJAX to > pull in some content that gets displayed in a new layer, including a > form I'd like to submit. http://www.qapodcast.com/news/2005/11/02/qa-podcast-7-talking-selenium-with-luke-closs That and unit tests for your ajax handlers should do it. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me kicks %s on the nose: neeyah! pgpwsZLSuUi4B.pgp Description: PGP signature
Re: PDD20, Tcl
On Mon, Nov 28, 2005 at 03:22:10PM -0500, Will Coleda wrote: > Tcl variables can be either globals or lexicals (inside a [proc]). > So, all the code to get a PMC from a varname was factored out to a > single routine that returns the right PMC (global or lexical) > depending on call level. I think I understand: You're creating a subroutine to manipulate a pad, and the subroutine is a common utility which can't specify :outer for all its callers, and find_lex only follows :outer. So you have to use interpreter introspection to find the pad. > > >>.sub find_lex_pdd20 > >> .param string variable_name > >> > >> .local pmc interp, lexpad, variable > >> .local int depth > >> interp = getinterp > >> depth = 2 # we know it's not us or our direct caller. > >> > >>get_lexpad: > >> # Is there a lexpad at this depth? > >> lexpad = interp["lexpad";depth] > >> unless_null lexpad, got_lexpad > >> > >> # try again > >> inc depth > >> goto get_lexpad > >>got_lexpad: > >> variable = lexpad[variable_name] > >> .return(variable) > >>.end > So: This subroutine's loop is technically unnecessary, but convenient: The depth of your utility subroutine from the user-written subroutine with :lex is knowable at compile time, so you could rewrite the function to take a depth parameter and just grab the right LexPad on the first try. But you find it more convenient to loop up the call stack rather than have to calculate the depth everywhere. (Right?) Also: If it weren't for the fact you want to search lexicals and globals every time, you could just use find_lex. Therefore: Something along the lines of find_var could help you. PS: I'd forgotten the lex opcodes used to follow the *call stack*. My unholy $DEITY, they were even more broken than I remembered. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Test::More and Tests in PIR
On Nov 26, 2005, at 22:16, chromatic wrote: Hi all, Here's a first shot at Test::More in pure PIR. It only supports plan(), ok(), and is() (for integers, floats, strings, and PMCs) right now. If everyone's reasonably happy, I'll check it in. chromatic please make that sentence: 'If no one's unhappy, ...' looks good to me ... thanks, leo
Re: testing Javascript applications ?
On 2005-11-28, Ovid <[EMAIL PROTECTED]> wrote: > --- Mark Stosberg <[EMAIL PROTECTED]> wrote: > >> What are other folks doing to test web applications that make heavy >> use >> of JavaScript? > > If you want to leverage your Perl testing knowledge, you can check out > Test.Simple from JSAN: > > http://openjsan.org/doc/t/th/theory/Test/Simple/0.21/index.html > > I've been using it and once you get it set up, it's fairly straight > forward. You can see a sample in my journal: > http://use.perl.org/~Ovid/journal/27229 Interesting. And is there a way to run these as part of "./Build test" for a project, that may also run Perl tests as well? Mark
Re: automated web testing with selenium
On 2005-11-02, Luke Closs <[EMAIL PROTECTED]> wrote: > > Also, yesterday Test::WWW::Selenium was uploaded to CPAN, so Selenium > can now be driven by perl! Test::WWW::Selenium seems interesting, but I could use an example it would be useful to use, versus the standard techniques. From the docs, it's not clear if there are restrictions about where the related Perl testing code must reside. Does it need to be on the same server as Selenium and the application? > Anyways, check out the podcast at http://qapodcast.com I'm downloading it now, but I think I better wait until the house clears out before I pipe it through the speaker system and expose my geek side. Mark
Re: automated web testing with selenium
On Mon, Nov 28, 2005 at 10:34:42PM +, Mark Stosberg wrote: > On 2005-11-02, Luke Closs <[EMAIL PROTECTED]> wrote: > > > > Also, yesterday Test::WWW::Selenium was uploaded to CPAN, so Selenium > > can now be driven by perl! > > Test::WWW::Selenium seems interesting, but I could use an example it > would be useful to use, versus the standard techniques. > > From the docs, it's not clear if there are restrictions about where > the related Perl testing code must reside. Does it need to be on the > same server as Selenium and the application? I believe it either needs to be on the same server, or else the perl code should be on a server that provides a reverse proxy to the application under test. I've not actually used the driven mode of selenium - I just use the table driven approach. We have lots of selenium test scripts to test our applications, but we only use the table mode. It's much easier to get started than using selenium in driven mode. > > Anyways, check out the podcast at http://qapodcast.com > > I'm downloading it now, but I think I better wait until the house clears > out before I pipe it through the speaker system and expose my geek side. Sounds good. Note that I don't talk very much about selenium in driven mode in the podcast or the screencast. Luke -- Luke Closs PureMessage Developer There is always time to juggle in the Sophos Zone.
Re: testing Javascript applications ?
--- Mark Stosberg <[EMAIL PROTECTED]> wrote: > > http://openjsan.org/doc/t/th/theory/Test/Simple/0.21/index.html > > > > I've been using it and once you get it set up, it's fairly straight > > forward. You can see a sample in my journal: > > http://use.perl.org/~Ovid/journal/27229 > > Interesting. > > And is there a way to run these as part of "./Build test" for a > project, > that may also run Perl tests as well? Short of compiling Spidermonkey, not that I know of. However, there might be a different approach available: http://use.perl.org/~Ovid/journal/26650 Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
upcoming changes
The whole scratchpad is doomed and will be scratched RSN (see pdd20 instead). A patch with immanent changes is at http://perlcabal.org/~lt/pad.diff but the patch doesn't properly reflect deleted files - if you like to experiment, please svn rm the deleted files: D src/lexical.c D include/parrot/lexical.h D classes/scratchpad.pmc Two items inside parrot source like lexical MMDs are TODOed but untested and shouldn't harm now. Two parrot tests are failing with it, I'll explore more tomorrow. Failed TestStat Wstat Total Fail Failed List of Failed --- t/pmc/sub.t 1 256411 2.44% 11 t/src/extend.t1 256131 7.69% 13 (1 subtest UNEXPECTEDLY SUCCEEDED), 8 tests and 363 subtests skipped. Failed 2/179 test scripts, 98.88% okay. 2/4008 subtests failed, 99.95% okay. Diffstat of patch is nice - less code is good ;-) $ diffstat -w 70 pad.diff MANIFEST |3 classes/closure.pmc | 21 -- classes/coroutine.pmc| 10 classes/pmc.num |2 classes/scratchpad.pmc | 215 config/gen/makefiles/root.in |3 include/parrot/interpreter.h |1 include/parrot/lexical.h | 45 include/parrot/parrot.h |1 include/parrot/sub.h |5 ops/ops.num | 52 ++-- ops/var.ops | 207 ++- src/global.c |3 src/inter_create.c |4 src/inter_misc.c |2 src/lexical.c| 346 - src/mmd.c| 15 - src/sub.c| 73 ++ t/op/lexicals.t |2 t/pmc/sub.t |5 t/src/extend.t |1 21 files changed, 93 insertions, 923 deletions leo
Re: PDD20, Tcl
On Nov 28, 2005, at 22:37, Chip Salzenberg wrote: PS: I'd forgotten the lex opcodes used to follow the *call stack*. My unholy $DEITY, they were even more broken than I remembered. Yes. And have supported hacks that were far beyond anything dubbed as damian-ish (pdd20). Re: tcl - it's just a matter of transition from an interpreter to a compiler and emitting proper code. leo
parrot directory reorganization
the parrot directory structure is large and a bit disorganized. let me give you some examples: * build_tools/, util/, and tools/*/ each contain utility perl scripts. these should be grouped together under tools/, which already contains subdirectories * there are multiple dirs containing C source code (charset, classes, io, etc.) these should be grouped together under src/ * the editor/ directory contains files for text editors and has a generated makefile. there is no reason for this to be a make target. a perl script should be created to replace makefile, and the dir moved with the other tool & utility scripts. * imcc test files are not grouped with other tests (this is already on my TODO list and should be done RSN.) i propose reorganizing the tree to improve clarity and cohesion. here is an annotated picture of the current tree (extra info ped as shown.) . trunk +---ast +---blib | +---lib +---build_tools # move to tools/build/ +---charset # move to src/charset/ +---classes # move to src/classes/ +---compilers | +---pge | | +---PGE | +---tge | +---TGE +---config +---debian +---docs +---dynclasses# move to src/dynclasses/ +---dynoplibs # move to src/dynoplibs/ +---editor# move to tools/editor/, get rid of Makefile, convert it to perl +---encodings # move to src/encodings/ +---examples +---imcc | +---docs | +---examples | +---t # move to t/compilers/imcc/ +---include | +---parrot | +---oplib +---io# move to src/io/ +---jit # move to src/jit/ +---languages +---LICENSES +---ops # move to src/ops/ +---pf# move to src/packfile/ +---runtime +---src +---t | +---compilers | | +---pge | | | +---p5regexp | | | +---p6rules | | +---tge | +---doc | +---dynclass | +---examples | +---library | +---native_pbc | +---op | +---perl | +---pmc | +---run | +---src | +---stress | +---tools +---tools | +---dev | +---docs +---types # move to src/types/ +---util # move to tools/util/ below is the modified tree, which groups related directories, and reduces the number of top-level directories from 28 to 15. . trunk +---ast +---blib | +---lib +---compilers | +---pge | | +---PGE | +---tge | +---TGE +---config | +---debian +---docs +---examples | +---imcc | +---docs | +---examples +---include | +---parrot | +---oplib +---languages | +---LICENSES +---runtime | +---src | +---charset # moved from charset/ | +---classes # moved from classes/ | +---dynclasses# moved from dynclasses/ | +---dynoplibs # moved from dynoplibs/ | +---encodings # moved from encodings/ | +---io# moved from io/ | +---jit # moved from jit/ | | | +---ops # moved from ops/ | +---pf# moved from pf/ | +---types # moved from types/ +---t | +---compilers | | +---imcc # moved from imcc/t/ | | | | | +---pge | | | +---p5regexp | | | +---p6rules | | +---tge | +---doc | +---dynclass | +---examples | +---library | +---native_pbc | +---op | +---perl | +---pmc | +---run | +---src | +---stress | +---tools +---tools | +---build_tools # moved from build/ | +---dev | +---docs | +---editor# moved from editor/, no Makefile, converted to perl | +---util # moved from util/ this work can and should be done one piece at a time to prevent widespread panic. if this proposal is accepted, i will create todo tasks for each unit of work. then, they can be assigned one at a time, until the task is complete. of course, a realclean / configure / make test cycle should be done after each change to ensure it has gone smoothly. thoughts? ~jerry
Re: parrot directory reorganization
Hi Jerry, I'm just curious, I don't mean to criticize your ideas. Just, give some "why"s for the "should"s. On 11/29/05, jerry gay <[EMAIL PROTECTED]> wrote: > the parrot directory structure is large and a bit disorganized. > let me give you some examples: > * build_tools/, util/, and tools/*/ each contain utility perl > scripts. these should be grouped together under tools/, which > already contains subdirectories Why must all perl scripts be grouped under one directory? > * there are multiple dirs containing C source code (charset, > classes, io, etc.) these should be grouped together under src/ Why must all C files be grouped under one directory? > * the editor/ directory contains files for text editors and has > a generated makefile. there is no reason for this to be a make > target. a perl script should be created to replace makefile, > and the dir moved with the other tool & utility scripts. Why can't we use make for this? Make handles modification times and rebuilds on demand based on dependencies. imc.vim (and a few others IIRC) are built from dependencies, and if the dependencies haven't been changed, they don't need to be rebuilt. That sounds like make's job to me. Luke
Re: parrot directory reorganization
On 11/28/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Hi Jerry,
>
> I'm just curious, I don't mean to criticize your ideas. Just, give
> some "why"s for the "should"s.
>
no worries--this isn't criticism, it's feedback.
> On 11/29/05, jerry gay <[EMAIL PROTECTED]> wrote:
> > the parrot directory structure is large and a bit disorganized.
> > let me give you some examples:
> > * build_tools/, util/, and tools/*/ each contain utility perl
> > scripts. these should be grouped together under tools/, which
> > already contains subdirectories
>
> Why must all perl scripts be grouped under one directory?
>
perhaps my language was too imprecise here. let me try to clarify.
there are multiple directories off the root that contain tools and
utilities (most, if not all of which, are written in perl.) some are
used during development, some during build, and some during test.
grouping these tools and utilities together will give parrot
developers (and users) greater ability to infer the purpose of the
files based on their directory locations.
it requires too much knowledge of parrot in order to know that
development tools belong under tools/dev/, testing tools like the
smoke server belong under utils/, and build tools can be found under
build_tools/. i believe moving these directories under one parent
(tools) would flatten the learning curve.
> > * there are multiple dirs containing C source code (charset,
> > classes, io, etc.) these should be grouped together under src/
>
> Why must all C files be grouped under one directory?
>
again, perhaps i was imprecise--it's not a breakdown by language type
i'm looking for. in fact, the files in ops/, dynclasses/ and classes/
aren't even C files -- C files are generated from them. but, they are
logically source files. keeping all source files under one parent
would increase clarity and flatten the learning curve by keeping like
things together.
> > * the editor/ directory contains files for text editors and has
> > a generated makefile. there is no reason for this to be a make
> > target. a perl script should be created to replace makefile,
> > and the dir moved with the other tool & utility scripts.
>
> Why can't we use make for this? Make handles modification times and
> rebuilds on demand based on dependencies. imc.vim (and a few others
> IIRC) are built from dependencies, and if the dependencies haven't
> been changed, they don't need to be rebuilt. That sounds like make's
> job to me.
>
perhaps you are right here. there is a makefile target ('tags') which
calls the editor makefile. i don't have or use ctags, so i forgot
there was even a target for making tags. the tags target is not run as
part of the default make target, so only if a developer calls 'make
tags' will the editor makefile run. the editor syntax files are
regenerated if any ops files change, so there is indeed a dependency
there.
however, the syntax files are not installed, even if 'make tags' is
run. you must 'cd editor && make vim-install' (or 'kate-install') if
you want to actually update your editor. so, really, i don't see the
purpose of having this as a make step, since it doesn't finish the job
(and shouldn't! make shouldn't just install things whereever it wants
to on your system without you telling it to, like typing 'make
install'.)
anyway, i'll leave decisions on removing the makefile from editor/ up
to chip and leo, but my feelings are that it doesn't belong as part of
the make cycle, and is better off as a seperate utility, like
regenerating the MANIFEST.SKIP file (also a seperate utility.)
thanks for the feedback. hopefully i have better conveyed the reasons
behind my proposal.
~jerry
Re: parrot directory reorganization
On Mon, Nov 28, 2005 at 04:45:33PM -0800, jerry gay wrote: > i propose reorganizing the tree to improve clarity and cohesion. Reorganization would be good at this point, but should be undertaken cautiously so as to minimize unpleasantness. * I can't find a rationale for putting both 'imcc' and 'compilers' at the top level. (Though I see a note that you intended imcc to be under compilers; if so, I think that's good.) * Should pasm be considered a compiler for source organization purposes? I suppose in theory it should: There's more than one assembler syntax for most CPUs. And AFAICT, the actual pasm implementation is intermixed with the PIR implementation, so if imcc goes into compilers, it'll take pasm with it. * The directory name 'src' is a bit fuzzy to me, if 'imcc' and 'compilers' aren't part of it. Perhaps 'vm' for the core machine...? That would include infrastructure PMCs. Lots more interesting ideas, I hope. (Jerry's diagrams follow.) > here is an annotated picture of the current tree (extra info > ped as shown.) > > . trunk > +---ast > +---blib > | +---lib > +---build_tools # move to tools/build/ > +---charset # move to src/charset/ > +---classes # move to src/classes/ > +---compilers > | +---pge > | | +---PGE > | +---tge > | +---TGE > +---config > > +---debian > +---docs > > +---dynclasses# move to src/dynclasses/ > +---dynoplibs # move to src/dynoplibs/ > +---editor# move to tools/editor/, get rid of > Makefile, convert it to perl > +---encodings # move to src/encodings/ > +---examples > > +---imcc > | +---docs > | +---examples > | +---t # move to t/compilers/imcc/ > > +---include > | +---parrot > | +---oplib > +---io# move to src/io/ > +---jit # move to src/jit/ > > +---languages > > +---LICENSES > +---ops # move to src/ops/ > +---pf# move to src/packfile/ > +---runtime > > +---src > +---t > | +---compilers > | | +---pge > | | | +---p5regexp > | | | +---p6rules > | | +---tge > | +---doc > | +---dynclass > | +---examples > | +---library > | +---native_pbc > | +---op > | +---perl > | +---pmc > | +---run > | +---src > | +---stress > | +---tools > +---tools > | +---dev > | +---docs > +---types # move to src/types/ > +---util # move to tools/util/ > > > below is the modified tree, which groups related directories, > and reduces the number of top-level directories from 28 to 15. > > > . trunk > +---ast > +---blib > | +---lib > +---compilers > | +---pge > | | +---PGE > | +---tge > | +---TGE > +---config > | > +---debian > +---docs > > +---examples > | > +---imcc > | +---docs > | +---examples > +---include > | +---parrot > | +---oplib > +---languages > | > +---LICENSES > +---runtime > | > +---src > | +---charset # moved from charset/ > | +---classes # moved from classes/ > | +---dynclasses# moved from dynclasses/ > | +---dynoplibs # moved from dynoplibs/ > | +---encodings # moved from encodings/ > | +---io# moved from io/ > | +---jit # moved from jit/ > | | > | +---ops # moved from ops/ > | +---pf# moved from pf/ > | +---types # moved from types/ > +---t > | +---compilers > | | +---imcc # moved from imcc/t/ > | | | > | | +---pge > | | | +---p5regexp > | | | +---p6rules > | | +---tge > | +---doc > | +---dynclass > | +---examples > | +---library > | +---native_pbc > | +---op > | +---perl > | +---pmc > | +---run > | +---src > | +---stress > | +---tools > +---tools > | +---build_tools # moved from build/ > | +---dev > | +---docs > | +---editor# moved from editor/, no Makefile, > converted to perl > | +---util # moved from util/ > > > this work can and should be done one piece at a time to prevent > widespread panic. if this proposal is accepted, i will create > todo tasks for each unit of work. then, they can be assigned one > at a time, until the task is complete. of course, a realclean / > configure / make test cycle should be done after each change to > ensure it has gone smoothly. > > thoughts? > ~jerry > -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: parrot directory reorganization
On Mon, Nov 28, 2005 at 04:45:33PM -0800, jerry gay wrote: > the parrot directory structure is large and a bit disorganized. > let me give you some examples: > * build_tools/, util/, and tools/*/ each contain utility perl > scripts. these should be grouped together under tools/, which > already contains subdirectories Sounds reasonable. > * there are multiple dirs containing C source code (charset, > classes, io, etc.) these should be grouped together under src/ I've found that reorganizing source trees tends to expose lots of build dependency problems so it's probably worth doing for that reason alone. However, it should be done with some caution and lots of warning for those that have uncommitted changes. > * the editor/ directory contains files for text editors and has > a generated makefile. there is no reason for this to be a make > target. a perl script should be created to replace makefile, > and the dir moved with the other tool & utility scripts. I disagree. A Perl script won't do any better of a job and will be more complex then that rather simple makefile. > * imcc test files are not grouped with other tests (this is > already on my TODO list and should be done RSN.) Does it make sense for the tests to even refer to imcc? IMHO Parrot ability to digest PIR is whats really being tested. However unlikely, it's worth keeping in ind that Parrots internal PIR compiler may be replaced someday. > i propose reorganizing the tree to improve clarity and cohesion. > here is an annotated picture of the current tree (extra info > ped as shown.) [SNIP] > this work can and should be done one piece at a time to prevent > widespread panic. if this proposal is accepted, i will create > todo tasks for each unit of work. then, they can be assigned one > at a time, until the task is complete. of course, a realclean / > configure / make test cycle should be done after each change to > ensure it has gone smoothly. I'd suggest that you consider making the change in two phases. With all of the non-"move it under /src" changes first as it will cause less disruption in the tree. Cheers, -J -- pgpKeQ3QkX6G5.pgp Description: PGP signature
Re: parrot directory reorganization
On Mon, Nov 28, 2005 at 05:37:19PM -1000, Joshua Hoblitt wrote: > On Mon, Nov 28, 2005 at 04:45:33PM -0800, jerry gay wrote: > > * the editor/ directory contains files for text editors and has > > a generated makefile. there is no reason for this to be a make > > target. a perl script should be created to replace makefile, > > and the dir moved with the other tool & utility scripts. > > I disagree. A Perl script won't do any better of a job and will be more > complex then that rather simple makefile. I mildly agree with Joshua about Makefiles. More to the point, I don't like changing directory tree and build tech at the same time. They're separate changes. > > * imcc test files are not grouped with other tests (this is > > already on my TODO list and should be done RSN.) > > Does it make sense for the tests to even refer to imcc? IMHO Parrot > ability to digest PIR is whats really being tested. However unlikely, > it's worth keeping in ind that Parrots internal PIR compiler may be > replaced someday. Oh, one other thing for the renaming game: IMC vs. PIR Two names enter One name leaves /me giggles -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: parrot directory reorganization
jerry gay <[EMAIL PROTECTED]> wrote: > the parrot directory structure is large and a bit disorganized. > let me give you some examples: Agreed. I find this confusing sometimes, not being intimately familiar with all of parrot. > i propose reorganizing the tree to improve clarity and cohesion. > here is an annotated picture of the current tree (extra info > ped as shown.) > thoughts? I'd really like to see imcc/docs/ get moved to docs/imcc/ while we're moving things around. I know that some people consider imcc to be rather separate from parrot, but as a compiler writer, I see it as a core feature. I always seem to forget that there are docs in imcc/docs/ and end up grepping through docs/ instead (missing valuable information). -- matt diephouse http://matt.diephouse.com
