Re: Solving '=' confusion: ':=' for aliasing

[Joshua Juran]

On Nov 29, 2005, at 5:16 PM, Chip Salzenberg wrote:


On Tue, Nov 29, 2005 at 11:13:05PM +0100, Leopold Toetsch wrote:

On Nov 29, 2005, at 21:36, Chip Salzenberg wrote:

I'm planning a flag day sometime in December.  I'm also planning to
create a simple "handles most cases" translator.


That's all ok with me, but not without an automatic translator [...]


Excellent.  Now if only I knew a good language for text filters...


How about sed or awk?

Josh

Re: [perl #38146] [TODO] OS.pmc - file copy

[Joshua Juran]

On Jan 6, 2006, at 4:11 PM, Alberto Simoes via RT wrote:


[coke - Tue Jan 03 18:03:31 2006]:

OS.pmc should provide both a:

copy(source_file,target)

And a

copy(array_of_source_files,targetDir)


This needs some more discussion. If we look to Perl, for instance, it
doesn't have a built-in copy. You should use either a module, or open
both files, copy contents, and close both files.


You assume cp semantics.  What about preserving metadata?  What about 
multiple forks?  What about per-file properties that are invented after 
you ship your code?  And what if the source and destination are on the 
same file server?



Thus, what I ask if we should have a copy method on OS.pmc.
Basically, I think we have three hipothesis:

1) do not implement copy at all.


You are in a maze of twisty little ad-hoc, informally-specified 
bug-ridden slow implementations of file copy, all different.



2) implement it under os.pmc, in C
3) implement it somewhere else in PIR

Given that we have (I think) all the needed instructions in PIR, it 
will

be a lot easier to make copy portable using the third choice... but I'm
not sure if Parrot will ship with a PIR library...

Please, share your ideas.


I'd like to see every OS get a chance to provide its own file copier.  
This is important to Mac users, since resource forks may exist and the 
AppleShare protocol (AFP) allows for intra-server file copy.  The same 
arguments also apply to other file systems.


The Genie kernel (part of Lamp, a Unix-like environment on Mac OS) has 
a copyfile() system call for just this purpose.  The knowledge of how 
to copy a file correctly in a Mac environment (which is non-trivial) is 
encapsulated in a single place, and usable by any program, either 
directly through the system call, through cp (for shell scripts), or 
through a module-loading interpreter.


For more typical systems, supply copyfile() in a library as you would a 
missing kernel call.


This usage assumes that copyfile() blocks until completion.  Clearly 
there will be a desire for a concurrent processing mode as well.


Josh

Re: [perl #38146] [TODO] OS.pmc - file copy

[Joshua Juran]

On Jan 10, 2006, at 10:29 PM, Chip Salzenberg wrote:


On Sat, Jan 07, 2006 at 01:04:29PM -1000, Joshua Hoblitt wrote:

...  More sophisticated behavior, like metadata replication, should
be left to another method (perhaps syscopy()) that has platform 
specific

behavior(s).


My first thought was that if you're not going to copy any metadata at
all, then you're not looking at an OS method.  But then then I
remembered that some operating systems might actually have
high-efficiency fast tricks for copying (e.g. the way Linux is going
with its splice() system call proposals).  So OS is fine.

However, instead of shying away from the metadata problem, we should
embrace it.  Define copying with metadata as a standard feature with a
standard interface.  Something like:

   metacopy($src, $dest,
owner => 0, # optional to copy
mtime => 1, # mandatory to copy
atime => undef, # forbidden to copy
...
   )


I suggest using -1 to mean forbidden, and any false value to mean 
optional.



This provides a portable way of expressing what you need and want.
If the current operating system can't accomodate you, you'll get a
failure or exception (not making any assumptions on that point).

Hm.  If you say 'contents => undef', you might get a copying of
metadata _only_.  Neat.


This reminds me of something that's been bothering me for a long time.  
Since before System 7 (approaching two decades ago), Mac OS has had a 
system call that exchanges the contents of two files.  The purpose of 
this call is to implement a 'safe save' strategy:  When the user saves 
a document, you create a temp file, write the new contents to it, 
exchange with the existing file, and delete the temp file (which now 
has the old contents).  This is obviously better than just overwriting 
the original file, since there's no risk of crashing or running out of 
disk space leaving a truncated file.  It's also better than using 
rename(), because in the end it's the same file -- except for the 
modification date, the metadata are preserved, including the file ID 
number (read: inode) -- with different contents.  If you rename() 
instead of exchange/delete, you have a new file, and you have to set 
all the metadata yourself, and you may not have the necessary knowledge 
to do that.  I suppose you could backup the original file and then 
overwrite it, but you lose atomicity.


What bothers me is that I haven't seen exchange-files anywhere else.  
Then again, Mac OS doesn't have move-and-rename-simultaneously, so 
nobody's perfect.


Josh

Re: [perl #38146] [TODO] OS.pmc - file copy

[Joshua Juran]

On Jan 11, 2006, at 7:02 PM, Chip Salzenberg wrote:


On Wed, Jan 11, 2006 at 04:16:55PM -0500, Joshua Juran wrote:

Since before System 7 (approaching two decades ago), Mac OS has had a
system call that exchanges the contents of two files.  The purpose of
this call is to implement a 'safe save' strategy ...


Is this still a system call in Mac OS X?


Yes, the original FSpExchangeFiles() call persists along with most of 
the calls pertaining to FSSpecs.  New code written only for Mac OS 9 
and above could also use the newer FSRef-based FSExchangeObjects() call 
which subsumes it.


Josh

Re: Parrot vs NekoVM

[Joshua Juran]

On Feb 28, 2006, at 1:59 PM, Nicolas Cannasse wrote:


On Feb 28, 2006, at 12:09, Nicolas Cannasse wrote:

Yesterday I did a quick fib(30) benchmark comparing Parrot Win32  
daily
build (using jit core) and NekoVM (http://nekovm.org). The  
results are

showing that Parrot is 5 times slower than Neko (see my blog post on
this point there : http://ncannasse.free.fr/?p=66).


Benchmarks are just damn lies ;)


Worse than that...


Not exactly lies, but they are quite different from reality ;)


...they're statistics.  :-)

(With apologies to Mark Twain.)

Josh

Re: [perl #39313] [TODO] or [BUG] improve PMC compiler

[Joshua Juran]

On Jun 7, 2006, at 8:08 AM, Klaas-Jan Stol wrote:

I had a look at this, but I'm not that good at Perl, and regular  
expressions. However, I found where things go wrong, so someone who  
really groks REs may fix it.


I'm no Abigail, :-) but I'll try to help.

THe problem is (well, at least I think it is) at about line 440 in  
pmc2c.pl


sub parse_pmc {
   my $code = shift;

   my $signature_re = qr{
   ^
   (?: #blank spaces and comments and spurious  
semicolons

 [;\n\s]*
 (?:/\*.*?\*/)?# C-like comments
   )*


You're asking for multiple instances of something that could be  
empty.  I don't know if this is problematic, but I suspect it might  
cause unnecessary backtracking.  I would write: (?: [;\n\s] | (?:/ 
\*.*?\*/) )*



   (METHOD\s+)?#method flag

   (\w+\**)#type   <<<==I'd say  
this should be (\w+\s*\**) so it matches a word (the return type),  
optional spaces, and then optial *'s to indicate a pointer

 \s+
   (\w+)   #method name


In the case where there are no '*'s in the text, the pattern '\s*'  
eats up all the whitespace so the following '\s+' doesn't match.   
Although I don't understand why backtracking wouldn't kick in and  
make things match up, albeit inefficiently.


Try writing: ( \w+ (?: \s* \*+ )? )

(Some word characters optionally followed by any whitespace and some  
'*'.)



 \s*
   \( ([^\(]*) \)  #parameters
   }sx;

If the fix as I noted above is done, things don't compile anymore.
I'm sorry I can't provide a real fix, but at least it's easier to  
fix now, hopefully.


The real solution would use regular expressions but not rely on them.

I've been reading Higher Order Perl, by Mark Jason Dominus.  It has a  
chapter on writing parsers which is applicable to this discussion,  
and I cannot recommend it highly enough.


Higher Order Perl
http://hop.perl.plover.com/

Josh


kind regards,

klaas-jan



Leopold Toetsch (via RT) wrote:

# New Ticket Created by  Leopold Toetsch # Please include the  
string:  [perl #39313]
# in the subject line of all future correspondence about this  
issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=39313 >



It's easy to add 'invalide' code to .pmc files. E.g. I had defined:

   METHOD parent() {
   return PMC_pmc_val(SELF) ? PMC_pmc_val(SELF) : PMCNULL;
   }

Due to the absence of a return value, the PMC compiler just  
ignores this 'method' without further notice.


This also is happening, if there's just a whitespace before the '*':

   METHOD PMC *parent() {
   return PMC_pmc_val(SELF) ? PMC_pmc_val(SELF) : PMCNULL;
   }

This totally valid C type declaration is just ignored.

Fixes welcome,
leo

LLVM and C99 and classic Mac OS (Re: LLVM and HLVM)

[Joshua Juran]

On Aug 22, 2006, at 5:52 PM, John Siracusa wrote:


Has anyone looked at LLVM lately?

http://llvm.org/


I discovered it a few years ago.  My personal interest is in the  
portable C back end, so I can use the g++ compiler front end and send  
the output through CodeWarrior or MPW compilers, whose language  
support is frozen due to non-development (and therefore may have  
issues with C99 or modern C++ constructs) but handle C89 just fine.   
This will require a fairly large Round Tuit, of course.


This pattern may also be applicable to MSVC.

Josh

P.S.  Hi, John!  I loved your article on the Spatial Finder.

Re: PMC Methods, Inheritance, and User-visible Classes

[Joshua Juran]

On Aug 28, 2006, at 12:18 PM, Matt Diephouse wrote:


I would like to add some sort methods as well: quicksort(),
mergesort(), etc. But as methods, there is potential for these to end
up in a user-visible space.

Say for example, that I add a mergesort method to AbstractPMCArray.
Ruby's array class wouldn't be able to use AbstractPMCArray as a base
class because there is no mergesort method on an Array in Ruby.

Any thoughts?


How about requiring array classes to implement swap(), and then  
implementing sort algorithms in terms of that, as in C++?


Josh

Re: [perl #41889] [PATCH] hoist cut and paste duplication into a function in src/library.c, also possible win32 bug found ?

[Joshua Juran]

On Mar 18, 2007, at 3:59 PM, Mike Mattie wrote:


On Sun, 18 Mar 2007 19:30:35 +
Nicholas Clark <[EMAIL PROTECTED]> wrote:


On Sun, Mar 18, 2007 at 03:35:14PM +, Jonathan Worthington wrote:

Mike Mattie (via RT) wrote:

While mucking around in src/library.c I noticed some cut & paste
duplication. It looked like a fairly simple hoist so I have
attached the changes I made.


[snip]


   while ( (cnv = strchr(path->strstart, '/')) )
*cnv = '\\';


[snip]

But painfully inefficiently. (Probably this doesn't matter here)

I suspect the loop wants to become

  cnv = path->strstart;
  while (*cnv) {
if (*cnv == '/')
  *cnv = '\\';
}
++cnv;
  }

which should at least be O(n) rather than O(n²) for a string of
length n.


you are correct. I do like the strchr() call over a manual iteration
though. GCC will aggressively optimize some of the standard library
string functions, and I would guess that many other compilers do as  
well.


It at least leaves the door open to picking up the benefits of
future hardware/compiler changes. It's also more friendly to static- 
analysis.


I can't imagine someone else hasn't already come up with

cnv = path->strstart;
while ( (cnv = strchr( cnv, '/' )) )
{
*cnv = '\\';
}

but I didn't see it posted, so here it is just in case.

Josh

Re: [perl #41889] [PATCH] hoist cut and paste duplication into a function in src/library.c, also possible win32 bug found ?

[Joshua Juran]

On Mar 19, 2007, at 4:17 AM, Nicholas Clark wrote:


On Sun, Mar 18, 2007 at 08:33:25PM -0700, Joshua Juran wrote:


I can't imagine someone else hasn't already come up with

cnv = path->strstart;
while ( (cnv = strchr( cnv, '/' )) )
{
*cnv = '\\';
}

but I didn't see it posted, so here it is just in case.


Bikesheds, I know, but this will be faster:

cnv = path->strstart;
while ( (cnv = strchr( cnv, '/' )) )
{
*cnv++ = '\\';
}

because there's no way that the character at cnv can match '/' now :-)


I agree that that condition holds, but I'm not convinced your  
optimization yields a speed increase.  It saves a byte comparison per  
match, (which I missed before) but it doesn't prevent any calls to  
strchr().  And it makes the code a tiny bit larger, and a tiny bit  
more complex.  I'd probably go with yours over mine for  
'correctness'[1], though, unless profiling indicated otherwise.


[1] Regardless of speed, it 'looks' wasteful to duplicate that byte  
comparison.  It's usually important that the reader of the code have  
confidence in it.


Anyway, your performance claim is a load of null if the pathname  
conversion is followed by a filesystem operation such as stat().  :-)


Whether its faster than the loop without strchr probably depends on  
whether
the compiler inlines strchr(), whether the optimised version is  
efficient
on non-word aligned strings, and whether the optimised version  
doesn't have
a higher start cost. Either is better* than the current, and I  
don't have

a Win32 platform to test on, so can't test a change.

Nicholas Clark

* Yes, even in a non-speed critical area, because having poor  
algorithms around

  will tempt people to base other code on them.


Josh

Re: [svn:parrot] r17623 - trunk

[Joshua Juran]

On Mar 19, 2007, at 1:44 AM, chromatic wrote:

On Sunday 18 March 2007 10:14, [EMAIL PROTECTED] wrote:


Log:
Commenting out old MacOS Classic-specific code so the warnings don't
appear. Does anyone use MacOS Classic anymore?


We can get this code out of Subversion if we need it again; I say  
just delete

it.


The Lamp (Lamp Ain't Mac POSIX) environment effectively adds a Unix  
layer to traditional Mac OS, providing the usual process context  
(including argv).  I have a working miniperl already, and intent to  
support parrot the same way.


Otherwise, I suspect there are zero plans to target traditional Mac  
OS at all, unless pudge wants to surprise me.  :-)


Josh

Parrot on Mac OS

[Joshua Juran]

Hello,

On a nostalgic lark I searched Google for "Perl Python Parrot" and was 
astonished (and excited) to discover the Parrot project.


The Parrot FAQ states that Parrot must run on all platforms on which 
Perl 5 runs, including classic Mac OS.  I've been implementing a 
POSIX-like environment for Mac OS (unfortunately named LAMP) that given 
sufficient development could provide or mimic most POSIX facilities.  
LAMP's kernel (named Genie) is a regular Mac application that doesn't 
do anything weird like futz around with the virtual memory system, 
which while true means that fork() is absolutely impossible, since all 
processes share the same address space and therefore process images 
can't be copied (though vfork() can be managed with either a longjmp() 
hack or a change in semantics).  I hope this isn't a showstopper.  If 
Parrot's process contexts can be duplicated, then scripts can be made 
to fork even though parrot itself can't.


Genie more or less supports multiprogramming, signals, blocking I/O, 
and polymorphic file descriptors including pipes and sockets.  Programs 
are built as CFM plugins (dynamically loaded shared libraries), and 
each process runs in its own Mac OS thread.  Implementing threads and 
dynloading *within* a Genie process shouldn't be too hard.  So, 
contrary to MacPerl's approach of being a Mac application, I'm 
suggesting that parrot simply target a pseudo-POSIX layer and punt the 
Mac-specific details.


In case it's of interest, I also have Mac OS X, Linux/i386, and 
Linux/m68k systems.


Josh

Re: Indexing hashtables

[Joshua Juran]

On Jun 22, 2005, at 2:25 PM, Klaas-Jan Stol wrote:


I have some trouble indexing hashtables.

I have the following code snippet:

x["y;a"] = $P10 # (1) this does not work with the code below
y["a"] = $P10 # (2) this does work with the code below


x.y.a = 1;
print(x.y.a);

x and y are both hashtables.
x has a field "y", storing y
y has a field "a", storing an integer

I'd like to get the field "a" step by step, so first get a reference 
to x.y, then get a reference to y.a, instead of indexing at once with 
"y;a" as done at (2). Doing it step by step makes generating code a 
bit easier, in my opinion.


I'm wondering what I'm doing wrong, because it looks like it should be 
working (right?)


I'm just guessing here, but doesn't #1 above add 1 to x with key "y;a"?
For example, if your intention in Perl 5 was '$x->{y}{a} = 1', doesn't 
#1 mean '$x->{"y;a"} = 1'?


Josh

Re: takers wanted - a perl job

[Joshua Juran]

On Jun 24, 2005, at 8:07 AM, Chip Salzenberg wrote:


On Fri, Jun 24, 2005 at 08:21:25AM +0200, Leopold Toetsch wrote:

The plan is to move these methods to classes/scalar.pmc


Last I remember, I asked for a number.pmc for Integer and Float to
derive from.  A Number isa Scalar.  Is there some problem with Number?


Forgive my C++ bias, but why are these methods at all?  Shouldn't 
mathematical functions be functions?  Shouldn't the transcendentals 
take floating point values (converting from integers) and others be 
overloaded for both types as appropriate?


Having asked the question, here's my answer (which I'm making up and 
may not be accurate):


There's not a fixed set of numerical types -- consider bignums and 
complex numbers.  In C++ you would provide overloaded operators and 
functions along with the type declaration, but like Perl 5, Parrot 
blurs the distinction between operator and function, and method call 
vs. function call, so the effect is the same.


Having read my answer, I'd say that transcendentals (e.g. cos()) belong 
to Float-based types and any other types for which it makes sense to 
define them.  If you just happen to be dealing with an integral number 
of radians (probably zero), which just happens to be stored in an 
Integer, convert it to a Float first.


Speaking of radians, are there any plans for unit analysis?  It would 
be helpful to be able to write:


$angle = 60 degrees;
print cos $angle, "\n";
# prints 0.5

Josh

Re: takers wanted - a perl job

[Joshua Juran]

On Jun 24, 2005, at 11:02 PM, Bob Rogers wrote:

Since Complex could also be considered a Number, but of a very 
different
sort, it might be worth constructing the type hierarchy to reflect 
this:


Scalar
   Number
  Real
 Integer
 Float
  Complex


This is inaccurate.  All integers are reals (in fact, all integers are 
rationals and all rationals are reals), but floats are not all 
integers.  Factorial should be defined for integers but not floats.


Also, all reals are complex numbers (with a zero imaginary component).  
Here's my suggested hierarchy with abstract types in lowercase and 
instantiable types capitalized:


scalar
number (possibly complex)
real
rational
integer
Integer
BigInt
Ratio
Float
Complex
Quaternion
String
...

Also, what about non-scalar numbers such as vectors and matrices?  Will 
we have operators for dot-product and cross-product?  Or is this 
another HLL issue?


Josh

Re: PMCs: Should We Use Them?

[Joshua Juran]

On Jul 7, 2005, at 11:28 PM, Larry Wall wrote:


On Thu, Jul 07, 2005 at 09:28:04PM -0400, Michal Wallace wrote:
: What I'd want is to be able to download the language
: specific extensions as a library from cpan. Better
: yet if users can do it themselves without having
: to bug me.

Hmm...
My new language has several additional instruction:

break_out_of_sandbox
be_a_zombie
rm_minusrf
melt_cpu

:-)


I would expect these to be privileged instructions.  For example, only 
root should be entitled to melt the CPU.


Josh

Re: [perl #36794] [BUG] substr opcode segfault

[Joshua Juran]

On Aug 3, 2005, at 2:58 PM, Will Coleda (via RT) wrote:


With r8787, the following tcl code:

puts \u666

causes a segfault in the substr opcode (from tcl's lib/tclconst.pir),
and forces a few tcl-unicode escape tests into TODOs.


Duh, because it's *evil*.

:-)

Josh

Re: Zcode interpreter release

[Joshua Juran]

On Aug 24, 2005, at 7:42 PM, Andrew Rodland wrote:


On Wednesday 24 August 2005 04:26 pm, Amir Karger wrote:


Several people pointed out that I didn't perldoc -f system. Sorry!
Btw, even after reading the docs, I still don't understand why Perl
would pass a cd command to a piece of the shell that can't understand
it. Granted, I shouldn't do it anyway, because then Perl will exit the
shell it created for the system() and my cd will be useless.


It's not "a piece of the shell"; it's no shell at all. Perl is trying 
to
execute /bin/cd (or rather, 'cd' somewhere in your search path), as 
provided
for by execvp. As to why perl does it; perl doesn't know or care that 
the
thing you're naming is a shell builtin; it simply tries to run what 
you told

it to. If you wanted to force it to work as a builtin, you could use
system('sh', '-c', 'cd /foo'); -- but as you've already noted, it 
wouldn't be

good for anything anyway.


Another way to execute a shell builtin is to append a semicolon:  
system( "cd /foo;" ).


Josh

Re: loadlib and libraries with '.' in the name

[Joshua Juran]

On Sep 23, 2005, at 3:47 AM, Leopold Toetsch wrote:


On Sep 23, 2005, at 7:51, Ross McFarland wrote:

i was planning on playing around with gtk+ bindings and parrot and 
went about looking around for the work that had already been done and 
didn't turn anything up. if anyone knows where i can find it or who i 
should talk to i would appreciate that info as well.


Google for "NCI gtk". There is also a weekly summary entry but the 
xrl.us shortcut seems to have expired.


I was wondering about that.  I Googled for "tinyurl considered harmful" 
and was surprised to find only one message, discussing the phishing 
risks.  I found no mention of the risk of outsourcing a bottleneck to a 
third party who has zero obligation or direct interest to continue 
providing the service.


From :


Do Metamark links expire?

The Metamark urls expire after five years or two years after the last 
usage - whichever comes later. However, if a link is never used, it 
will expire after two years. This should mean that as long as a link 
is on a public page, some search engine will visit it and keep it 
alive.


Of course, this is subject to change and is no promise but just my 
intentions as of this writing. If you want guarantees you can make 
your own service.


To be quite frank, I'm astonished the practice exists here in the first 
place.  In my opinion it goes directly against the spirit of the Web 
envisioned by Tim Berners-Lee.  A better practice would be to post long 
URL's within angled brackets.  And there's no reason you can't do both, 
either.


Josh

Re: [perl #36200] Parrot on Linux/m68k test failures

[Joshua Juran]

On Oct 5, 2005, at 12:11 AM, Joshua Hoblitt via RT wrote:


[EMAIL PROTECTED] - Tue Jun 07 02:29:24 2005]:

A 'make test' of parrot failed some tests on Linux/m68k.

Here is the contents of myconfig:

Summary of my parrot 0.2.1 (r8279) configuration:
   configdate='Mon Jun  6 03:37:27 2005'


Would you mind retesting with the latest sources from SVN?


Parrot itself builds successfully, but 'make' fails here:

...
./parrot -o runtime/parrot/library/Stream/Sub.pbc 
runtime/parrot/library/Stream/Sub.imc
./parrot -o runtime/parrot/library/Stream/Writer.pbc 
runtime/parrot/library/Stream/Writer.imc
./parrot -o runtime/parrot/library/YAML/Parser/Syck.pbc 
runtime/parrot/library/YAML/Parser/Syck.imc
/usr/bin/perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >> 
8;' dynclasses

make[1]: Entering directory `/home/jjuran/src/parrot/dynclasses'
/usr/bin/perl /home/jjuran/src/parrot/build_tools/pmc2c.pl --dump 
match.pmc
Can't write 'classes/default.dump' at 
/home/jjuran/src/parrot/build_tools/pmc2c.pl line 664.

pmc2c dump failed (512)
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/jjuran/src/parrot/dynclasses'
make: *** [dynclasses.dummy] Error 2

My guess is that the absence of directory 
'/home/jjuran/src/parrot/dynclasses/classes' is causing open to fail, 
and that the trivial fix is to open '../classes/default.dump' instead.  
Or not change directories.


Josh

Re: [perl #37577] [PATCH] Fix a couple of minor niggles (-1 -> uint, K&R prototype)

[Joshua Juran]

On Nov 5, 2005, at 4:27 PM, Joshua Hoblitt via RT wrote:


[EMAIL PROTECTED] - Tue Nov 01 04:52:22 2005]:

This patch fixes two classes of issue.

  * Don't assign -1 to an unsigned variable; use ~0U instead as it
makes it clear that the value is intended to be out-of-band (g++
warned about this, and C compilers will increasingly)

  * Change a K&R prototype in a config test

Regards,

Nick


I've applied the bit of the patch that removed the K&Rism in
config/auto/alignptrs/test_c.in as r9803.  I don't think that anybody,
myself included, like the idea of using ~0U as a magic value.  Can I
consider this bug 'resolved'?

Cheers,

-J


If -1 causes warnings, I'd think it should be replaced.  I agree that 
~0U isn't readable.  How about defining a named constant?  That solves 
both problems, and has the additional benefit of making the client code 
self-documenting.


Josh

Re: Is Parrot 1.0 too late?

[Joshua Juran]

On Apr 24, 2007, at 11:21 PM, chromatic wrote:


On Tuesday 24 April 2007 15:31, Nikolay Ananiev wrote:


Why would the developers use Parrot instead of JVM/CLR/Mono?


Parrot is open source today, not *mumble* down the road like the  
JVM will be.


Parrot is also widely portable, much like perl is.  This one's  
especially important to me, as I still work with Mac OS 9.


Parrot supports more dynamic features than only "find method by  
name at

runtime".


Unix user shells have had that for decades.  It's called 'execvp()'. :-)

Josh

Re: Is Parrot 1.0 too late?

[Joshua Juran]

On Apr 25, 2007, at 2:06 AM, Nicholas Clark wrote:


On Tue, Apr 24, 2007 at 11:43:48PM -0700, Joshua Juran wrote:


Parrot is also widely portable, much like perl is.  This one's
especially important to me, as I still work with Mac OS 9.


Parrot builds on Mac OS 9? Cool
It's not listed in PLATFORMS, so I wasn't sure.


No -- I haven't even attempted it yet.  I'm still developing the Unix  
emulation layer, Lamp (Lamp Ain't Mac POSIX) on which it will run,  
including the kernel and prerequisite userland utilities -- one of  
which is perl.


Just this weekend I ported Lamp to 68K, and after a little assembly  
hacking and refactoring yylex() into small enough chunks, perl made  
the trip as well.


Once I get perl further along (as right now it's only miniperl -- I  
haven't written dlopen() yet) and add some missing features to the  
shell, I'll take on building parrot.  Chances are, if it works on  
CygWin, I can make it run in traditional Mac OS -- on both  
architectures.


Josh

Re: Is Parrot 1.0 too late?

[Joshua Juran]

On Apr 25, 2007, at 11:46 AM, Joshua Isom wrote:

Aiming to be as ANSI C compatible as possible will help to make it  
build on a PDP-10, although I haven't tried it yet in an emulator.   
Of course, some tweaking may be necessary, but that would only  
increase portability!


Oh, and I forgot to mention:  With Parrot, you have the Perl  
community's legendary sense of humor.


Hey, at least Mac OS 9 uses ASCII... *ducks*

Josh



On Apr 25, 2007, at 4:06 AM, Nicholas Clark wrote:


On Tue, Apr 24, 2007 at 11:43:48PM -0700, Joshua Juran wrote:


Parrot is also widely portable, much like perl is.  This one's
especially important to me, as I still work with Mac OS 9.


Parrot builds on Mac OS 9? Cool
It's not listed in PLATFORMS, so I wasn't sure.

Re: Simplifying Marking with a Macro

[Joshua Juran]

On Jun 19, 2007, at 12:13 AM, chromatic wrote:

I hate seeing repeated code structures.  We could simplify the mark 
() entry in

plenty of PMCs with a macro something like:

#define MARK_UNLESS_NULL(interp, struct, name) \
if (struct->name) \
pobject_lives(interp, (PObj *)struct->name)


Or better yet:

#define MARK_UNLESS_NULL(interp, struct, name) \
if (struct->name) \
pobject_lives(interp, (PObj *)struct->name); \
else \
(void) NULL

Josh

Re: [perl #44555] [PATCH] Add POD to 51_if_unless.pir

[Joshua Juran]

On Aug 10, 2007, at 4:21 PM, Colin Kuskie (via RT) wrote:


+=item Numbers
+
+0.0 is false, all other numbers are true.


Including -0.0 and NaN?

Either way, that should be documented explicitly.

Josh

Re: [perl #45013] Configure fails if prefix ends with '/'

[Joshua Juran]

On Sep 10, 2007, at 6:52 PM, James Keenan via RT wrote:


On Mon Sep 10 10:53:43 2007, [EMAIL PROTECTED] wrote:


Is the chance that $prefix ends in slash-newline sufficiently rare
that the $
anchor is better than \z?


Can we get some tests on Win32 as well?  And how about that Mac OS 9?


I'm going to assume the prerogative of speaking on behalf of the  
community of prospective supporters of Parrot on Mac OS 9, based on  
the belief (or perhaps merely a suspicion) that I constitute a  
majority of that community.


As I've mentioned previously on p5p, I've ported perl (well,  
miniperl) to a Unix-like environment that runs on top of Mac OS 9 --  
the moral equivalent of CygWin.  Since Lamp (Lamp Ain't Mac POSIX)  
uses Unix-style filing, there won't be slashes in individual file and  
directory names (they'll occur as colons, just like in OS X).  But  
you'll still have to watch out for Icon\r and friends.


Having a file named with a bare LF is just plain evil, generally not  
possible for a 'mere mortal' to create through sanctioned channels,  
and IMHO deserving of whatever consequences follow -- but technically  
legal.  At this level of obscurity, correctness is less a public  
service than it is an artistic expression.


In summary, Parrot on OS 9 (running in Lamp) looks like like Parrot  
on Unix.  (Except for the occasional wacky filename, which OS X has  
to handle anyway.)


As for 'macish' parrot (as opposed to unixish parrot running in  
Lamp), I expect there won't be one.  (Unless neeri or pudge cares to  
contradict me...)


Josh

Re: [svn:parrot] r21437 - branches/pdd15oo/src/ops

[Joshua Juran]

On Sep 21, 2007, at 1:15 AM, Joshua Isom wrote:


-Werror -Wdeclaration-after-statement

Should work according to the manpage.  But just one little problem.

src/string.c
In file included from src/string.c:26:
src/string_private_cstring.h:21: warning: size of 'parrot_cstrings'  
is 7560 bytes

*** Error code 1

So we'd have to change some things around.  Every single warning  
would have to go away.


How about runniing the gcc output through a filter that checks for  
the warning and if present indicates failure?


Josh



On Sep 20, 2007, at 4:24 PM, Nicholas Clark wrote:


On Thu, Sep 20, 2007 at 02:13:11PM -0700, chromatic wrote:

Hoist that declaration up a bit, or C89 compilers will complain.   
Is there a

GCC warning that we could enable here?


 -Wdeclaration-after-statement

Sadly it can't be made an error.

Re: [perl #46223] [PATCH] Remove dead code in src/pmc/pair.pmc (Coverity CID 5)

[Joshua Juran]

On Oct 7, 2007, at 12:43 PM, Paul Cochrane (via RT) wrote:


# New Ticket Created by  Paul Cochrane
# Please include the string:  [perl #46223]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46223 >


Coverity Prevent mentions that the code after the C
comparison in src/pmc/pair.pmc can never be executed.  Here is the
offending chunk of code (the comments are mine):

 p1 = PMC_pmc_val(SELF);
 p2 = PMC_pmc_val(value);

 if (!p1 && !p2)
return 1;  /* when p1 = p2 = null, or p1 = p2 = non-null */

 if (p1 || p2)
return 0; /* when p1 = null, p2 = non-null, or p1 = non-null,  
p2 = null */


/* which handles all permutations of p1 and p2 */

/* hence, the following code can never be executed */
 if (!mmd_dispatch_i_pp(INTERP, p1, p2, MMD_EQ))
return 0;

 return 1;

The attached patch removes the dead code, and 'make test' passes.  If
there are no complaints, I'll apply this patch in about 3 days; if it
is approved, as soon as I am able.


The "when ..." comments don't match the code.  Depending on which is  
correct I'd write either


return p1 == null  &&  p2 == null;

or

return (p1 == null) == (p2 == null);

Josh

Re: [perl #46223] [PATCH] Remove dead code in src/pmc/pair.pmc (Coverity CID 5)

[Joshua Juran]

On Oct 8, 2007, at 4:36 AM, Paul Cochrane wrote:


On 08/10/2007, Joshua Juran <[EMAIL PROTECTED]> wrote:

On Oct 7, 2007, at 12:43 PM, Paul Cochrane (via RT) wrote:


# New Ticket Created by  Paul Cochrane
# Please include the string:  [perl #46223]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46223 >


Coverity Prevent mentions that the code after the C
comparison in src/pmc/pair.pmc can never be executed.  Here is the
offending chunk of code (the comments are mine):

 p1 = PMC_pmc_val(SELF);
 p2 = PMC_pmc_val(value);

 if (!p1 && !p2)
return 1;  /* when p1 = p2 = null, or p1 = p2 = non-null */

 if (p1 || p2)
return 0; /* when p1 = null, p2 = non-null, or p1 = non-null,
p2 = null */

/* which handles all permutations of p1 and p2 */

/* hence, the following code can never be executed */
 if (!mmd_dispatch_i_pp(INTERP, p1, p2, MMD_EQ))
return 0;

 return 1;

The attached patch removes the dead code, and 'make test'  
passes.  If
there are no complaints, I'll apply this patch in about 3 days;  
if it

is approved, as soon as I am able.


The "when ..." comments don't match the code.  Depending on which is
correct I'd write either

return p1 == null  &&  p2 == null;

or

return (p1 == null) == (p2 == null);


Another good reason why I submitted a patch instead of just committing
the change :-)  On looking at this again I think my reading of the
code was incorrect.  Here's another go:

This path will be taken only if p1 *and* p2 are null.
if (!p1 && !p2)
return 1;

This path will be taken if either p1 is non-null or p2 is non-null
if (p1 || p2)
 return 0;

So the only case left is p1 is non-null *and* p2 is non-null, which
means this code *is* executed (at some stage)


False.  "Either or" in logic indicates exclusive union, but in  
general English does not.  Regardless, the test (p1 || p2) includes  
the case of both p1 and p2 being non-null, so whatever the state of  
p1 and p2, one of those two tests will catch it and return.



The question now becomes: what is Coverity Prevent trying to tell us?
Is it getting mixed up somehow?


Nope.  Coverity is right on the money.

Josh

Re: [svn:parrot-pdd] r22126 - trunk/docs/pdds/draft

[Joshua Juran]

On Oct 16, 2007, at 6:33 AM, [EMAIL PROTECTED] wrote:


Modified: trunk/docs/pdds/draft/pdd19_pir.pod
== 


--- trunk/docs/pdds/draft/pdd19_pir.pod (original)
+++ trunk/docs/pdds/draft/pdd19_pir.pod Tue Oct 16 06:33:21 2007
@@ -116,8 +116,8 @@

 Heredocs work like single or double quoted strings. All lines up to
 the terminating delimiter is slurped into the string. The delimiter


"All lines ... is slurped" should end "are slurped".

Josh

Re: [perl #39824] [CAGE] tools/dev/check_source_standards.pl -- this should be a test

[Joshua Juran]

On Oct 16, 2007, at 10:52 AM, Paul Cochrane wrote:


The minimum requirements for filenames should be:
 - Any character in the set: a-zA-Z0-9,.-_
 - Should we make a rule about multiple dots?
 - Should there be a maximum length?  1024 chars?  100 chars?  12  
chars?


I would like to see a maximum no greater than 31 characters, for  
compatibility with traditional Mac OS.


Josh

Re: [perl #39824] [CAGE] tools/dev/check_source_standards.pl -- this should be a test

[Joshua Juran]

On Oct 16, 2007, at 8:23 PM, Patrick R. Michaud wrote:


On Tue, Oct 16, 2007 at 10:45:29PM -0400, James E Keenan wrote:

Joshua Juran wrote:

On Oct 16, 2007, at 10:52 AM, Paul Cochrane wrote:


The minimum requirements for filenames should be:
- Any character in the set: a-zA-Z0-9,.-_
- Should we make a rule about multiple dots?
- Should there be a maximum length?  1024 chars?  100 chars?  12  
chars?


I would like to see a maximum no greater than 31 characters, for
compatibility with traditional Mac OS.


I'm not necessarily in agreement with this, but I wonder whether you
could you run a 'find' over the Parrot distribution and provide us  
with

a list of files that are >32 characters.


Running it on my checkout of parrot (r22155), I get

  docs/dev/pmc_object_design_meeting_notes.pod  (35 chars)
  t/configure/010-verbose_step_number_not_called.t  (36 chars)


That's the unanimous opinion.


This doesn't include files in .svn/ directories (many of which
exceed 32 characters because of the ".svn-base" extension added
to the name).


I'm aware of those.  For now, they're a non-issue as I haven't yet  
ported svn which would create them in the first place.


Josh

Re: unallocated memory in string.c?

[Joshua Juran]

On Oct 28, 2007, at 8:28 AM, Klaas-Jan Stol wrote:

hi, when building parrot it reported a warning about some variable  
"string"

in string.c
When checking out, I saw this:

static const char *
nonnull_encoding_name(STRING *s)
{
char *string;
if (!s)
strcpy(string, "null string");
else
strcpy(string, s->encoding->name);

return string;
}

Can this be right?


No, it can't.


I thought that the first argument to strcpy needs to
point to some memory, but "string" (which really should be renamed  
I think,


Shouldn't be a problem if you're not 'using namespace std;'.  I use  
'string' as a variable name in my C++ programs without ill effect.


as it might cause trouble when compiling it using a C++ compiler)  
is not

even initialized.


You're quite right -- the listed code is bonkers.  If you're lucky,  
you'll get a segfault attempting to write to unmapped memory.


Josh

Re: [perl #48226] [Patch] Option 'exec' for Parrot::Test::Harness

[Joshua Juran]

On Dec 5, 2007, at 5:57 PM, chromatic wrote:

Everything looks reasonable to me, except q{} versus q{ } which are  
barely
discernable and offers (to my mind) only disadvantages over ''  
versus ' '

which is much more distinguishable.


Would "" vs. " " be a further improvement?

Josh

Re: [perl #61224] .eof returns false if last read call read the last byte of the file, but not beyond

[Joshua Juran]

On Dec 11, 2008, at 5:07 PM, Allison Randal via RT wrote:

The way to check if the byte after the last requested byte is the  
end of

the file is to read ahead. Perl (at least 5.10) does this by actually
reading the next character and then putting it back with 'ungetc'. Not
the best solution. Any read ahead can be a bit expensive. I  
experimented
with a quick patch to use 'peek' in the test for EOF in Parrot,  
just to

see what would happen... it broke a large quantity of code (probably
because all the code is expecting the old behavior of the EOF test, or
possibly a bug in 'peek').


If I'm understanding correctly, unrequested read-ahead is an error.   
The problem is that you can't put the toothpaste back into the tube,  
so to speak.  Continuing with this analogy, calling ungetc() is like  
putting the extra toothpaste in a paper cup for later.  If I'm the  
next person to brush my teeth, then sure, I'll scrape the toothpaste  
out of the cup first before I get more from the tube, but any  
hypothetical roommates would regard the cup as personal to me and  
ignore it, going straight for the tube.


Toothpaste is fungible, though, and it doesn't matter in what order  
it's used, whereas the same is not true of streamed bytes.  If  
multiple processes are sharing a file descriptor and coordinating  
reads from it, any non-undoable read-ahead* will break the protocol.


* Read-ahead could be undone via lseek() for files, or be done non- 
destructively with recv( ..., MSG_PEEK ) for sockets.


Josh

Re: Testing asynchronous code

[Joshua Juran]

On Dec 31, 2007, at 11:57 AM, chromatic wrote:


On Monday 31 December 2007 05:50:47 Allison Randal wrote:


In the concurrency work I'm about to check in, I have some tests that
fail intermittently because they test for something like:

1
alarm1
2
alarm2
3
alarm3
alarm1
alarm3
4
alarm3
alarm3
alarm3
5
done.

When the actual output is something like:

1
2
alarm1
3
alarm2
4
alarm3
alarm1
5
alarm3
done.
alarm3
alarm3
alarm3

Everything that should happen is happening, just not in the expected
order, or even in a consistent order from one test run to the  
next. It's

asynchronous code, so there isn't any guaranteed order.


It sounds like the tests shouldn't print but instead set flag  
variables and
then something at the end can check those flags and then report  
success or

failure.


Would it be useful to pipe the output through sort and then check for  
an exact string match?


Josh

Re: Extending Parrot NCI callback functionality

[Joshua Juran]

On Jan 16, 2008, at 7:39 PM, Geoffrey Broadwell wrote:


I am starting to implement a GLUT and OpenGL binding for Parrot.  GLUT
is extremely callback-oriented.

Unfortunately, none of the GLUT callbacks fall within the current
limitations on Parrot NCI callbacks.


As you've discovered, callbacks are easy enough to implement portably  
provided that an opaque pointer-sized value is one of the arguments  
-- you register a single C function, which uses information stored in  
the opaque structure to dispatch to the real handler -- and it's  
unfortunate that GLUT's callbacks don't support this.



So ... how can Parrot support callbacks of the types that GLUT uses?
The trick of putting magical properties on a special user data  
parameter
won't work anymore.  I've been tanking on this for a while, and  
come up

with several possible schemes.

My first idea was that each time a new callback was registered, Parrot
would copy a tiny shim function and then poke the address(es) of the
data it needed to figure out what PIR routine to call directly into  
the

copied shim code.


This requires special knowledge per platform.


So my next idea was to have a shim function that did nothing but call
another function, thus putting its own address on the stack.  The  
other

function would then reach up above its own stack frame and grab that
return address, using *that address* to look up the needed information
in a global callback registry.  By making copies of this simple shim
every time a new callback was registered, each copy would get its own
address, and everything would magically work.

This was certainly better than the previous ideas, because it didn't
involve poking anything into the shim code, just being able to copy  
it.


But it still requires per-platform support, at least for retrieving  
the stack frame pointer.



But I still don't know how to do that in pure portable C.  My guess is
that you could declare another function (which need not do  
anything) in
some special way so that it is guaranteed to be compiled into the  
object
code directly after the magic shim.  Subtracting the address of the  
shim

function from the dummy function would then tell you exactly how many
bytes long the compiled shim is (including perhaps some padding, which
doesn't matter).  This would allow you to copy the shim at will.


I've seen this done (so it 'works') but the underlying assumption  
isn't portable.



But this still leaves the problems of:

A. Being able to portably force two functions two be compiled
   sequentially in memory.  I would hope this is easy, but I don't
   recall which set of declarations makes exactly this guarantee.

B. Being able to execute a copy of the shim on architectures that have
   non-executable stack and/or heap.  I assume this had to be solved
   before JIT could work, so I'm guessing this isn't a real problem.

C. Being able to reach up above one's own stack frame and grab the
   return address from the shim function's dummy call.  Is there a
   trick to make this work in pure portable C?


No.  What you're trying to do can't be done portably.  Period.

However, once you place per-platform implementation on the table, it  
becomes simple (in theory, at least).  Rather than teach Parrot to  
cope with GLUT callbacks, I suggest a scheme for creating 'GLUT- 
prime' callbacks which accept the opaque structure pointer you're  
familiar with, which Parrot can already deal with.


For example:  Here's a callback interface that includes the opaque  
handle:


void generic_handler( void* user_data );

struct foo foo_data;

install_generic_handler( &generic_handler, &foo_data );

Here's one without:

struct bar bar_data;

typedef void (*handler)();

handler bar_handler = new_handler( &generic_handler, bar_data );

install_handler( bar_handler );

The new_handler() function creates a thunk that loads the data  
argument and jumps to the generic handler.  In 68K, the thunk code  
might (if it were written out) look like:


asm void thunk_zero_args()
{
MOVEA.L #$11223344,A0;  // load immediate handler address into 
A0
MOVE.L  #$55667788,-(SP);  // load immediate data pointer onto 
stack
JMP (A0)
}

asm void thunk_one_arg( void* arg1 )
{
MOVEA.L #$11223344,A0;  // load immediate handler address into 
A0
MOVE.L  #$55667788,-(SP);  // load immediate data pointer onto 
stack
MOVE.L  8(SP),-(SP);  // load previous arg 1 onto stack
JMP (A0)
}

asm void thunk_two_args( void* arg1, void* arg2 )
{
MOVEA.L #$11223344,A0;  // load immediate handler address into 
A0
MOVE.L  #$55667788,-(SP);  // load immediate data pointer onto 
stack
MOVE.L  12(SP),-(SP);  // load previous arg 2 onto stack