[RFT] File Spec
Here is a new variant of File Spec for the Parrot internals. I've changed implementation. Made some alternations concerning with function names. catdir and catfile have become concat_dirnames and append_filename respectively. Now it will work properly on Windows, UNIX, VMS, Mac, cygwin, and OS/2(?), I believe. If you doesn't find your OS on the above-mentioned list, let me know. Below I'm laying out the semantics of curdir, concat_dirnames, and append_filename which File Spec is being consistent with. It would be great if you examined that on whether those functions do the Right Thing relative to your OS. Also at the moment the patch works fine for MSVC, though I'd like to know what the other compilers think about it. UNIX, cygwin, OS/2 curdir() = . concat_dirnames(, ) = concat_dirnames(null, ) = concat_dirnames(, null) = concat_dirnames(null, null) = concat_dirnames(., ) = . concat_dirnames(, .) = . concat_dirnames(., .) = . concat_dirnames(a, ) = a concat_dirnames(, b) = b concat_dirnames(a, .) = a concat_dirnames(., b) = b concat_dirnames(a, b) = a/b concat_dirnames(a/b, c) = a/b/c append_filename(, ) = append_filename(null, ) = append_filename(, null) = append_filename(null, null) = append_filename(., ) = append_filename(a, ) = append_filename(a, b) = a/b MS Win32 == curdir() = . concat_dirnames(, ) = concat_dirnames(null, ) = concat_dirnames(, null) = concat_dirnames(null, null) = concat_dirnames(., ) = . concat_dirnames(, .) = . concat_dirnames(., .) = . concat_dirnames(a, ) = a concat_dirnames(, b) = b concat_dirnames(a, .) = a concat_dirnames(., b) = b concat_dirnames(a, b) = a\b concat_dirnames(a\b, c) = a\b\c append_filename(, ) = append_filename(null, ) = append_filename(, null) = append_filename(null, null) = append_filename(., ) = append_filename(a, ) = append_filename(a, b) = a\b VMS = curdir() = [] concat_dirnames(, ) = concat_dirnames(null, ) = concat_dirnames(, null) = concat_dirnames(null, null) = concat_dirnames([], ) = [] concat_dirnames(, []) = [] concat_dirnames([], []) = [] concat_dirnames(a, ) = [a] concat_dirnames(, b) = [b] concat_dirnames(a, []) = [a] concat_dirnames([], b) = [b] concat_dirnames(a, b) = [a.b] concat_dirnames([a.b], c) = [a.b.c] append_filename(, ) = append_filename(null, ) = append_filename(, null) = append_filename(null, null) = append_filename([], ) = append_filename([a], ) = append_filename([a], b) = [a]b Mac = curdir() = : concat_dirnames(, ) = concat_dirnames(null, ) = concat_dirnames(, null) = concat_dirnames(null, null) = concat_dirnames(:, ) = : concat_dirnames(, :) = : concat_dirnames(:, :) = : concat_dirnames(a, ) = :a concat_dirnames(, b) = :b concat_dirnames(a, :) = :a concat_dirnames(:, b) = :b concat_dirnames(a, b) = :a:b concat_dirnames(:a:b, :c) = :a:b:c append_filename(, ) = append_filename(null, ) = append_filename(, null) = append_filename(null, null) = append_filename(:, ) = append_filename(:a, ) = append_filename(:a, b) = :a:b file_spec.diff Description: Binary data
Happy Anniversary, Parrot
Has it been two years already? -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: [RFT] File Spec
On Thu, Sep 11, 2003 at 10:23:27AM +0300, Vladimir Lipskiy wrote: Unix et al == append_filename(., ) = Shouldn't that be .? append_filename(a, ) = a append_filename(a, b) = a/b What about append_filename(, b) ? Would that be an error? Don't forget absolute paths concat_dirnames(/foo, /bar) = error? concat_dirnames(foo, /bar) = error? concat_dirnames(/foo, bar) = /foo/bar MS Win32 == append_filename(., ) = . append_filename(a, ) = a? What about volumes? concat_dirnames(C:\foo, bar) = C:\foo\bar concat_dirnames(C:\foo, C:\bar) = error? concat_dirnames(foo, C:\bar) = error? VMS = append_filename(, ) = append_filename(null, ) = append_filename(, null) = append_filename(null, null) = append_filename([], ) = Ditto. append_filename([a], ) = [a] Same caveats about volumes. Mac = Is Parrot really targetting MacOS Classic? PS I'd forward this bit to [EMAIL PROTECTED] concat_dirnames(, ) = concat_dirnames(null, ) = concat_dirnames(, null) = concat_dirnames(null, null) = concat_dirnames(:, ) = : concat_dirnames(, :) = : concat_dirnames(:, :) = : concat_dirnames(a, ) = :a concat_dirnames(, b) = :b concat_dirnames(a, :) = :a concat_dirnames(:, b) = :b concat_dirnames(a, b) = :a:b concat_dirnames(:a:b, :c) = :a:b:c append_filename(, ) = append_filename(null, ) = append_filename(, null) = append_filename(null, null) = append_filename(:, ) = append_filename(:a, ) = append_filename(:a, b) = :a:b -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ I do have a cause though. It is obscenity. I'm for it. -- Tom Lehrer Smut
Re: [RFT] File Spec
On Thu, Sep 11, 2003 at 01:17:29PM +0300, Vladimir Lipskiy wrote: Shouldn't that be .? append_filename(a, ) = a Umm. Don't think so. At least it will be that way until you convince me that it must be another way concat_dirnames(a, ) = a concat_dirnames(, b)= b ergo append_filename(a, ) = a Why wouldn't appending no filename onto a directory result in the directory being returned? Unless append_filename() guarantees that it will always return a filepath ending in a filename? What about append_filename(, b) ? Would that be an error? No. It's okay. I just forgot to mention that case. append_filename(, b) will produce b Now wait a second. append_filename(a, ) produces nothing but append_filename(, b) produces a filename? Isn't that a little inconsistent? concat_dirnames(/foo, /bar) = error? concat_dirnames(foo, /bar) = error? concat_dirnames(/foo, bar) = /foo/bar I just want to remind you the Leo's words: Please keep in mind, that the intended usage inside Parrot just should be to locate some standard include or extension files for Parrot internals. More abstraction and complexity can always be added above that or implemented by HLLs. -- Him.(~:) I don't suppose Leo will be pass in spoiled data. Famous last words: Our data is perfect, we don't need to check our inputs. What about volumes? I plan a special functions for volumes, and nodes, and root dirs like prepend_volume, prepend_node, prepend_rootdir. For example, prepend_rootdir could throw the prepend_rootdir is unsupported on this platform exception on windows. Of course, I will go implement those if Parrot needs those. Ok, but what happens when I pass filepaths with volumes attached to concat_dirnames? What if the volumes don't match? What if I'm adding a path with a volume to one without? -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Death? Its like being on holiday with a group of Germans.
Re: Missing Ops
Dan Sugalski [EMAIL PROTECTED] wrote: For us, teh equivalent would be returning a PerlInt if we find the result produces an integral value, and a PerlNum if it doesn't. (Assuming, of course, that the operation took place on two perl-style PMCs, as other languages may have different rules on what happens) Ok. Most done. (PerlNum) 4.2+2.8 gives PerlInt 7 now. Dan leo
Re: Of AST and YAL
Leopold Toetsch [EMAIL PROTECTED] wrote: I'm currently investigating the AST (abstract syntax tree) interface for Parrot. For getting a feeling, how this could look like, I've implemented (some parts) of Yet Another Language (YAL). I have put version yal-0.02 on my webpage. You can get it at: http://toetsch.at/yal/ http://toetsch.at/yal/yal-0.02.tgz Have fun comments welcome, leo
Re: [PATCH] Small test case exception for ponie
Arthur Bergman [EMAIL PROTECTED] wrote: Aha, that explains it, I assumed that genclass produced something that was correct, apparently it didn't :), fixed now and I withdraw my patch. Ah, that explains it too. Sorry. Fixed genclass.pl - thanks. (I'm almost always takint an existing similar PMC and generate a new one out from that ;) Arthur leo
Re: [RFT] File Spec
Michael G Schwern [EMAIL PROTECTED] wrote:
Why wouldn't appending no filename onto a directory result in the
directory
being returned? Unless append_filename() guarantees that it will always
return a filepath ending in a filename?
Yes. And it guarantees to return a , when you do something that
it treats as wrong in it's point of view.
append_filename(, b) will produce b
Now wait a second. append_filename(a, ) produces nothing but
append_filename(, b) produces a filename? Isn't that a little
inconsistent?
No, it isn't. In the first case it returns being standing for to
indicate an error situation. In the second case,
append_filename(, b) will give you :b on Mac.
It does sense, when you want to get a relative filepath which is
a route to the file b in the current directory.
Famous last words: Our data is perfect, we don't need to check our
inputs.
Yes. Our data is perfect and we don't need to check our inputs if we
play by rules. And the rules are:
Always use concat_dirnames to concatenate directory names
Always use append_filename to append a file name to a path
Always keep in mind that this tool gives you a proper result
when you give it proper input, which is simple directory
names, simple file names, and paths produced by this tool only.
If you observe the rules, you won't get into a mess.
Ok, but what happens when I pass filepaths with volumes attached to
concat_dirnames?
You get what you do, nonsense. Even File::Spec, a tool of a lot more
higher level, doesn't protect you from such things.
D:\perl -MFile::Spec::Functions -e print catdir('C:\hh','C:\dd'), qq(\n)
C:\hh\C:\dd
What if the volumes don't match?
Don't match against what? concat_dirnames doesn't do matching arguments
against anything but PARROT_FS_DIRNAME_START and PARROT_FS_DIRNAME_END,
which, for example, are '[' and ']' on VMS.
What if I'm adding a path with a volume to one without?
Still. You get what you do. On Mac:
concat_dirnames('my disk:a', ':b') = ':my disk:a:b'
File::Spec has an individual function for such purposes, catpath().
We can't process more than two in-arguments in PASM, so we would take
advantage of prepend_volume and things of such sort.
[PATH] Get rid of very annoying header warnings on darwin
Hi, This gets rid of the very annoying long double might change warning under darwin, the warning comes from my config.h which has typedef long double HUGEFLOATVAL; Arthur Index: config/init/hints/darwin.pl === RCS file: /cvs/public/parrot/config/init/hints/darwin.pl,v retrieving revision 1.6 diff -u -r1.6 darwin.pl --- config/init/hints/darwin.pl 7 Jun 2002 19:21:17 - 1.6 +++ config/init/hints/darwin.pl 11 Sep 2003 14:38:57 - @@ -1,6 +1,6 @@ my($ccflags, $ldflags)=Configure::Data-get(qw(ccflags ldflags)); -$ccflags .= -pipe -fno-common ; +$ccflags .= -pipe -fno-common -Wno-long-double ; $ccflags =~ s/-flat_namespace\s*//; $ldflags =~ s/-flat_namespace\s*//; $ldflags .= -flat_namespace ;
Re: [RFT] File Spec
On Thursday, September 11, 2003, at 10:36 AM, Vladimir Lipskiy wrote: If you observe the rules, you won't get into a mess. I'm not convinced If you don't have users, you won't get into a mess is a workable design goal for library code. -- c
Re: Moving imcc ...
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski wrote: On Mon, 8 Sep 2003, Leopold Toetsch wrote: Imcc is still lacking full integration inside Parrot. To accomplish this, we would need these steps: - rebuild and commit directory structure $Parrot_Root/imcc - move files from languages/imcc to ../imcc [1] - adapt Makefiles - include imcc source files except main.c into libparrot Almost. IMCC's getting integrated with Parrot. All the core sources should be in one spot, so either move the current top-level C code to core/ and put the IMCC stuff in there as well (in core/ directly, not core/imcc/) or move all the IMCC files to the top level directory (with the header files in include/parrot) Could be done too (with some file renaming i.e. jit.c) but imcc has its own test structure and its own TestCompiler.pm. OTOH pd07 has something about subsystem - they should be separate. As imcc is the assembler/compiler subsystem I'd rather have it in a separate directory. I think the same way. Imcc is a seperate subsystem. Clobbering the root of the source directory is not good, and moving everything to core/ neither. In the long term more code from the root directory should move to subsystems like packfile, mem etc. Furthermore the *.h should not get blindly copied to include/parrot, some of the imcc header-files are private to the imcc subsystem (like imcparser.h). These files should stay in the subsystem directory. PDD07 calls them *_private.h. ... The makefile needs to be integrated into the top-level makefile. (Again, in the top-level. I don't want a separate makefile for IMCC) Nor do I. io is also a subsystem, but the build is controlled by the root-makefile. There's not much reason to have IMCC split out, so I'd rather not. pdd07, file name clashes, t/* bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Win32 Build Issues (was Re: Linking pdump and dissassemble)
Vladimir Lipskiy [EMAIL PROTECTED] writes:
static INTVAL
PIO_win32_getblksize(PIOHANDLE fd)
{
those indentifiers had internal linkage. Bi-bi. Fixed.
Thanks applied.
boe
RE: [PATH] Get rid of very annoying header warnings on darwin
Arthur Bergman: # This gets rid of the very annoying long double might change warning # under Darwin... Thanks, applied (config/init/hints/darwin.pl version 1.7). However, can you see if the diff below my sig (applied against 1.7, not 1.6) works too? If so, it's probably a more appropriate place to put it. --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna set myself on fire to prove it. Index: config/init/hints/darwin.pl === RCS file: /cvs/public/parrot/config/init/hints/darwin.pl,v retrieving revision 1.7 diff -u -r1.7 darwin.pl --- config/init/hints/darwin.pl 11 Sep 2003 18:43:41 - 1.7 +++ config/init/hints/darwin.pl 11 Sep 2003 18:46:43 - @@ -1,6 +1,6 @@ my($ccflags, $ldflags)=Configure::Data-get(qw(ccflags ldflags)); -$ccflags .= -pipe -fno-common -Wno-long-double ; +$ccflags .= -pipe -fno-common ; $ccflags =~ s/-flat_namespace\s*//; $ldflags =~ s/-flat_namespace\s*//; $ldflags .= -flat_namespace ; @@ -8,5 +8,5 @@ Configure::Data-set( ccflags = $ccflags, ldflags = $ldflags, - cc_warn = -Wno-shadow, + cc_warn = -Wno-shadow -Wno-long-double, );
Need Win32 Tinder suggestions
I'm about done setting up the TPF Win32 tinderbox machine. It's a WinXP Pro gadget with Visual Studio .NET. I'm going to install cygwin as well. I'll be setting up tinderboxes for it but, honestly, I don't do windows programming, so I'm not particularly sure what'd be useful. I'm going to try and get JIT and non-JIT tinders for both vanilla VS and cygwin builds, but I'd be more than happy if someone with some actual windows experience would throw in some suggestions on what and how to set things up for the maximum utility. Dan
Re: Need Win32 Tinder suggestions
Based on current customers I would guess the following in priority: VC/C++ (latest non-.NET version, most people I know are still building their stuff with Pre-.NET versions) Visual Studio .NET Cygwin Borland C++ Builder I love Borland but I have to put it last because I think the 1st 3 covers more installed base. Just my opinions. Hey where is my free P6E copy? :P I'm plugging the book here at IBM, although I never saw my name mentioned, particularly in the IMCC chapter. :) I'm doing a Lunch-N-Learn soon and will use the book. Later, -Melvin Dan Sugalski [EMAIL PROTECTED] 09/11/2003 02:54 PM To: [EMAIL PROTECTED] cc: Subject:Need Win32 Tinder suggestions I'm about done setting up the TPF Win32 tinderbox machine. It's a WinXP Pro gadget with Visual Studio .NET. I'm going to install cygwin as well. I'll be setting up tinderboxes for it but, honestly, I don't do windows programming, so I'm not particularly sure what'd be useful. I'm going to try and get JIT and non-JIT tinders for both vanilla VS and cygwin builds, but I'd be more than happy if someone with some actual windows experience would throw in some suggestions on what and how to set things up for the maximum utility. Dan
Re: Need Win32 Tinder suggestions
On Thu, 11 Sep 2003, Melvin Smith wrote: Based on current customers I would guess the following in priority: VC/C++ (latest non-.NET version, most people I know are still building their stuff with Pre-.NET versions) Visual Studio .NET Cygwin Borland C++ Builder I don't have VC/C++ or Borland -- if someone gets me copies I'll install them and make 'em build as well. Hey where is my free P6E copy? :P D'oh! Sitting on my bureau waiting to get packaged up and mailed. You sent me your address, right? Dan
Re: Need Win32 Tinder suggestions
Eep, I was too busy poking fun at Dan about the book I forgot to say: 1) I do not represent IBM nor IBM's preferences for development environment, I was just guessing. You are welcome to add IBM Visual Age stuff in there, let me know if you need a license. :) 2) The P6E book was well done, I did finally get a look at it at Barnes and Noble. Good job Dan/Leo. Cheers, -Melvin Dan Sugalski [EMAIL PROTECTED] 09/11/2003 02:54 PM To: [EMAIL PROTECTED] cc: Subject:Need Win32 Tinder suggestions I'm about done setting up the TPF Win32 tinderbox machine. It's a WinXP Pro gadget with Visual Studio .NET. I'm going to install cygwin as well. I'll be setting up tinderboxes for it but, honestly, I don't do windows programming, so I'm not particularly sure what'd be useful. I'm going to try and get JIT and non-JIT tinders for both vanilla VS and cygwin builds, but I'd be more than happy if someone with some actual windows experience would throw in some suggestions on what and how to set things up for the maximum utility. Dan
Re: Need Win32 Tinder suggestions
I do have an older version of Borland that I can mail you, but I think it is at least 2 releases old As for Microsoft I can't help with a license, but I can probably get us one for IBM Visual Age. I assume you have a lot of disk space? Doesn't Borland have some sort of free download version that is non-commercial usable? I'll check. -Melvin Dan Sugalski [EMAIL PROTECTED] 09/11/2003 03:08 PM To: Melvin Smith/ATLANTA/Contr/[EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject:Re: Need Win32 Tinder suggestions On Thu, 11 Sep 2003, Melvin Smith wrote: Based on current customers I would guess the following in priority: VC/C++ (latest non-.NET version, most people I know are still building their stuff with Pre-.NET versions) Visual Studio .NET Cygwin Borland C++ Builder I don't have VC/C++ or Borland -- if someone gets me copies I'll install them and make 'em build as well. Hey where is my free P6E copy? :P D'oh! Sitting on my bureau waiting to get packaged up and mailed. You sent me your address, right? Dan
Re: Need Win32 Tinder suggestions
On Thu, 11 Sep 2003, Melvin Smith wrote: Eep, I was too busy poking fun at Dan about the book I forgot to say: 1) I do not represent IBM nor IBM's preferences for development environment, I was just guessing. You are welcome to add IBM Visual Age stuff in there, let me know if you need a license. :) And media! (Or a download location) I'd be thrilled to have it up and running. I should probably try and find a license for Intel's compiler too. (I think the 80G drive on this thing may end up being too small...) 2) The P6E book was well done, I did finally get a look at it at Barnes and Noble. Good job Dan/Leo. And it's your job, if you choose to accept it, to help make it horribly out-of-date. :) Dan
Re: Need Win32 Tinder suggestions
On Thu, Sep 11, 2003 at 03:16:15PM -0400, Dan Sugalski wrote: And it's your job, if you choose to accept it, to help make it horribly out-of-date. :) Are there going to be (booby) prizes for the people who make the most paragraphs obsolete? Is anyone counting? (Who do I score the U-turn on page 93 to?) Nicholas Clark
Re: Need Win32 Tinder suggestions
On Thu, 11 Sep 2003, Melvin Smith wrote: I do have an older version of Borland that I can mail you, but I think it is at least 2 releases old As for Microsoft I can't help with a license, but I can probably get us one for IBM Visual Age. I may be able to scare up media and license from MS for VS/C++. They're the folks that got us the VS/.NET kit. I assume you have a lot of disk space? With 80 gig I thought I did, but I'm not so sure at this point... :) Doesn't Borland have some sort of free download version that is non-commercial usable? I'll check. I honestly don't know. It's been a few years since I used Windows, and at that point it was mostly as an X client, Eudora host, DVD player, and cygwin setup. I don't know about all these fancy gooey tools everyone's using... :-P Dan
Re: Need Win32 Tinder suggestions
On Thu, 11 Sep 2003, Nicholas Clark wrote: On Thu, Sep 11, 2003 at 03:16:15PM -0400, Dan Sugalski wrote: And it's your job, if you choose to accept it, to help make it horribly out-of-date. :) Are there going to be (booby) prizes for the people who make the most paragraphs obsolete? Is anyone counting? Heh. We ought to do that. Winner gets a mention in the forward of the next version. Dunno if we should send on a signed copy, or a hand corrected version of the old copy. (Who do I score the U-turn on page 93 to?) Don't have it handy. Which U-turn is that? Dan
RE: Need Win32 Tinder suggestions
Dan Sugalski: # (Who do I score the U-turn on page 93 to?) # # Don't have it handy. Which U-turn is that? Presumably, Coroutines can be implemented in terms of continuations if need be, but that requires using a full continuation-passing function call system, something we chose not to do. --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna set myself on fire to prove it.
RE: Need Win32 Tinder suggestions
On Thu, 11 Sep 2003, Brent Dax wrote: Dan Sugalski: # (Who do I score the U-turn on page 93 to?) # # Don't have it handy. Which U-turn is that? Presumably, Coroutines can be implemented in terms of continuations if need be, but that requires using a full continuation-passing function call system, something we chose not to do. Ah. That one's the collective fault of the denizens of the Little Languages mailing list and the MIT Lisp and/or Scheme folks. Dan
RE: Need Win32 Tinder suggestions
Dan Sugalski: # Ah. That one's the collective fault of the denizens of the Little # Languages mailing list and the MIT Lisp and/or Scheme folks. Oh, and in case it wasn't abundantly clear before, I already picked up a copy--a month or so ago, while I was on vacation and needed something to read during long drives. It was good, but not long enough to last from Virginia to Philadelphia. ;^) --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna set myself on fire to prove it.
RE: Need Win32 Tinder suggestions
On Thu, 11 Sep 2003, Brent Dax wrote: Dan Sugalski: # Ah. That one's the collective fault of the denizens of the Little # Languages mailing list and the MIT Lisp and/or Scheme folks. Oh, and in case it wasn't abundantly clear before, I already picked up a copy--a month or so ago, while I was on vacation and needed something to read during long drives. It was good, but not long enough to last from Virginia to Philadelphia. ;^) You were supposed to take the rest of the time and sketch out a grammar for perl 6 regular expressions. Did we leave that bit out of the end of the book? (Damn, one more erratta to add! :) Dan
Re: Need Win32 Tinder suggestions
On Thu, Sep 11, 2003 at 12:44:05PM -0700, Brent Dax wrote: Dan Sugalski: # (Who do I score the U-turn on page 93 to?) # # Don't have it handy. Which U-turn is that? Presumably, Coroutines can be implemented in terms of continuations if need be, but that requires using a full continuation-passing function call system, something we chose not to do. That would be the one: http://www.ccl4.org/~nick/P/p6ee++.jpeg (thanks to my housemate hoggy for taking the picture) I think that a fully hand corrected first edition would make quite an interesting prize. Nicholas Clark
Re: [RFT] File Spec
On Thu, Sep 11, 2003 at 08:36:02PM +0300, Vladimir Lipskiy wrote:
Famous last words: Our data is perfect, we don't need to check our
inputs.
Yes. Our data is perfect and we don't need to check our inputs if we
play by rules. And the rules are:
Always use concat_dirnames to concatenate directory names
Always use append_filename to append a file name to a path
Always keep in mind that this tool gives you a proper result
when you give it proper input, which is simple directory
names, simple file names, and paths produced by this tool only.
If you observe the rules, you won't get into a mess.
People make mistakes. Perhaps you should produce some errors if a user
strays outside these rules. Garbage in, garbage out: Bad. Garbage in,
error out: Good.
I'll admit to not knowing the general error philosophy of Parrot ops.
Ok, but what happens when I pass filepaths with volumes attached to
concat_dirnames?
You get what you do, nonsense. Even File::Spec, a tool of a lot more
higher level, doesn't protect you from such things.
D:\perl -MFile::Spec::Functions -e print catdir('C:\hh','C:\dd'), qq(\n)
C:\hh\C:\dd
Justifying your own tool's bad behavior using another tool's bad behavior
is not a terribly compelling design argument. Just because File::Spec's
handling of volumes is historicly lousy doesn't mean yours has to be.
What if the volumes don't match?
Don't match against what? concat_dirnames doesn't do matching arguments
against anything but PARROT_FS_DIRNAME_START and PARROT_FS_DIRNAME_END,
which, for example, are '[' and ']' on VMS.
What if I feed you:
concat_dirnames(VOL1:[dir.dir], VOL2:[dir.dir])
Well, I suppose that's simple, its an error since you can't usefully
concatenate two absolute directories. Anyhow, the point is is an *error*.
What if I'm adding a path with a volume to one without?
Still. You get what you do. On Mac:
concat_dirnames('my disk:a', ':b') = ':my disk:a:b'
Mac's a special case since, IIRC, :b can either mean The volume called b
or The file/directory in the current directory called b. On VMS or
Windows no such ambiguity exists.
But I was unclear. I meant the other way around.
concat_dirnames(b, :my disk:a);
Trying to concatenate an absolute directory onto a relative one should
produce an error.
File::Spec has an individual function for such purposes, catpath().
We can't process more than two in-arguments in PASM, so we would take
advantage of prepend_volume and things of such sort.
Unless I'm missing something, since the volumes and root dirs are already
attached to the filepath string, you don't need more than two arguments.
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
It's Ecstacy time!
Re: Embedding interface to PMCs
If the pdd is amended, let's not forget to update the check_source script-
for that matter, if there are any other items that should be added
(perhaps some specific checks for the embedding headers), let me know-
I'll be happy to add them.
--Josh
At 18:57 on 09/11/2003 BST, Nicholas Clark [EMAIL PROTECTED] wrote:
On Thu, Sep 11, 2003 at 09:30:29PM +0300, Vladimir Lipskiy wrote:
to document the idea of Juergen Bommels to include the
extern C {
I take it you meant the full game:
#ifdef __cplusplus
extern C {
#endif
specification () in each header in pdd7_codingstd, no body had replied),
but maybe Parrot isn't going to have support for C++ embedding applications
.
It will. perl 5 does. Therefore the current situation is a bug.
Nicholas Clark
Re: [PATCH] Small test case exception for ponie
On Wednesday, September 10, 2003, at 05:55 pm, Leopold Toetsch wrote: From: Leopold Toetsch [EMAIL PROTECTED] Date: Wed Sep 10, 2003 5:55:59 pm Europe/London To: [EMAIL PROTECTED] (Arthur Bergman) Cc: [EMAIL PROTECTED] Subject: Re: [PATCH] Small test case exception for ponie Reply-To: [EMAIL PROTECTED] Arthur Bergman [EMAIL PROTECTED] wrote: Hi, I am adding an additional pmc (Perl5LV), however a test fails t/pmc/pmc...NOK 75# Failed test (t/pmc/pmc.t at line 1650) # got: 'Perl5LV PMCs have incorrect name # ' # expected: 'All names and ids ok. # ' t/pmc/pmc...ok 91/91# Looks like you failed 1 tests of 91. This is the builtin ponie protection ;-) These come to my mind: $ make realclean perl Configure.pl ... (We are still missing some dependencies) If that doesn't: A PMCs name() is coming from the name() vtable, which is handled in default.pmc. default.name() returns vtable-whoami. This is a STRING set up by pmc2c.pl. You can see these in $class.c files. Normally a class shouldn't handle the name() and type() vtables, the default implementation does it. If you have a base class, that has these functions then you must handle it in all your derived classes. Finally: $ perl classes/pmc2c.pl --tree classes/perl*.pmc should give you a class hierarchy tree. If that still isn't: then set a break point in Parrot_class_name, where the class is that one you see in Perl5LV.c:temp_base_vtable in the Cname slot. HTH leo Aha, that explains it, I assumed that genclass produced something that was correct, apparently it didn't :), fixed now and I withdraw my patch. (I just removed the name and id functions and inherit them instead) Arthur
Embedding interface to PMCs
Hi, Is there any documentation, or code I can read to figure out how use PMCs in embedded mode? I tried to just include parrot/parrot.h in sv.c but that results in a million (or so ;) errors, so using parrot/embed would be nice. (it looks like it isn't finished yet, so it is more a question of what plans exists?) Arthur
Re: Embedding interface to PMCs
- Original Message -
From: Arthur Bergman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, September 11, 2003 7:14 PM
Subject: Embedding interface to PMCs
Hi,
Is there any documentation, or code I can read to figure out how use
PMCs in embedded mode? I tried to just include parrot/parrot.h in sv.c
but that results in a million (or so ;) errors ...
Ha-ha-ha. The same thing. To be more exactly, I get like a half of million
errors(anyway it's still less than you get), when I try to embed parrot in a
c++ application. The reason of that is that the parrot headers don't contain
the C linkage specification and there is an awful lot of typedef struct a *a
declarations that don't please C++ compilers. I ain't sure (when I proposed
to document the idea of Juergen Bommels to include the
extern C {
specification () in each header in pdd7_codingstd, no body had replied),
but maybe Parrot isn't going to have support for C++ embedding applications.
Re: Embedding interface to PMCs
On Thu, Sep 11, 2003 at 09:30:29PM +0300, Vladimir Lipskiy wrote:
to document the idea of Juergen Bommels to include the
extern C {
I take it you meant the full game:
#ifdef __cplusplus
extern C {
#endif
specification () in each header in pdd7_codingstd, no body had replied),
but maybe Parrot isn't going to have support for C++ embedding applications.
It will. perl 5 does. Therefore the current situation is a bug.
Nicholas Clark
