Platform splitting, mark 2.
OK, here is a new implementation of the same idea. Also, here is a more explicit set of instructions. To install: rm -r platforms untar the attached tarball in the main parrot dir. To use: run Configure.pl, then run GuessConfig. (Merging them is on the todo list.) run make test. Go home happy. Note that some (many) possible methods havn't been written. (Esp. for dynloading.) This is still proof-of-concept stage, largly. -=- James Mastros -- God has both Tea and No Tea -=- SLM platforms.tar.gz Description: Binary data
Re: Butt-ugliness reduction
ason Gloudon [EMAIL PROTECTED] wrote: On Sat, Nov 17, 2001 at 02:22:44PM +, [EMAIL PROTECTED] wrote: Alan Burlison [EMAIL PROTECTED] wrote: Dave Mitchell wrote: * Is there ever any need to for a PMC type which holds both an int and a num? In the Perl 5 case we were constrained by code that expected to always find an int (or a num) in a fixed slot in the SV; with PMCs, all access to these slots is via methods, so an int-num or num-int conversion can be done on the fly. If you use the same value enough times in places where you need an integral value, (an array index, an argument to substr etc), it is faster to cache the int value than converting from double (or BIGFLOAT) every time. The overhead of calling the 'get_int' method of a PMC will probably swamp the float-int conversion time for most processors these days. And not maintaining both values will probably avoid the need for allocating an extra structure to hold the values, and/or the need for flags and if (NoK) ... else if (IoK) .. else ... style code.
Re: Butt-ugliness reduction
Dan Sugalski [EMAIL PROTECTED] wrote: I'm saying that classes can have user-defined flags, to save a dereference. Or at least, I'm saying that until Dan wanders over here and persuades me it's a bad idea. :) Dan thinks its a very good idea. :) Almost anything that potentially saves a dereference's good by me. Presumably we should have a small, *fixed* number of private bits in the flags word available for use by vtable implementors (ie to stop people getting carried away with the notion that they can steal any bits which do not otherwise appear to have been allocated yet ;-)
What happened at little languages?
Can't find any articles or notes on what happened at the conference. What happened? I'm really curious about the Worse is Better panel and the talk that Dan and Simon gave. - Ken
Re: Platform splitting, mark 2.
On Mon, 19 Nov 2001, James Mastros wrote: OK, here is a new implementation of the same idea. Also, here is a more explicit set of instructions. To install: rm -r platforms untar the attached tarball in the main parrot dir. To use: run Configure.pl, then run GuessConfig. (Merging them is on the todo list.) This still doesn't build for me. First, Configure.pl dies because MANIFEST hasn't been corrected to reflect the rm -r platforms command. After fixing that, Configure.pl dies with this message: Alright, now I'm gonna check some stuff by compiling and running another small C program. This could take a bit... ./include/parrot/parrot.h, line 28: cannot find include file: parrot/platform.h cc: acomp failed for testparrotsizes.c C compiler died! at ./Configure.pl line 347. So I fake one up with touch include/parrot/platform.h Then, Configure.pl and GuessConfig run, but make dies with cc -I./include -o core_ops.o -c core_ops.c core_ops.c, line 358: undefined symbol: DEFAULT_OPEN_MODE core_ops.c, line 365: undefined symbol: DEFAULT_OPEN_MODE core_ops.c, line 372: undefined symbol: DEFAULT_OPEN_MODE core_ops.c, line 379: undefined symbol: DEFAULT_OPEN_MODE core_ops.c, line 386: undefined symbol: DEFAULT_OPEN_MODE core_ops.c, line 393: undefined symbol: DEFAULT_OPEN_MODE Next, I copied the old parrot/platforms/generic.h to include/parrot/platform.h. make then died with platform.c, line 3: 0 is invalid in #line directive platform.c, line 21: 0 is invalid in #line directive platform.c, line 35: syntax error before or at: / platform.c, line 35: invalid source character: '#' platform.c, line 35: undefined or not a type: include platform.c, line 35: cannot recover from previous errors Lines 3 and 21 have #line 0 directives. Line 35 is a C++ comment, //. I fixed both of those, and then the link stage died with cc -I./include -o test_prog global_setup.o interpreter.o parrot.o register.o core_ops.o memory.o packfile.o stacks.o string.o encoding.o chartype.o runops_cores.o trace.o vtable_ops.o pmc.o encodings/singlebyte.o encodings/utf8.o encodings/utf16.o encodings/utf32.o chartypes/unicode.o chartypes/usascii.o resources.o platform.o classes/perlint.o classes/perlstring.o classes/perlnum.o test_main.o -lsocket -lnsl -ldl -lm -lc -lcrypt Undefined first referenced symbol in file setenv platform.o Parrot_intval_time core_ops.o unsetenvplatform.o Parrot_floatval_timecore_ops.o Parrot_sleepcore_ops.o ld: fatal: Symbol referencing errors. No output written to test_prog *** Error code 1 That's as far as I've gotten. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Butt-ugliness reduction
On Mon, Nov 19, 2001 at 10:58:55AM +, Dave Mitchell wrote: Presumably we should have a small, *fixed* number of private bits in the flags word available for use by vtable implementors (ie to stop people getting carried away with the notion that they can steal any bits which do not otherwise appear to have been allocated yet ;-) If you look at the way I've done it in the code and the docs, vtable implementors have a macro representing the start of private flags. I've reserved 8 flags, starting the private stuff at 9. If we need to reserve more, we rewrite the macro, and all the vtable stuff should recompile, unless they're using an reasonable number of bits. There will, of course, be warnings and guidelines about what constitutes reasonable in the documentation; in the worst case, they'll have to use the flag structure we provide as fast flags and store a separate flags field in their data structure for less-commonly accessed stuff. -- The best book on programming for the layman is Alice in Wonderland; but that's because it's the best book on anything for the layman. - Alan Perlis
Re: What happened at little languages?
On Mon, Nov 19, 2001 at 09:44:41AM -0500, Ken Fox wrote: Can't find any articles or notes on what happened at the conference. Oh, be fair, I've only just got off a plane. :) Article coming on perl.com this Wednesday or so. -- In this talk, I would like to speculate a little, on ... the development of intelligent life. I shall take this to include the human race, even though much of its behaviour throughout history has been pretty stupid... - Stephen Hawking
Re: Butt-ugliness reduction
Simon Cozens [EMAIL PROTECTED] wrote: On Mon, Nov 19, 2001 at 10:58:55AM +, Dave Mitchell wrote: Presumably we should have a small, *fixed* number of private bits in the flags word available for use by vtable implementors (ie to stop people getting carried away with the notion that they can steal any bits which do not otherwise appear to have been allocated yet ;-) If you look at the way I've done it in the code and the docs, vtable implementors have a macro representing the start of private flags. I've reserved 8 flags, starting the private stuff at 9. If we need to reserve more, we rewrite the macro, and all the vtable stuff should recompile, unless they're using an reasonable number of bits. There will, of course, be warnings and guidelines about what constitutes reasonable in the documentation; in the worst case, they'll have to use the flag structure we provide as fast flags and store a separate flags field in their data structure for less-commonly accessed stuff. Hmmm - of course, once Parrot is out there in the wild with the equivalent of XS vtables, we won't have the luxury of recompiling. I'd prefer the you have 8 private bits, the rest is Parrot's approach rather than the Parrot has 8 bits and the rest is yours for now, we'll let you know when we want to grab some more back off you approach. I think that way, we'll have less backwards compatibility issues for 3rd party code. Just MHO and $0.02's worth :-) Dave.
Re: What happened at little languages?
On Mon, Nov 19, 2001 at 03:17:31PM +, Simon Cozens wrote: Oh, be fair, I've only just got off a plane. :) Executive summary: Us: We're working on this, that and the other. Them: Pshaw. We solved those problems thirty years ago. Us: Yes, but your solutions are unpublished, unadvertised, impossible to comprehend and applied solely to ML or Scheme. Them: So? -- Overall there is a smell of fried onions. (fnord)
Re: What happened at little languages?
Simon Cozens wrote: Us: We're working on this, that and the other. Them: Pshaw. We solved those problems thirty years ago. Were Perl and Python both grouped into the same category of re-inventing the wheel? Or is this just the academic distaste for Perl syntax showing through? I had hoped that the Perl 6 effort, especially Damian's influence, might gain respect for Perl in the academic community. Doesn't sound like it though. What new and interesting things did the Them crowd talk about? - Ken
Re: What happened at little languages?
On Mon, Nov 19, 2001 at 11:55:50AM -0500, Ken Fox wrote: Were Perl and Python both grouped into the same category of re-inventing the wheel? Yes. Or is this just the academic distaste for Perl syntax showing through? Don't forget that Python doesn't have a formally-defined language specification either. I had hoped that the Perl 6 effort, especially Damian's influence, might gain respect for Perl in the academic community. Doesn't sound like it though. It's not all bad. Let's not forget that the conference actually took place, and it was really the first time the academic community and the real-world language implementors got together to chat about stuff. I count that as progress. What new and interesting things did the Them crowd talk about? Oh, the usual, new languages that nobody else is going to use. :) Seriously, if you wait for just a couple of hours, I can finish this article that I'm promising you. Simon -- A few hours later, I'm on the administrative floor, and a secretary asks me about some mail I sent that had [scrambled double-byte characters] in it. While I do use a Japanese-patched Mutt at work, I've never had any instance of it sending scrambled characters, so I went over to her machine to take a look: [...] it was my sendmail.cf - Jonathan Byrne.
Re: What happened at little languages?
On 11/19/01 12:25 PM, Dan Sugalski wrote: Python's got a good shot at things, as it seems to be the 'dirty little secret' of the academic world--it's the practical language people admit to using when they're actually doing something. Sounds familiar... I've reasonably good hope for Ruby, too, but nobody seemed to have heard of it. That's hopefully changed. (I made a point of mentioning it, as it is a really nice language and one of our targets) Or is this just the academic distaste for Perl syntax showing through? Sort of. How academics can dislike Perl's syntax aesthetics and yet like Smalltalk's is beyond me. -John
Re: Butt-ugliness reduction
At 03:29 PM 11/19/2001 +, Dave Mitchell wrote: Hmmm - of course, once Parrot is out there in the wild with the equivalent of XS vtables, we won't have the luxury of recompiling. Then we'll need to abstract that out somehow so we can do it if we need to... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Splitting out platforms
At 03:17 PM 11/16/2001 -0500, Andy Dougherty wrote: I like the idea of splitting out some things (such as dynaloading) into separate directories, instead of a single monolithic platform.c file. Whether *every* non-portable function needs its own directory is a different question. I suspect not, but it's clearly a matter of taste and balance just where to draw the line. That's a good point. The big things (async I/O, dynaloading, and subprocess creation and communication come to mind as biggies) can be taken as separate things rather than treating platforms separately. We'd end up with a mix of per-platform and per-style code, though, so I'm not sure if it'd be a win. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Size of integer register vs sizeof(void *)
On Mon, 2001-11-19 at 12:43, Hong Zhang wrote: Are there any cases where a void * cannot be placed into an integer register? It seems like it shouldn't happen, especially since jump and jsr are supposed to take an integer register and they point to a host-machine-address... What register are you talking about? The 16-bit x86 has 16-bit integer registers, but uses segment:offset as address. So the sizeof(void*) may be 32-bit, plus you have to deal with far, near, huge, ... (total 6 types) of pointers. Hong Sorry: should be size of parrot integer vs sizeof(void *) Should have clarified that :) Brian
Re: Splitting out platforms
On Mon, 19 Nov 2001, Dan Sugalski wrote: At 03:17 PM 11/16/2001 -0500, Andy Dougherty wrote: I like the idea of splitting out some things (such as dynaloading) into separate directories, instead of a single monolithic platform.c file. Whether *every* non-portable function needs its own directory is a different question. I suspect not, but it's clearly a matter of taste and balance just where to draw the line. That's a good point. The big things (async I/O, dynaloading, and subprocess creation and communication come to mind as biggies) can be taken as separate things rather than treating platforms separately. We'd end up with a mix of per-platform and per-style code, though, so I'm not sure if it'd be a win. At least for the Unix-like systems, I think it will be. For example, HP/UX is like most other Unix systems (e.g. sleep, gettimeofday, SysV IPC, sockets, etc.) but has a different dynamic loading scheme. For less Unixy systems, it's less obvious, but I think it will still be a win. However, let's continue to try to think of these files as feature files, not platform files. Thus, it's not whether you're on Linux or OpenBSD or Solaris or Cygwin that matters, it's whether you have a gettimeofday() function. Even for dynaloading, it's still a feature file. It's just that the natural names for the features may include a platform name, e.g. dlopen()-style or HP/UX-style or AIX-style dynamic loading. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: What happened at little languages?
Dan wrote: I've reasonably good hope for Ruby, too, but nobody seemed to have heard of it. That's hopefully changed. (I made a point of mentioning it, as it is a really nice language and one of our targets) Yes, I discovered it a year ago and fell in love with the language, now what it needs is a faster implementation (using a VM and bytecode) and better windows support that is, it needs parrot... Benoit
Re: What happened at little languages?
Where I studied, they liked ML (objective caml actually) and prolog... Benoit - Original Message - From: Dan Sugalski [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Perl 6 Internals [EMAIL PROTECTED] Sent: Monday, November 19, 2001 6:57 PM Subject: Re: What happened at little languages? At 12:35 PM 11/19/2001 -0500, John Siracusa wrote: On 11/19/01 12:25 PM, Dan Sugalski wrote: Or is this just the academic distaste for Perl syntax showing through? Sort of. How academics can dislike Perl's syntax aesthetics and yet like Smalltalk's is beyond me. Wrong crowd. We were at MIT--it was Scheme and Lisp, not Smalltalk. That's a different university... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Tinderbox clients on Mac OS X?
Okay, I've finally gotten the OS disks for the PowerMac that Grant kicked in to the development effort, and we should have an OS X system up and ready to build parrot on. Anyone familiar with setting up Tinderbox under OS X, or Tinderbox clients in general, want to pitch in a bit and help me get the thing set up? Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What happened at little languages?
At 09:29 PM 11/19/2001 +0100, Benoit Cerrina wrote: Dan wrote: I've reasonably good hope for Ruby, too, but nobody seemed to have heard of it. That's hopefully changed. (I made a point of mentioning it, as it is a really nice language and one of our targets) Yes, I discovered it a year ago and fell in love with the language, now what it needs is a faster implementation (using a VM and bytecode) and better windows support that is, it needs parrot... And I'll be happy for us to provide it. :) I rather like Ruby. It seems a nice language. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Butt-ugliness reduction
[EMAIL PROTECTED] wrote: There is. You can't necessarily convert on the fly - perl5 allows dual-typed SVs where the string and number aren't necessarily interchangable versions of each other. Ahem, I was asking about int and num, not num and string :-) Oops - so you were. Soz! -- Alan Burlison -- $ head -1 /dev/bollocks visioneer 24/365 niches
Re: Size of integer register vs sizeof(void *)
Segher Boessenkool wrote: Are there any cases where a void * cannot be placed into an integer register? It seems like it shouldn't happen, especially since jump and jsr are supposed to take an integer register and they point to a host-machine-address... Yes, all platforms that support LP64, i.e. virtually all 64-bit address space platforms. Sparc is just one example. -- Alan Burlison -- $ head -1 /dev/bollocks refactor service-led meta-services, going forwards
sizeof(INTVAL), sizeof(void*), sizeof(opcode_t)
Hey all. In parellel to splitting out features (yeah, I like that better then platforms too) (which is going well this time, I think (I'm being a lot better about checking against clean checkouts, but having problems thinking of a good generic interface for open() and friends), I'm thinking about a new packfile format. I'm comeing across a common problem to both of them. That is, that the sizeof things don't come in nice easy units. In byteswapping the bytecode, it's a Very Good Thing if you can just treat it as an array of some specifc type, so you don't have to figure out how man args each opcode takes (this may, in fact, be impossible, if oplibs are dynamicly loadable during the bytecode's runtime). In the feature-splitting, for example in file opening, some interfaces (POSIX open(), for example) want to return an integer (the fd), and some (win32 CreateFile(), for example) want to return a void* (the file handle). (This is a pointer to a kernel-allocated structure that will cause a segfault to directly access, BTW, so no GC problems here.) I propose that we make INTVAL and opcode_t the same size, and gaurrenteed to be able to hold a void*. -=-- James Mastros -- Put bin Laden out like a bad cigar: http://www.fieler.com/terror You know what happens when you bomb Afghanastan? Thats right, you knock over the rubble. -=- SLM
Re: [perl6]Tinderbox clients on Mac OS X?
I am familiar with both being an OS X user and the tinderbox client author and would be happy to help in any way needed. Zach On 11/19/01 2:11 PM, Dan Sugalski [EMAIL PROTECTED] wrote: Okay, I've finally gotten the OS disks for the PowerMac that Grant kicked in to the development effort, and we should have an OS X system up and ready to build parrot on. Anyone familiar with setting up Tinderbox under OS X, or Tinderbox clients in general, want to pitch in a bit and help me get the thing set up? Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: sizeof(INTVAL), sizeof(void*), sizeof(opcode_t)
On Mon, 2001-11-19 at 19:59, James Mastros wrote: Hey all. In parellel to splitting out features (yeah, I like that better then platforms too) (which is going well this time, I think (I'm being a lot better about checking against clean checkouts, but having problems thinking of a good generic interface for open() and friends), I'm thinking about a new packfile format. I'm comeing across a common problem to both of them. That is, that the sizeof things don't come in nice easy units. In byteswapping the bytecode, it's a Very Good Thing if you can just treat it as an array of some specifc type, so you don't have to figure out how man args each opcode takes (this may, in fact, be impossible, if oplibs are dynamicly loadable during the bytecode's runtime). In the feature-splitting, for example in file opening, some interfaces (POSIX open(), for example) want to return an integer (the fd), and some (win32 CreateFile(), for example) want to return a void* (the file handle). (This is a pointer to a kernel-allocated structure that will cause a segfault to directly access, BTW, so no GC problems here.) I propose that we make INTVAL and opcode_t the same size, and gaurrenteed to be able to hold a void*. Seems reasonable to me, since jsr and jump are slated to use an I register to jump to a host-machine-address and start interpreting there. Brian
