Re: imcc/ directory
MrJoltCola wrote: At 06:57 PM 4/11/2005, Matt Diephouse wrote: Now that IMCC is a core part of Parrot, I'd like to see the imcc/ directory go away. Technically IMCC should be separate I think mild separation that still exists is a good thing. IMCC does not actually execute anything, it is a registered front-end that handles PIR and PASM. You could add another front-end called PIR2 if you wanted. It just so happens that IMCC is the default front-end. Actually there is already a second front end, PAST, which resides in the 'ast/' directory. It might make sense to refactor 'imcc/main.c' and split it into e.g. 'src/main.c' and 'imcc/frontend.c'. This would make the distinction more clear, and would provide an opportunity to clean up the exported symbols. CU, Bernhard -- ** Dipl.-Physiker Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel: +49 89 895574-839 Fax: +49 89 895574-825 eMail: [EMAIL PROTECTED] Website: www.biomax.com **
Re: [perl #34704] [PATCH] get SDL running on win32
Jerry Gay [EMAIL PROTECTED] wrote: the attached patch gets the SDL library and examples running on win32. Are there more Win32 libs that have the same naming conventions: unixish: win32: libSDL SDL The question is, if the dynext loader should try to strip ^lib off the library name. leo
Re: [perl #34912] Badly balanced at classes/pmc2c2.pl
Jrieks @ Wmit00 . It . Math . Uni-Wuppertal . De [EMAIL PROTECTED] wrote: wmit01 ~ perl -v This is perl, v5.6.0 built for i586-linux As it seems to be a perl issue, please check the relevant part of the PMC compiler. IIRC there was a patch regarding Cextract_balanced not too long ago. leo
Re: imcc/ directory
Matt Diephouse [EMAIL PROTECTED] wrote: Now that IMCC is a core part of Parrot, I'd like to see the imcc/ directory go away. I'd be willing to spend some time trying to prepare some patches (it'd be a good way to become more familiar with the source), but I have a few questions first: (1) Is this desirable? As Melvin already stated, no: IMCC is a distinct subsystem of parrot namely the PASM/PIR compilers (or assemblers). If you like to spend time on it, I'd prefer the following instead: - split PASM/PIR parsers and lexers into tow distinct file pairs - make the C.macro pre-processor a separate pass (2) Does IMCC's version number ever differ from Parrot's? We probably don't need the IMCC_VERSION. (3) Should all the headers in imcc/ be moved to include/parrot/? No, they are mostly private to IMCC. But we need eventually a public compiler interface, which should reside inside include/parrot. (4) Should all the files be moved to src/? No with one exception: imcc/sets.c is a file implementing a bit set. All functions should get a Parrot prefix and an interpreter argument. (5) Should the contents of the docs/, examples/, and t/ directories be moved to the root directories of the same names? imcc/examples is useless, it can go away. imcc/docs needs some updates. Especially syntax.pod sould be pasm.pod and pir.pod. Both are not quite up-to-date. The tests are for testing the assemblers and should stay there. (6) Is there a document i should be reading about Parrot's directory structure? Probably: $ perldoc -F docs/pdds/pdd07_codingstd.pod /Subsystems (7) Should IMCC_ functions stay with that prefix or be renamed to use Parrot_ or something similar? The IMCC_ prefix is fine. (8) Is there any reason to keep src/parrot.c around? I'd like that to be eventually the real start program. It should parse the commandline arguments and select an appropriate compiler depending on the source filetype. One of these compilers is IMCC (or two :) (9) Is there anything else I should be aware of? Yes ;) Thanks. leo
Re: Takers wanted - a perl job
On Tue, Apr 12, 2005 at 11:08:30AM +0200, Leopold Toetsch wrote: t/src/manifest.t tests 3 and 4 used to compare MANIFEST file entries against CVS/Entries. The latter is now .svn/entries with an xmlish syntax. The job is now to replace t/src/manifest.t:scan_cvs so that it extracts Cname items from .svn/entries and descends into Ckind=dir subdirectories. And no - I don't think, we need a full-fledged XML parser for this. No need to parse the XML files, svn list -R lists everything in the repo. And I suppose I just volunteered myself for the job.
Re: Takers wanted - a perl job
On Tue, Apr 12, 2005 at 02:50:57AM -0700, Michael G Schwern wrote: No need to parse the XML files, svn list -R lists everything in the repo. And I suppose I just volunteered myself for the job. $ svn list -R svn: '.' is not a working copy Doesn't work when svk is used to check out the copy. But in that case svk list -R does. Nicholas Clark
Re: Takers wanted - a perl job
Leopold Toetsch wrote:
t/src/manifest.t tests 3 and 4 used to compare MANIFEST file entries
against CVS/Entries. The latter is now .svn/entries with an xmlish syntax.
The job is now to replace t/src/manifest.t:scan_cvs so that it extracts
Cname items from .svn/entries and descends into Ckind=dir
subdirectories. And no - I don't think, we need a full-fledged XML
parser for this.
No XML parser? Bummer, it would be sooo much simpler. ;-)
C:\parrot\.svnperl -MXML::Simple -MData::Dumper
-eprint(join \\n\, keys %{XMLin('entries')-{entry}})
encodings
ops
pf
ast
PBC_COMPAT
MANIFEST
...
VERSION
build_tools
README
Ron
Re: [perl #34704] [PATCH] get SDL running on win32
On 12 Apr 2005 09:44:08 -, Leopold Toetsch via RT [EMAIL PROTECTED] wrote: Jerry Gay [EMAIL PROTECTED] wrote: the attached patch gets the SDL library and examples running on win32. Are there more Win32 libs that have the same naming conventions: unixish: win32: libSDL SDL The question is, if the dynext loader should try to strip ^lib off the library name. the convention on windows is not to include the lib prefix, however there are exceptions. notably, the windows svn client, and trillian, my irc client. centralizing the logic of loading libraries so it Just Works on any platform makes sense to me. this should follow for other conventions on other platforms, as well. i dunno what macOS and os2 do. and then i could stop patching runtime libraries and move on to something more exciting :) leo ~jerry
Re: SVN revision (was: [perl #xxxxxx] Badly balanced at classes/pmc2c2.pl)
On Monday 11 April 2005 17:54, Leopold Toetsch wrote: BTW: a nice to have: include SVN revision of local copy in bug report. I'll implement it. jens
Re: [PATCH] Dynamic Perl, 2 [t/]
William Coleda [EMAIL PROTECTED] wrote: Or, rather, find the attached patch here: https://rt.perl.org/rt3/Ticket/Attachment/110536/75860/dynamic_perl2.patch Thanks, applied. leo
Re: [perl #34704] [PATCH] get SDL running on win32
jerry gay wrote: On 12 Apr 2005 09:44:08 -, Leopold Toetsch via RT [EMAIL PROTECTED] wrote: The question is, if the dynext loader should try to strip ^lib off the library name. the convention on windows is not to include the lib prefix, however there are exceptions. Ok, let's try it. Please test rev 7813. leo
Re: [perl #34704] [PATCH] get SDL running on win32
On 12 Apr 2005 15:14:58 -, Leopold Toetsch via RT [EMAIL PROTECTED] wrote: jerry gay wrote: On 12 Apr 2005 09:44:08 -, Leopold Toetsch via RT [EMAIL PROTECTED] wrote: The question is, if the dynext loader should try to strip ^lib off the library name. the convention on windows is not to include the lib prefix, however there are exceptions. Ok, let's try it. Please test rev 7813. works! the win32-specific stuff can be ripped out of runtime/library/pcre.imc SDL.imc. or i'll submit a patch if you'd rather. leo ~jerry
Re: [perl #34704] [PATCH] get SDL running on win32
On Tue, 2005-04-12 at 10:59 -0700, jerry gay wrote: works! the win32-specific stuff can be ripped out of runtime/library/pcre.imc SDL.imc. or i'll submit a patch if you'd rather. There shouldn't be any Win32-specific stuff in SDL.imc now. (I don't see any.) There's Debian-specific stuff, but that's just Debian being charmingly itself. If Jerry's happy, I'm happy and the RT overlords can close this ticket. -- c
Re: [perl #34704] [PATCH] get SDL running on win32
i'm happy. close the ticket. On 12 Apr 2005 18:10:49 -, chromatic via RT [EMAIL PROTECTED] wrote: On Tue, 2005-04-12 at 10:59 -0700, jerry gay wrote: works! the win32-specific stuff can be ripped out of runtime/library/pcre.imc SDL.imc. or i'll submit a patch if you'd rather. There shouldn't be any Win32-specific stuff in SDL.imc now. (I don't see any.) There's Debian-specific stuff, but that's just Debian being charmingly itself. If Jerry's happy, I'm happy and the RT overlords can close this ticket. -- c
[perl #34932] [PATCH] Add -I/path/to/icu/headers flag if needed
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #34932]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34932
If the user has ICU installed in a location not normally searched by
the compiler, but does specify the location of the icu-config program,
Configure.pl ought to add in the appropriate -I/path/to/icu to
ccflags, if necessary.
This patch has Configure.pl test if that additional -I flag is needed.
If ICU is found, it first tries to include unicode/ucnv.h. If that
fails, then it adds -I $icuheaders to ccflags.
I don't understand ICU on Windows. If anyone could test this patch
there, I'd appreciate it.
[As an aside: I didn't suggest using icu-config --cppflags because
that's broken in icu-3.2 for Solaris; I've sent an appropriate patch
off to the icu list.]
Apply with patch -p1.
diff -r -u parrot-orig/config/gen/icu.pl parrot-andy/config/gen/icu.pl
--- parrot-orig/config/gen/icu.pl Mon Apr 11 11:14:55 2005
+++ parrot-andy/config/gen/icu.pl Tue Apr 12 10:58:53 2005
@@ -142,10 +142,29 @@
Configure::Data-set(
has_icu= 1,
icu_shared = $icushared,
-icu_cflags = -I$icuheaders,
icu_headers = join( ' ', @icu_headers ),
icu_datadir = $icudatadir,
);
+
+ # Add -I $Icuheaders if necessary
+ my $header = unicode/ucnv.h;
+ Configure::Data-set(testheaders =#include $header\n);
+ Configure::Data-set(testheader = $header);
+ cc_gen('config/auto/headers/test_c.in');
+
+ Configure::Data-set(testheaders = undef); # Clean up.
+ Configure::Data-set(testheader = undef);
+ eval { cc_build(); };
+ if (!$@ cc_run() =~ /^$header OK/) {
+# Ok, we don't need anything more.
+print Your compiler found the icu headers... good!\n if $verbose;
+ }
+ else {
+print Adding -I $icuheaders to ccflags for icu headers.\n if $verbose;
+Configure::Data-add(' ',
+ccflags= -I $icuheaders);
+ }
+ cc_clean();
$Configure::Step::result = yes;
--
Andy Dougherty [EMAIL PROTECTED]
[perl #34933] [PATCH] Handle trailing space in $(LD_OUT)
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #34933]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34933
Removing ICU from the build uncovered an odd build bug concerning the
space after ${ld_out} in config/init/data.pl. This patch fixes it.
Gory details:
The Makefile command to build ./parrot is (essentially)
$(LINK) $(LINKFLAGS) $(LD_OUT)$(PARROT) $(IMCC_DIR)/main$(O)
Note how there's no space between LD_OUT and PARROT. That's
deliberate, I think, allowing for VMS-like syntax
link /output=parrot.exe
on the compile line.
On Unix systems, however, the typical command would be
cc -o parrot
Some compilers don't require the space after the '-o'; Sun's CC
compiler does (at least under certain conditions, which are triggered
by the parrot Makefile). The ${ld_out} Configure.pl variable contains
a trailing space, and the $(LD_OUT) Makefile variable also holds that
trailing space. However, not all 'make' programs honor trailing
spaces. GNU make does. Sun's make doesn't. NetBSD make doesn't
either.
This patch takes the issue out of make's hands and leaves it up to
perl to decide as it extracts the root.in Makefile. Since I highly
doubt that anyone is experimenting with command-line overrides for LD_OUT
when they type 'make', this fix should be safe and sensible.
diff -r -u parrot-orig/config/gen/makefiles/root.in
parrot-andy/config/gen/makefiles/root.in
--- parrot-orig/config/gen/makefiles/root.inMon Apr 11 11:14:51 2005
+++ parrot-andy/config/gen/makefiles/root.inTue Apr 12 12:32:04 2005
@@ -121,7 +121,6 @@
SHARE_EXT = ${share_ext}
LOAD_EXT= ${load_ext}
A = ${a}
-LD_OUT = ${ld_out}
LD_SHARE_FLAGS = ${ld_share_flags}
LD_LOAD_FLAGS = ${ld_load_flags}
@@ -625,7 +624,7 @@
$(PARROT) parrot-config.imc VERSION DEVEL
$(PARROT) : $(IMCC_DIR)/main$(O) $(GEN_HEADERS) $(LIBPARROT)
lib/Parrot/OpLib/core.pm
- $(LINK) $(LD_OUT)$(PARROT) $(LINKFLAGS) $(IMCC_DIR)/main$(O)
$(ALL_PARROT_LIBS)
+ $(LINK) ${ld_out}$(PARROT) $(LINKFLAGS) $(IMCC_DIR)/main$(O)
$(ALL_PARROT_LIBS)
lib_deps_object : $(O_FILES)
$(PERL) tools/dev/lib_deps.pl object $(O_FILES)
@@ -660,10 +659,10 @@
blib/lib/libparrot$(SHARE_EXT) : $(O_FILES)
$(MKDIR) blib blib/lib
- $(LD) $(LD_SHARE_FLAGS) $(LDFLAGS)
$(LD_OUT)blib/lib/libparrot$(SHARE_EXT) $(O_FILES) $(C_LIBS) $(LIBICUCORE)
$(LIBICUDATA)
+ $(LD) $(LD_SHARE_FLAGS) $(LDFLAGS)
${ld_out}blib/lib/libparrot$(SHARE_EXT) $(O_FILES) $(C_LIBS) $(LIBICUCORE)
$(LIBICUDATA)
$(PARROT_SO) : $(IMCC_DIR)/main$(O) blib/lib/libparrot$(SHARE_EXT)
lib/Parrot/OpLib/core.pm
- $(LINK) $(LINKFLAGS) $(LD_OUT)$(PARROT) $(IMCC_DIR)/main$(O) -Lblib/lib
-lparrot $(C_LIBS)
+ $(LINK) $(LINKFLAGS) ${ld_out}$(PARROT) $(IMCC_DIR)/main$(O) -Lblib/lib
-lparrot $(C_LIBS)
#
# Parrot Debugger
@@ -672,7 +671,7 @@
$(SRC_DIR)/pdb$(O) : $(GENERAL_H_FILES)
$(PDB) : $(SRC_DIR)/pdb$(O) $(LIBPARROT)
- $(LINK) $(LD_OUT)$(PDB) $(SRC_DIR)/pdb$(O) $(LINKFLAGS)
$(ALL_PARROT_LIBS)
+ $(LINK) ${ld_out}$(PDB) $(SRC_DIR)/pdb$(O) $(LINKFLAGS)
$(ALL_PARROT_LIBS)
#
# Parrot Disassembler
@@ -681,19 +680,19 @@
$(SRC_DIR)/disassemble$(O) : $(GENERAL_H_FILES)
$(DIS) : $(SRC_DIR)/disassemble$(O) $(LIBPARROT)
- $(LINK) $(LD_OUT)$(DIS) $(SRC_DIR)/disassemble$(O) $(LINKFLAGS)
$(ALL_PARROT_LIBS)
+ $(LINK) ${ld_out}$(DIS) $(SRC_DIR)/disassemble$(O) $(LINKFLAGS)
$(ALL_PARROT_LIBS)
#
# Parrot Dump
#
$(PDUMP) : $(SRC_DIR)/pdump$(O) $(SRC_DIR)/packdump$(O) $(LIBPARROT)
- $(LINK) $(LD_OUT)$(PDUMP) $(SRC_DIR)/pdump$(O) $(SRC_DIR)/packdump$(O)
$(LINKFLAGS) $(ALL_PARROT_LIBS)
+ $(LINK) ${ld_out}$(PDUMP) $(SRC_DIR)/pdump$(O) $(SRC_DIR)/packdump$(O)
$(LINKFLAGS) $(ALL_PARROT_LIBS)
# pbc_info
$(PINFO) : $(SRC_DIR)/pbc_info$(O) $(LIBPARROT)
- $(LINK) $(LD_OUT)$(PINFO) $(SRC_DIR)/pbc_info$(O) $(LINKFLAGS)
$(ALL_PARROT_LIBS)
+ $(LINK) ${ld_out}$(PINFO) $(SRC_DIR)/pbc_info$(O) $(LINKFLAGS)
$(ALL_PARROT_LIBS)
###
#
@@ -1361,17 +1360,17 @@
###
exec : $(SRC_DIR)/exec_start$(O) $(LIBPARROT)
- $(LINK) $(LD_OUT)$(EXEC) $(LINKFLAGS) $(EXEC)$(O)
$(SRC_DIR)/exec_start$(O) $(ALL_PARROT_LIBS)
+ $(LINK) ${ld_out}$(EXEC) $(LINKFLAGS) $(EXEC)$(O)
$(SRC_DIR)/exec_start$(O) $(ALL_PARROT_LIBS)
exec_so : $(SRC_DIR)/exec_start$(O) blib/lib/libparrot$(SHARE_EXT)
- $(LINK) $(LD_OUT)$(EXEC) $(LINKFLAGS) $(EXEC)$(O)
$(SRC_DIR)/exec_start$(O) -lparrot $(C_LIBS)
+ $(LINK) ${ld_out}$(EXEC) $(LINKFLAGS) $(EXEC)$(O)
$(SRC_DIR)/exec_start$(O) -lparrot $(C_LIBS)
## OS depend targets ##
# for use by t/pmc/nci.t
$(LIBNCI_TEST_SO):
Re: [perl #34704] [PATCH] get SDL running on win32
chromatic wrote: There's Debian-specific stuff, but that's just Debian being charmingly itself. That should go away too. The canonical fix is to create the missing symlinks and probably submit patches to debian. leo
Re: [perl #34932] [PATCH] Add -I/path/to/icu/headers flag if needed
On Tuesday 12 April 2005 19:10, Andy Dougherty wrote: # New Ticket Created by Andy Dougherty # Please include the string: [perl #34932] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34932 If the user has ICU installed in a location not normally searched by the compiler, but does specify the location of the icu-config program, Configure.pl ought to add in the appropriate -I/path/to/icu to ccflags, if necessary. This patch has Configure.pl test if that additional -I flag is needed. If ICU is found, it first tries to include unicode/ucnv.h. If that fails, then it adds -I $icuheaders to ccflags. Thanks, applied! I don't understand ICU on Windows. If anyone could test this patch there, I'd appreciate it. [As an aside: I didn't suggest using icu-config --cppflags because that's broken in icu-3.2 for Solaris; I've sent an appropriate patch off to the icu list.] Apply with patch -p1. [snip] jens
Win32 with ICU files build problem
I'm sorry if this is a repeat... I posted this accidentally to perl6-language... Following the instructions in README.Win32 (which has been successful for me in the past), no longer works successfully. First, I cannot run Configure.pl successfully; it complains about --icudatadir not being defined (again not one of the --icu* options mentioned in README.Win32 AND not necessary before). Defining --icudatadir, I now get the following error during make: Src\string_primitives.c(24) : fatal error C1083: Cannot open include file: 'unicode/ucnv.h': No such file or directory I had defined --icuheaders in my call to Configure in whose directory 'unicode/ucnv.h' does exist. Does this mean that Configure is ignoring --icuheader or --icuheader is ignored in the build of the file above? Has anyone successfully built Parrot on Win32 (MSVC 13.10.3077) recently? Mark Solinski
Re: Win32 with ICU files build problem
On Tuesday 12 April 2005 21:06, Solinski, Mark wrote: Following the instructions in README.Win32 (which has been successful for me in the past), no longer works successfully. First, I cannot run Configure.pl successfully; it complains about --icudatadir not being defined (again not one of the --icu* options mentioned in README.Win32 AND not necessary before). Defining --icudatadir, I now get the following error during make: Src\string_primitives.c(24) : fatal error C1083: Cannot open include file: 'unicode/ucnv.h': No such file or directory With which command line arguments is the compiler called? I had defined --icuheaders in my call to Configure in whose directory 'unicode/ucnv.h' does exist. Does this mean that Configure is ignoring --icuheader or --icuheader is ignored in the build of the file above? Configure.pl does not complain about missing headers, does it? Can you please retry with the latest version of parrot (= r7817), run Configure.pl with --verbose-step=ICU and provide its output? Has anyone successfully built Parrot on Win32 (MSVC 13.10.3077) recently? No, but I tried it on an old Win98 box with VC6 or so, it worked there. (The problem though was that each time parrot is invoked, No such file or directory appears in the output, but the result looks okay nevertheless - have to dig into it another time...) Mark Solinski jens
Re: Win32 with ICU files build problem
I succeeded using the mingw32 setup. I counldn't get the Visual Studio.Net or free VC++ compilers to work, and ran out of energy. On Apr 12, 2005 12:06 PM, Solinski, Mark [EMAIL PROTECTED] wrote: I'm sorry if this is a repeat... I posted this accidentally to perl6-language... Following the instructions in README.Win32 (which has been successful for me in the past), no longer works successfully. First, I cannot run Configure.pl successfully; it complains about --icudatadir not being defined (again not one of the --icu* options mentioned in README.Win32 AND not necessary before). Defining --icudatadir, I now get the following error during make: Src\string_primitives.c(24) : fatal error C1083: Cannot open include file: 'unicode/ucnv.h': No such file or directory I had defined --icuheaders in my call to Configure in whose directory 'unicode/ucnv.h' does exist. Does this mean that Configure is ignoring --icuheader or --icuheader is ignored in the build of the file above? Has anyone successfully built Parrot on Win32 (MSVC 13.10.3077) recently? Mark Solinski
Summary for the week ending 2005-04-12
The Perl 6 Summary for the week ending 2005-04-12 Whoa! Deja vu! Where'd Matt go? Don't worry, Matt's still writing summaries. As you may have noticed, Matt's been writing summaries every two weeks. And now so am I. Because we love you, we've decided to arrange things so I write summaries in the weeks when Matt doesn't. We could do it the other way, but that could be seen by some as self-defeating. Heck, when I say 'some' I probably mean 'all'. So, bear with me while I remember how to type all those accented characters and get back into the swing of writing these things (and of reading everything in the mailing lists once more -- someone should write a summary for us summarizers...) I'll be sticking to my old 'lists in alphabetical order' scheme of writing summaries. So, let's get going This week in perl6-compiler Array of arrays, hash of hashes, elems, last Lev Selector asked for confirmation that Pugs didn't support compound data structures, @ar.elems or @ar.last. Autrijus and others confirmed that they didn't then, but they do now. http://xrl.us/fq99 MakeMaker6 stalls on takeoff Darren Duncan pointed out that, whilst last week's summary had claimed he was working on implementing MakeMaker in Perl 6 which is, sadly not the case. He reckoned he'd possibly look into it again when he had tuits and Pugs was more complete (supporting objects, for instance). http://xrl.us/fraa Declaration oddness Roie Marianer pointed out what looks like some weirdness in Pugs' parsing of lexically scoped subroutines. Warnock applies. http://xrl.us/frab Toronto pugs hackathon John Macdonald asked for people who wanted to come to the YAPC::NA pugs hackathon to get in touch with him beforehand as spaces there are limited. If you're interested, drop him a line. http://xrl.us/frac Pugs slice oddities Andrew Savige noticed some weirdness in pugs's slicing behaviour. He posted some example code showing the problem. Autrijus agreed that there was a problem and explained that he was in the process of rewriting all the variable types, symbol tables and casting rules to agree with the Perl 5 model as described in perltie.pod. The rewrite is currently failing tests, so he posted a patch for people who want to play. On Sunday, he bit the bullet and committed the entire 2500 line patch which 'touches pretty much all evaluator code'. http://xrl.us/frad -- Autrijus's patch http://xrl.us/frae -- Autrijus on the patch http://xrl.us/fraf Meanwhile, in perl6-internals Tcl, Unicode William Coleda has been trying to add Unicode support to his TCL implementation and he fell across issues with missing methods in charset/unicode.h. Leo waved a magic wand and checked in an implementation which he fenced about with disclaimers. http://xrl.us/frag The status of Ponie Nicholas Clark confessed that Ponie had been pretty much stalled for some time, but sweetened the pill by announcing that it's about to restart and that he would be able to allocate at least one day a week to the project. He pointed people at the Ponie roadmap which breaks down the required tasks between here and a first release, complete with time estimates. If you're interested in getting Ponie to a ridable state, this would be a good place to start. People were pleased. http://xrl.us/frah -- Ponie intro/roadmap http://xrl.us/frai Monthly release schedule Chip donned his Fearless Leader hat and announced that, effective, Parrot would be moving to a monthly release schedule (with an initial three week 'month' to get things into sync). There was some debate about whether Solaris/SPARC should be one of the officially required monthly release platforms (darwin, linux-x86-gcc3.* and win32-ms-cl were Chip's initial blessed three). This morphed into a discussion of Tinderbox; apparently there are cool things happening behind the scenes. http://xrl.us/fraj Calling convention abstraction What do you know? You go away for n months and when you come back people are *still* talking about calling conventions. http://xrl.us/fram Dynamic Perl, Part 1 William Coleda announced that he was starting work on removing the core's dependence on Perl* PMCs in favour of using language agnostic PMCs internally and loading the Perl ones dynamically as required. Everything but PerlArray was dealt with quickly and names and ways forward with that tricky case were discussed. It looks like we're going to have a 'ResizablePMCArray' added to the core once people have the tuits. http://xrl.us/fran Subversion Another discussion that wouldn't go away back when I was last writing summaries has come to a head. Parrot's finally migrating from CVS to Subversion. By the time
Re: Takers wanted - a perl job
On Tue, Apr 12, 2005 at 10:54:14AM +0100, Nicholas Clark wrote: On Tue, Apr 12, 2005 at 02:50:57AM -0700, Michael G Schwern wrote: No need to parse the XML files, svn list -R lists everything in the repo. And I suppose I just volunteered myself for the job. $ svn list -R svn: '.' is not a working copy Doesn't work when svk is used to check out the copy. But in that case svk list -R does. Hmm. Maybe this should be a commit action and not a test.
Re: Win32 with ICU files build problem
On Apr 12, 2005 12:06 PM, Solinski, Mark [EMAIL PROTECTED] wrote: Has anyone successfully built Parrot on Win32 (MSVC 13.10.3077) recently? parrot builds fine on win32--vc-7.1-perl-5.8.6 for me, without icu. i have been building this way for some time now. configure.pl --without-icu nmake nmake test i have not tried with icu for the past several days. Mark Solinski ~jerry
Re: perlscalar morph code
On Tue, 12 Apr 2005, Nicholas Clark wrote: I think that there are 2 bugs here 1: Morphing from enum_class_PerlString to enum_class_BigInt or enum_class_Complex looks broken. The return in the second if clause will quit the function and the DYNSELF.init() will never get called. Can anyone easily write a regression test that demonstrates this This code: new P0, .PerlString new P1, .BigInt typeof I1, P1 morph P0, I1 set P0, 123 print P0 end segfaults for me with the latest snapshot of parrot, but prints '123' as expected if you remove the two lines mentioned below. The analogous test with Complex instead of BigInt appears to work regardless of whether the lines are present or not. I think that the cure is to remove SELF-vtable = Parrot_base_vtables[type]; return; I've also re-run the test suite with these lines removed, and all existing tests still pass. Hope this is useful, Simon
Re: Summary for the week ending 2005-04-12
On Tue, 12 Apr 2005, The Perl 6 Summarizer wrote: Dynamic Perl, Part 1 William Coleda announced that he was starting work on removing the core's dependence on Perl* PMCs in favour of using language agnostic PMCs internally and loading the Perl ones dynamically as required. Everything but PerlArray was dealt with quickly and names and ways forward with that tricky case were discussed. It looks like we're going to have a 'ResizablePMCArray' added to the core once people have the tuits. Minor correction: 'ResizablePMCArray' is already in the core, but some of the necessary vtable methods still need to be implemented (and tested!). Simon
Pugs 6.2.0 released.
I am delighted to report that the first major milestone of Pugs, version
6.2.0, has been released to CPAN:
http://wagner.elixus.org/~autrijus/dist/Perl6-Pugs-6.2.0.tar.gz
SIZE (Perl6-Pugs-6.2.0.tar.gz) = 642482
MD5 (Perl6-Pugs-6.2.0.tar.gz) = 8d5438d49db872ffe2394fd4995d335b
It represents the culmination of 71 days of intensive work, by more
than 60 people in our committer team, with nearly 2000 revisions.
According to the roadmap in PA01, this and the next milestone are:
6.2: Basic IO and control flow elements; mutable variables; assignment.
6.28: Classes and traits.
In other words, we are now reasonably confident that the basics of
Perl 6 syntax and data structures are in place. We already have an
object/type system now, and the 6.2.x series will make them available
on the language leve, together with a full-fledged class system.
After this release, I will take a short break from coding Pugs, and
focus on writing Pugs Apocryphon 2: Design of Pugs. In it I will
explain the relation of the various components in Pugs, as well as how
it relates to Parrot, GHC, and other systems. Once it is written,
I plan to start working on the IMC subsystem, with the goal of making
Parrot IMC the primary target for the 6.28.0 release.
Again, thanks too all lambdacamels for making this release possible,
and for building this new ship with me.
Enjoy,
/Autrijus/
== Changes for 6.2.0 - April 13, 2005
=== Pugs Internals
* Major refactor of ITypes subsystem, we now have:
** Nested structures: `$a{1}[2]{3}`
** Autovivification: `$a{1}[2]{3} = b`
** Tied magic: `%ENVUSER`
** Proxy scalars: `%ENVPATH ~= '/tmp'`
** Slice assignment: [EMAIL PROTECTED],2] = a b`
** Anonymous arrays: `[1..10][0] = 0`
** Lazy IArray structures: Infinite lists, constant time
** Infinite slices: [EMAIL PROTECTED]
** and much much more ...
* Experimental support for link external Haskell libraries
** One such module is SHA1.pm: http://tpe.freepan.org/repos/ingy/SHA1/
* New builtins:
** `sum`, `log`, `log10`, `sign`, `pi`, `tan`, `cos`, `atan`
** `zip`, `hash`, `pair`, `isa`, `bytes`, `chars`, `codes`, `graphs`
* New type specific builtins;
** `.kv`, `.pairs`, `.delete`, `.exists`
** `.pick`, `.keys`, `.values`
* Several file test operators
** `-r`, `-w`, `-x`, `-e`, `-z`, `-s`, `-f`, `-d`
* Support for `$*UID`, `$*EUID`, `$*GID`, and `$*EGID` on *nix
* Stacked file test operators now (mostly) work
* Added `is rw` trait for subroutine parameters
* `$*PID` now works on *nix systems
* Several command line switches implemented: `-I` `-p` `-n` and more
* `s:perl5/.../{ code }/` works correctly
* Type casting errors are now more descriptive
* `require ` now works on UTF-8 files
* Regex substitution is now UTF-8 safe
* `sort {}` now works
* Some support for the /splat/ star `*`
=== Tests, Examples and Documentations
* Many new tests and cleaning up of older tests, we now have 4200+
* `examples/games/hangman.p6` added which uses the `AUTHORS` file as
the dictionary file
* `READTHEM` added; recommended reading for aspiring Pugs hackers
* The Perl 6 Cookbook is well underway at `examples/cookbook/`
* Working perl6 modules added to `ext/`
** CGI.pm
** lib.pm
** HTML::Entities
* Several Working Drafts added to `docs/`
** Apocalypse 20 - Debugging
** Synopsis 26 - Perl Documentation
** Synopsis 28 - Special Variables
** Synopsis 27 - Perl Culture (with CPAN drinking game rules)
** Synopsis 29 - Builtin Functions
* Early work on Perl 6 Object System in `docs/class/`
=== Bug Fixes
* Parens no longer required for; `last()` and `return()`
* Fixed issue with binding invocant parameters
* Fixed parsing issue with `lc $, $y`
* `$_` now behaves correctly in most cases
* `exit()` now triggers `END {}` correctly
* `undef $x` now works correctly ($x is rw)
* Fixed parsing of default parameters: `sub foo (+$x = 3, +$y = 4)`
* `say` and `print` now default to `$_`
* `map { ... } @list` now parses correctly
* `loop { ... }` no works correctly
* `int(3) + 4` now parses correctly
* Fix parsefail bug on false unaries
* `for (@list)` no longer flattens [EMAIL PROTECTED]
* `$var.method $param` is now illegal: use `$var.method($param)`
* `readline()` is now strict in list context
* `$list.join('|')` now works
* `xor` and `^^` now short-circuits
* Named bindings to `%_` repaired
pgpBxt2tZUn5h.pgp
Description: PGP signature
[perl #34935] [PATCH] r7818: removing more warnings in src/
# New Ticket Created by jerry gay # Please include the string: [perl #34935] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34935 This transaction appears to have no contentthis patch against r7818 should eliminate many more warning messages in src/*.c i'll follow up with another patch against other dirs ~jerry r7818-src-warnings.patch Description: Binary data
[perl #34936] [PATCH] r7818: removing more warnings in other dirs
# New Ticket Created by jerry gay # Please include the string: [perl #34936] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34936 This transaction appears to have no contentthis patch covers charset/, ops/, pf/, classes/, and io/ adds typecast info, and removes unreferenced locals BTW svn made this very much easier than cvs. ~jerry r7818-other-warnings.patch Description: Binary data
[perl #34937] [PATCH] Absolute library paths on Win32
# New Ticket Created by Philip Taylor
# Please include the string: [perl #34937]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34937
This patch makes Parrot recognise /path/to/file and c:/path/to/file as
absolute paths on Win32 (so that e.g. 'load_bytecode c:/path/to/file'
can be used instead of 'load_bytecode c:\\path/to/file')
--
Philip Taylor
[EMAIL PROTECTED]
Index: src/library.c
===
--- src/library.c (revision 7810)
+++ src/library.c (working copy)
@@ -202,8 +202,10 @@
/* use absolute paths as is */
#ifdef WIN32
-if (file_name[0] == '\\' || (isalpha(file_name[0])
-strncmp(file_name+1, :\\, 2) == 0)) {
+if (file_name[0] == '\\' || file_name[0] == '/' ||
+(isalpha(file_name[0])
+(strncmp(file_name+1, :\\, 2) == 0 ||
+ strncmp(file_name+1, :/, 2) == 0))) {
#else
if (file_name[0] == '/') {
#endif
Re: [PROPOSAL] calling convention abstraction
From: Roger Hale [EMAIL PROTECTED] Date: Mon, 11 Apr 2005 09:30:32 -0400 Bob Rogers wrote: From: Roger Hale [EMAIL PROTECTED] Date: Thu, 07 Apr 2005 04:23:41 -0400 Leopold Toetsch wrote: Roger Hale [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: As @ARGS (or @IN_ARGS, @OUT_ARGS) is being stored in the context, and that context is defacto the continuation, yes - a tail-call would inherit this information. But as each tail-call supplies a new @ARGS, how can this be the case? We would have two parts in the context: @IN_ARGS, @OUT_ARGS. The Ctailcall opcode can preserve that part with the return context. It seems to me that both @IN_ARGS and @OUT_ARGS get used for other things (the tail-calls' arguments) in a chain of tail-calls. The definition of a tail call is that it returns its callee's results back to its caller unmodified. Agreed, but... So if @OUT_ARGS is used for other things, then it's not a tail call. I don't understand. @OUT_ARGS aren't the arguments returned (to my understanding), they're the arguments to the next function in sequence. My mistake; I had thought @OUT_ARGS meant results. I see I didn't read Leo's original proposal carefully enough, and you were just following his terminology; my apologies. I agree that information about return context can't live in @ARGS (in or out) directly. . . . but the continuation (I propose) does; and this continues to be good for whoever wants to know: the return object holds the return context. No? regards, Roger I believe so, but I think this is what Leo meant by ... that context is defacto the continuation. There doesn't need to be a separate return object because it would be one-to-one with the continuation. Sorry, by return object I was only meaning the continuation; you are quite right. Just using a different term for parallelism with return context, but I see it only introduced confusion. So it sounds like we are all saying the same thing now? -- Bob
Re: Welcome to the land of Subversion
Could that be added as 4th line? Good ideas, all of them. I've updated the page to add that, and to switch to bz2. -R
I wish to understand the JIT machine code generator
I have been trying to examine the i386 code generator to see how feasible it would be to create an AMD64 code generator. Unfortunately, the code is uncommented, and I haven't yet found any documentation to explain how it works on Parrot. So far I've determined there's relevant stuff in jit/i386. I don't understand the .jit extension on core.jit. Is that not actually heavily templated C code? I'm curious if there's other sources to study. Preferably, I'd like to get some advice on how to study this code generator so I can at least improve it. I'd prefer to become knowledgeable enough to add an AMD64 generator sometime. However, I'll gladly advise only if somebody has already started it.
