Re: [perl #30395] [PATCH] win32 stat.h
Dennis Rieks <[EMAIL PROTECTED]> wrote: > add this lines to config/gen/platform/generic/stat.h > I think that no win32/stat.[c|h] file is needed, I checked it in as config/gen/platform/win32/stat.h, which then gets included for win32. I'd like to keep things separate. leo
Re: [perl #30397] [PATCH] Document more spots that require perl 5.6
Andy Dougherty <[EMAIL PROTECTED]> wrote: > There are a variety of places in the languages/ directory that require > at least perl 5.006. This patch puts in 'require 5.006' in those files. > If we later decide to make everything work with 5.005, these will at least > mark some of the problem spots. In the meantime, you at least get more > meaningful error messages. Thanks, applied. leo
[perl #30401] [PATCH] win32 building fix (libnci.dll)
# New Ticket Created by Dennis Rieks
# Please include the string: [perl #30401]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=30401 >
Hi,
with this patch (and my previous stat.h patch) win32/vc6 compile, link and
test now successfully (with system icu). See starshadow tinderbox log for
more information.
modified file:
config/gen/makefiles/root.in
chanced nci_test.c to nci_test$(O)
(this prevents an link error while creating libnci.dll)
Dennis
--
Dennis Rieks
[EMAIL PROTECTED]
--- parrot.current/config/gen/makefiles/root.in 2004-06-20 10:10:28.0 +0200
+++ parrot.drieks/config/gen/makefiles/root.in 2004-06-22 03:09:12.0 +0200
@@ -1173,9 +1173,9 @@
## OS depend targets ##
# libnci.so used by t/pmc/nci.t
-$(LIBNCI_SO): $(SRC)/nci_test.c
+$(LIBNCI_SO): $(SRC)/nci_test$(O)
$(LD) $(LD_SHARED) ${ncilib_link_extra} $(LDFLAGS) \
- $(LD_OUT)$@ $(SRC)/nci_test.c
+ $(LD_OUT)$@ $(SRC)/nci_test$(O)
# vim ctags
# this needs exuberant-ctags
Re: The Pie-thon benchmark
On Mon, 21 Jun 2004, Gregor N. Purdy wrote: > So, where and when is the pie-throwing going to happen, precisely? > > IIRC, its at OSCON, but last time i googled for it, I didn't see > mention of which OSCON session or BOF it would be at The plan, last I knew, was to run the benchmarks at some point in the conference and announce the results (and deliver the pie) at the Python lightning talk session. While there'll potentially be much bragging (amongst other things :) about the results, it's not exactly exciting watching two people hit return three times in front of a roomful of people. > Dan Sugalski wrote: > > Since this is getting worked on now, I figured I'd post the benchmark URL > > for anyone who might be interested: > > > > ftp://python.org/pub/python/parrotbench/parrotbench.tgz > > > > It's pretty evil, and there's a chunk of "let's exercise python's builtins > > just because" code in there. > > > > Worth taking a look at, as we may well enlist the aid of the list to get > > some of those built-in functions working. (Which will be cool, since it'll > > mean a push to get a chunk of extra, useful functionality in) > > > > Dan > > > > --"it's like this"--- > > Dan Sugalski even samurai > > [EMAIL PROTECTED] have teddy bears and even > > teddy bears get drunk > > > Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #30395] [PATCH] win32 stat.h
On Tue, 22 Jun 2004, Leopold Toetsch wrote: > Dennis Rieks <[EMAIL PROTECTED]> wrote: > > > add this lines to config/gen/platform/generic/stat.h > > > I think that no win32/stat.[c|h] file is needed, > > I checked it in as config/gen/platform/win32/stat.h, which then gets > included for win32. I'd like to keep things separate. It's a minor thing, but I wouldn't think of this as separate. Or, more accurately, I wouldn't think of it as win32-platform-specific. It came (ultimately) from perl4's perl.h file, where it was written to supply the S_IS* macros on any system where they weren't already supplied. There were, at the time, a number of such Unix-ish systems. Because the fix was put in a generic file that tested for the specific needed feature, and not for one of the problematic platforms, it also "just worked" when win32 cam along, and will probably "just work" anywhere else that doesn't implement the S_IS* macros. For this case, I don't know if it matters much -- I don't know if there are other platforms that don't define those macros -- but the general principle of testing for features, not for platforms, is a good one and I like to jump up on my soapbox and ramble on about it at every opportunity :-). -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #30401] [PATCH] win32 building fix (libnci.dll)
Dennis Rieks <[EMAIL PROTECTED]> wrote: > with this patch (and my previous stat.h patch) win32/vc6 compile, link and > test now successfully (with system icu). See starshadow tinderbox log for > more information. Thanks, applied. leo
Q: exception objects
Pie-thon has Exception objects. We'll need such beasts too. So: 1) How do we "translate" Python classes? Properties only? Or full ParrotClass objects? 2) We'll need to classify our exceptions somehow so that we can model an exception class hierarchy. We'll also need to catch specific exceptions properly so that: # from b1.py - pseudo code try: n = self.P0(n+1) # recursive except RuntimeError: # pass return n can catch specific exceptions. Comments welcome. leo
Re: Q: exception objects
On Tue, 22 Jun 2004, Leopold Toetsch wrote: > Pie-thon has Exception objects. We'll need such beasts too. So: > 1) How do we "translate" Python classes? Properties only? Or > full ParrotClass objects? I think ParrotClass objects with properties should work fine. Python objects are also referred to by reference, which we need to deal with. > 2) We'll need to classify our exceptions somehow so that we can model an > exception class hierarchy. Exceptions have always been spec'd out to have language/type/subtype attached to them, though we've not implemented that. I think it's time to do so. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[CVS ci] Pie-thon 1 - recursion limit
b1.py calls recursively functions, the depth is limited by the interpreter, which throws a RuntimeException at recursion depth 1000. So does Parrot now. The limit can be change by: $P0 = getinterp .local int new_limit .local int old_limit new_limit = 4711 old_limit = $P0."recursion_limit"(new_limit) leo
Re: [perl #30395] [PATCH] win32 stat.h
Andy Dougherty <[EMAIL PROTECTED]> wrote: > For this case, I don't know if it matters much -- I don't know if there > are other platforms that don't define those macros -- but the general > principle of testing for features, not for platforms, is a good one and I > like to jump up on my soapbox and ramble on about it at every > opportunity :-). I'd say, if we find more platforms that need it, we move it into generic. leo
Re: [CVS ci] Pie-thon 1 - recursion limit
On Tue, 22 Jun 2004, Leopold Toetsch wrote: > b1.py calls recursively functions, the depth is limited by the > interpreter, which throws a RuntimeException at recursion depth 1000. So > does Parrot now. > > The limit can be change by: > >$P0 = getinterp >.local int new_limit >.local int old_limit >new_limit = 4711 >old_limit = $P0."recursion_limit"(new_limit) That's fine. We should add this (and anything else we do this way) to the interpinfo op so the values can be fetched back out, both by bytecode and via the interpinfo call for C code.. I'm tempted to have a special op for setting interpreter values rather than rely on methods, since this is all very low level, and likely to be set via C code. (Where method calls into parrot are a bit of a pain) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #30395] [PATCH] win32 stat.h
On Tue, 22 Jun 2004, Leopold Toetsch wrote: > Andy Dougherty <[EMAIL PROTECTED]> wrote: > > > For this case, I don't know if it matters much -- I don't know if there > > are other platforms that don't define those macros -- but the general > > principle of testing for features, not for platforms, is a good one and I > > like to jump up on my soapbox and ramble on about it at every > > opportunity :-). > > I'd say, if we find more platforms that need it, we move it into > generic. Given that we already know this is going to be an issue (since perl 5's already hit it) it seems a bit counterproductive to put this off until later. We know later's going to come, so we might as well get it out of the way now. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Q: class name hashes
We currently seem to have two different hashes for storing class names: one for PMC base classes and one for dynamic PMCs and objects. I think both should use just interpreter->class_hash. OTOH putting PMC names into this one hash makes it more likely that we get name collisions for user class names. We should be able to subclass PMCs as real objects. b3.py seems to do something like: # class TT(T): getclass $P0, "Integer" # Integer PMC class, Python: "int" class subclass $P1, $P0, "TT" # subclass the PMC Then it redefines the "__repr__" method, which we BTW don't have. Using "get_string" instead could be a problem. Seems that we need a C vtable, which gets called when printing PMCs. Comments welcome, leo
Re: Q: class name hashes
On Tue, 22 Jun 2004, Leopold Toetsch wrote: > We currently seem to have two different hashes for storing class names: > one for PMC base classes and one for dynamic PMCs and objects. > > I think both should use just interpreter->class_hash. OTOH putting PMC > names into this one hash makes it more likely that we get name > collisions for user class names. Yeah. We probably ought to go rename the PMC classes to have Parrot prefixes. > We should be able to subclass PMCs as real objects. Yep. We need to reserve a bit in the pmc flag word for delegated pmcs too, but that's a semi-separate issue. > b3.py seems to do something like: > # class TT(T): > getclass $P0, "Integer" # Integer PMC class, Python: "int" class > subclass $P1, $P0, "TT" # subclass the PMC > > Then it redefines the "__repr__" method, which we BTW don't have. Using > "get_string" instead could be a problem. Seems that we need a C > vtable, which gets called when printing PMCs. We don't need a __repr__ method. That's just an alternate freeze format. (Arguably we need a parameter to freeze to note which format to use) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [CVS ci] Pie-thon 1 - recursion limit
Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Tue, 22 Jun 2004, Leopold Toetsch wrote: >>old_limit = $P0."recursion_limit"(new_limit) > That's fine. We should add this (and anything else we do this way) to the > interpinfo op so the values can be fetched back out, both by bytecode and > via the interpinfo call for C code.. I'm tempted to have a special op for > setting interpreter values rather than rely on methods, since this is all > very low level, and likely to be set via C code. (Where method calls into > parrot are a bit of a pain) I think that this won't get used heavily. Anyway for this case, we can integrate it into C or some such. OTOH we probably need to support a method interface for a lot more things. b3.py has stuff like: TT.__cmp = Integer.__cmp, where TT is a ParrotClass and Integer isa PMC. > Dan leo
Re: [CVS ci] Pie-thon 1 - recursion limit
On Tue, 22 Jun 2004, Leopold Toetsch wrote: > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > On Tue, 22 Jun 2004, Leopold Toetsch wrote: > > >>old_limit = $P0."recursion_limit"(new_limit) > > > That's fine. We should add this (and anything else we do this way) to the > > interpinfo op so the values can be fetched back out, both by bytecode and > > via the interpinfo call for C code.. I'm tempted to have a special op for > > setting interpreter values rather than rely on methods, since this is all > > very low level, and likely to be set via C code. (Where method calls into > > parrot are a bit of a pain) > > I think that this won't get used heavily. Anyway for this case, we can > integrate it into C or some such. It won't be heavily used, certainly, but it will get used by folks doing embedded work. (They're the most likely users of this stuff, really) > OTOH we probably need to support a method interface for a lot more > things. b3.py has stuff like: TT.__cmp = Integer.__cmp, where TT is a > ParrotClass and Integer isa PMC. The current method interface for this sort of thing's fine. We may want to jump through some hoops with default MMD dispatch for some of these things (which is what the above code does -- __cmp gets mapped to one of the cmp slots) as it'll get... fun, but shouldn't be too big a deal. The underlying python bytecode doesn't make method calls by default for __cmp and friends unless they're overridden. (Which they are there, of course, but...) A standard left-side-wins scheme with operator overloading's in place for 'em. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
parrot interpreter on vxWorks?
my company would just love to embed the interpreter part of parrot into it's product (mtx603) that runs vxWorks. I'm trying to figure out if this is doable. I google'd the perl6-internals list but there's nary a mention of vxWorks. a 'grep fork *.c' in the parrot source code shows fork to occur only in platform.c. Although malloc-trace.c does some checking of pid's which could indicate forking. I haven't quite figured out how to get the interpreter to be standalone, I'm assuming it's possible though - right? any thoughts or ideas on this? greg strockbine
Re: parrot interpreter on vxWorks?
On Tue, 22 Jun 2004, greg strockbine wrote: > my company would just love to embed > the interpreter part of parrot into it's > product (mtx603) that runs vxWorks. Woohoo! That'd be cool. > I'm trying to figure out if this is doable. > I google'd the perl6-internals list but > there's nary a mention of vxWorks. Mainly because nobody on-list's got any experience with it. :) At least not that I'm aware of. > a 'grep fork *.c' in the parrot source code > shows fork to occur only in platform.c. > Although malloc-trace.c does some checking > of pid's which could indicate forking. The only place Parrot forks is in the fork op which, as you've noted, is in the platform-specific code. (Since Windows, amongst other OSes, doesn't fork) You'd need to build up the right config.h and platform.[ch] files for vxWorks, but that shouldn't be a huge problem. I'll warn you that we're not really set up for cross-compilation. OTOH, I'd *love* it if we were, so it might take a bit of work but I think it'd be doable. > I haven't quite figured out how to get the > interpreter to be standalone, I'm assuming it's > possible though - right? Depends on what you mean by standalone, I suppose. (Not that we shouldn't be able to regardless of the definition. More a question of whether we can right now or not) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #30349] [PATCH] Fix Win32 building part 1
On Friday 18 June 2004 03:56, Jonathan Worthington wrote: > # New Ticket Created by Jonathan Worthington > # Please include the string: [perl #30349] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org:80/rt3/Ticket/Display.html?id=30349 > > > > Hi, > > The attached one-line patch sorts out something that stopped ICU build > working on Win32 with Visual Studio 6.0. Sorry I missed it last time round > and that it's taken me so long to get back to it. I replaced your xcopy icu\source\common icu\include command with this one: xcopy /E /I icu\source\common\unicode icu\include\unicode Only the unicode folder is needed, and my buildhost version of xcopy asks "is the target an file or directory", with stops the automatic build process until i respones to this question... (But this may be an problem with differences between my German and yours version of xcopy, i have no other version to verify this) At least for me this command works better than yours one. > Thanks, > > Jonathan Dennis -- Dennis Rieks [EMAIL PROTECTED] Index: icu.pl === RCS file: /cvs/public/parrot/config/gen/icu.pl,v retrieving revision 1.15 diff -u -w -b -r1.15 icu.pl --- icu.pl 19 Jun 2004 13:08:21 - 1.15 +++ icu.pl 22 Jun 2004 23:03:28 - @@ -147,7 +147,7 @@ msdev icu\source\allinone\allinone.dsw /MAKE "stubdata - Win32 Debug" msdev icu\source\allinone\allinone.dsw /MAKE "common - Win32 Debug" msdev icu\source\allinone\allinone.dsw /MAKE "i18n - Win32 Debug" - xcopy icu\source\common icu\include + xcopy /E /I icu\source\common\unicode icu\include\unicode msdev icu\source\allinone\allinone.dsw /MAKE "ctestfw - Win32 Debug" msdev icu\source\allinone\allinone.dsw /MAKE "decmn - Win32 Debug" msdev icu\source\allinone\allinone.dsw /MAKE "gencmn - Win32 Debug"
[perl #30414] [PATCH] make realclean and .cvsignore fixes
# New Ticket Created by Dennis Rieks # Please include the string: [perl #30414] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=30414 > Hi, added just some missing files cvsignore.patch: RCS file: /cvs/public/parrot/.cvsignore,v -added test.[c,o,cco,ilk,ldo,out,pdb] and vc60.pdb cola_cvsignore.patch: RCS file: /cvs/public/parrot/languages/cola/.cvsignore,v -added Makefile .cvsignore: new file parrot/languages/parrot_compiler/.cvsignore (added Makefile) root.in.patch: RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v -added to GEN_MAKEFILES dynclasses/Makefile dynoplibs/Makefile languages/cola/Makefile -added to GEN_CONFIGS include/parrot/exec_dep.h ops/core_ops.c ops/core_ops_prederef.c ops/core_ops_switch.c test test.c test.o test.cco test.ilk test.ldo test.out test.pdb vc60.pdb config_lib.pasm $(SRC)/nci_test$(O) -chanced progclean: $(DYNEXT_DIR)/$(LIBNCI_SO) to $(LIBNCI_SO) Dennis -- Dennis Rieks [EMAIL PROTECTED] Index: .cvsignore === RCS file: /cvs/public/parrot/.cvsignore,v retrieving revision 1.33 diff -u -w -b -r1.33 .cvsignore --- .cvsignore 4 May 2004 12:55:18 - 1.33 +++ .cvsignore 22 Jun 2004 20:52:57 - @@ -7,6 +7,14 @@ *.patch *.tmp test +test.c +test.o +test.cco +test.ilk +test.ldo +test.out +test.pdb +vc60.pdb CFLAGS disassemble pbc_info Index: languages/cola/.cvsignore === RCS file: /cvs/public/parrot/languages/cola/.cvsignore,v retrieving revision 1.1 diff -u -w -b -r1.1 .cvsignore --- languages/cola/.cvsignore 11 Aug 2003 22:53:31 - 1.1 +++ languages/cola/.cvsignore 22 Jun 2004 20:53:01 - @@ -5,3 +5,4 @@ a.pasm colacc imcc \ No newline at end of file +Makefile Makefile Index: config/gen/makefiles/root.in === RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v retrieving revision 1.223 diff -u -w -r1.223 root.in --- config/gen/makefiles/root.in22 Jun 2004 13:13:50 - 1.223 +++ config/gen/makefiles/root.in22 Jun 2004 21:37:34 - @@ -90,6 +90,9 @@ Makefile \ languages/Makefile \ docs/Makefile \ +dynclasses/Makefile \ +dynoplibs/Makefile \ +languages/cola/Makefile \ languages/parrot_compiler/Makefile \ languages/jako/Makefile \ languages/miniperl/Makefile \ @@ -111,6 +114,10 @@ include/parrot/has_header.h \ include/parrot/feature.h \ include/parrot/core_pmcs.h \ +include/parrot/exec_dep.h \ +ops/core_ops.c \ +ops/core_ops_prederef.c \ +ops/core_ops_switch.c \ lib/Parrot/Config.pm \ lib/Parrot/PMC.pm \ runtime/parrot/include/config.fpmc \ @@ -118,6 +125,17 @@ #CONDITIONED_LINE(platform_asm):$(SRC)/platform_asm.s \ $(SRC)/core_pmcs.c \ CFLAGS imcc/CFLAGS \ +test \ +test.c \ +test.o \ +test.cco \ +test.ilk \ +test.ldo \ +test.out \ +test.pdb \ +vc60.pdb \ +config_lib.pasm \ + $(SRC)/nci_test$(O) \ libparrot.def # most of these are generated by config/gen/parrot_include.pl @@ -1056,7 +1074,7 @@ $(SRC)/pbc_info$(O) $(PINFO) \ $(PDB) $(SRC)/pdb$(O) \ $(DIS) $(SRC)/disassemble$(O) \ -$(DYNEXT_DIR)/$(LIBNCI_SO) +$(LIBNCI_SO) $(RM_F) $(LIBPARROT) $(PERL) build_tools/c2str.pl --init $(RM_F) $(STR_FILES) $(INC)/string_private_cstring.h
Re: Q: class name hashes
Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Tue, 22 Jun 2004, Leopold Toetsch wrote: >> I think both should use just interpreter->class_hash. OTOH putting PMC >> names into this one hash makes it more likely that we get name >> collisions for user class names. > Yeah. We probably ought to go rename the PMC classes to have Parrot > prefixes. Ack. But ParrotResizableIntegerArray :( > We don't need a __repr__ method. That's just an alternate freeze format. > (Arguably we need a parameter to freeze to note which format to use) I beg to differ. __repr__ is too universally used in Python. It's a distinct method. A different freeze format is of course doable, but overriding the C vtable method make this implementation a PITA. > Dan leo
Re: cvs commit: parrot/src call_list.txt
Nicholas Clark <[EMAIL PROTECTED]> wrote: > More NCI definitions needed to make things pass on OS X. Thanks. I really shouldn't forget to update call_list.txt. leo
Re: cvs commit: parrot/src call_list.txt
On Tue, 2004-06-22 at 11:03, Leopold Toetsch wrote: > > More NCI definitions needed to make things pass on OS X. > Thanks. I really shouldn't forget to update call_list.txt. Would figuring out how to make the PPC JIT set up NCI calls help with that? Not particularly volunteering, just asking. -- c
