parrot, win32, stand-alone distribution, separate Parrot maillist
Valery A.Khamenya
are there any info on getting ready-to-try
Parrot for win32 as stand-alone distribution?
If win32 is not met yet, what are the milestones then?
What about separate Parrot maillist?
(I am really sorry, I am not interested in Perl,
but in Parrot)
thanks a lot.
--
Valery
Dan Sugalski
>Hi All,
>
> are there any info on getting ready-to-try
> Parrot for win32 as stand-alone distribution?
Not that I know of. If someone's got a working build and can put
together a tarball or zip file, we can get it up for download.
> What about separate Parrot maillist?
> (I am really sorry, I am not interested in Perl,
> but in Parrot)
This is the parrot mailing list--perl doesn't really get any more
talk than any other language targetting parrot. (Though I should get
the list namechange taken care of and out of the way)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Brent Dax
> are there any info on getting ready-to-try
> Parrot for win32 as stand-alone distribution?
If you mean precompiled binaries, not yet. Parrot is still under
development, so we aren't shipping binaries.
> What about separate Parrot maillist?
> (I am really sorry, I am not interested in Perl,
> but in Parrot)
The list is named "perl6-internals" mostly for historical reasons--the
discussion on it is almost exclusively Parrot. Dan has said that it will
eventually become something like "parrot-dev", but not yet.
--Brent Dax <br...@brentdax.com>
Perl and Parrot hacker
Jonathan Worthington
From: "Dan Sugalski" <d...@sidhe.org>
To: "Valery A.Khamenya" <kham...@mail.ru>; <perl6-i...@perl.org>
Sent: Monday, August 04, 2003 10:44 PM
Subject: Re: parrot, win32, stand-alone distribution, separate Parrot
maillist
> At 8:48 PM +0200 8/4/03, Valery A.Khamenya wrote:
> >Hi All,
> >
> > are there any info on getting ready-to-try
> > Parrot for win32 as stand-alone distribution?
>
> Not that I know of. If someone's got a working build and can put
> together a tarball or zip file, we can get it up for download.
I can most probably do this; I've got the latest CVS checkout compiled here.
What needs to go into the ZIP? My guesses are:-
- parrot executable
- imcc executable
- The docs directory
- The examples directory
- The languages directory
If you want regular (weekly? bi-weekly?) builds on Win32 zipping up and
FTPing somewhere, I can do that for you.
FYI, current test status on Win32:-
Failed Test Status Wstat Total Fail Failed List of Failed
----------------------------------------------------------------------------
----
t/op/gc.t 1 256 8 1 12.50% 2
t/pmc/io.t 3 768 18 3 16.67% 3-5
t/src/manifest.t 1 256 4 1 25.00% 4
24 subtests skipped.
Failed 3/53 test scripts, 94.34% okay. 5/841 subtests failed, 99.41% okay.
Don't know if this is supposed to happen (I don't recall seeing it before),
but I'm seeing this many times during the nmake proccess:-
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
cd classes && NMAKE && cd ..
I see it maybe 10-20 times in a row when I run both nmake and nmake test,
and always for that classes folder. nmake test also seems to do an implicit
nmake, even though I've just done that. I'm guessing that shouldn't happen?
I'm running Configure.pl with the options "--jitcapable=0 --execcapable=0",
'cus it won't build otherwise.
Later,
Jonathan
Valery A.Khamenya
Monday, August 4, 2003, 11:44:11 PM, you wrote:
DS> Not that I know of. If someone's got a working build and can put
DS> together a tarball or zip file, we can get it up for download.
nice. ... but sounds, strange for me as for newbie :-)
win32 is a platform and there should be some specific, platform
dependent code. How could it be "by chance"?
it is not kinda
C:\tmp\>perl Configure.pl
C:\tmp\>make
and go.
Or? :)
BTW, under cygwin "perl Configure.pl" fails.
DS> This is the parrot mailing list--perl doesn't really get any more
DS> talk than any other language targetting parrot. (Though I should get
DS> the list namechange taken care of and out of the way)
I was a bit confused looking for a Parrot's list. Some better hints
in top web entries would be good really for parrot-newbies like me.
P.S. guys, it is cool what you do. Lispers had 50 years in order to do
the same and never created something like that. Come'on, don't die
please!
--
Best regards,
Valery mailto:kham...@mail.ru
Valery A.Khamenya
BD> If you mean precompiled binaries, not yet. Parrot is still under
BD> development, so we aren't shipping binaries.
OK, clear.
well, what about win32 milestones?
BD> The list is named "perl6-internals" mostly for historical reasons--the
BD> discussion on it is almost exclusively Parrot. Dan has said that it will
BD> eventually become something like "parrot-dev", but not yet.
it would be good.
Valery A.Khamenya
Tuesday, August 5, 2003, 12:28:16 AM, you wrote:
JW> I can most probably do this; I've got the latest CVS checkout compiled here.
JW> What needs to go into the ZIP? My guesses are:-
JW> - parrot executable
JW> - imcc executable
JW> - The docs directory
JW> - The examples directory
JW> - The languages directory
JW> If you want regular (weekly? bi-weekly?) builds on Win32 zipping up and
JW> FTPing somewhere, I can do that for you.
well, I am not sure, what the due content should be, but it would be
really good, and not just for me! Guys, sitting at Perl you do a great
work for all dynamic languages. If you could make your first pages on
web more comprehensive for other non-PERLers then you could obtain
some help from outside I guess.
JW> FYI, current test status on Win32:-
?!
under cygwin?
JW> Don't know if this is supposed to happen (I don't recall seeing it before),
JW> but I'm seeing this many times during the nmake proccess:-
JW> Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
JW> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
JW> cd classes && NMAKE && cd ..
or using cl.exe/MSVC ?
"nmake" sounds quite strange with ultimate goal of portability, but
anyway.
Jonathan Worthington
> Tuesday, August 5, 2003, 12:28:16 AM, you wrote:
>
> JW> What needs to go into the ZIP? My guesses are:-
> JW> - parrot executable
> JW> - imcc executable
> JW> - The docs directory
> JW> - The examples directory
> JW> - The languages directory
> JW> If you want regular (weekly? bi-weekly?) builds on Win32 zipping up
and
> JW> FTPing somewhere, I can do that for you.
>
> well, I am not sure, what the due content should be, but it would be
> really good, and not just for me!
If others agree and let me know what should go in there, I'll do my best to
work something out. :-) However, Brent said "If you mean precompiled
binaries, not yet. Parrot is still under development, so we aren't shipping
binaries.", so I'm guessing maybe I shouldn't do a ZIP with the executables
in? But in that case I guess there's no point me doing anything like that
at all, as people can just get the latest CVS snapshot and Configure,
n?make, etc.
> Guys, sitting at Perl you do a great
> work for all dynamic languages. If you could make your first pages on
> web more comprehensive for other non-PERLers then you could obtain
> some help from outside I guess.
I think I heard something a while back to the effect that the parrot site
was being updated sometime soon, but I'm not sure.
> JW> FYI, current test status on Win32:-
>
> ?!
>
> under cygwin?
>
> JW> Don't know if this is supposed to happen (I don't recall seeing it
before),
> JW> but I'm seeing this many times during the nmake proccess:-
> JW> Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
> JW> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
> JW> cd classes && NMAKE && cd ..
>
> or using cl.exe/MSVC ?
Using nmake/cl, etc. Not cygwin, I haven't tried it in that, though I
*think* someone mentioned having parrot running successfully under cygwin on
the list at some point.
> "nmake" sounds quite strange with ultimate goal of portability, but
> anyway.
AFAIK, the makefiles that are generated from Configure can (theoretically)
work with nmake or whatever make program you have on the target platform, so
I don't see a portability problem. I may be completely wrong though!
Jonathan
Vladimir Lipskiy
> >Hi All,
> >
> > are there any info on getting ready-to-try
> > Parrot for win32 as stand-alone distribution?
>
> Not that I know of. If someone's got a working build and can put
> together a tarball or zip file, we can get it up for download.
>If you mean precompiled binaries, not yet. Parrot is still under
>development, so we aren't shipping binaries.
Yep. Parrot is under development and there is no out-of-the-box
win32 binaries, let alone the getting ready-to-try information.
But since you're from Russia the below information might be
some benefical to you.
Not long ago, Nick Kostirya and I started to cook our website
about Parrot in Russian, he prepared a win32 build of the latest CPAN
copy of Parrot 0.0.10 that we're planning to put on there. Also we got
about half the documents in parrot/docs translated into Russian and surely
you will see these have been thrown out at our site, too.
Ruefully, though, the website doesn't arrive at a spot of readiness where
it can be moved out in front of public. Let's wait till this September (~:
And if the Parrot team have time to release the new version of Parrot by
this
time, we will boil yet another zip file of the new win32 build, I hope.
The website will be at http://parrot.ks.ua When it's ready, I'll announce.
I could give you a email address to get in touch at him on account of
the binaries but he went on vacation and now is unget-at-able and
unable-to-hack-able. IIRC, he is not the only who's done the
work, Clinton Pierce did it some time ago.
Sean O'Rourke
> work something out. :-) However, Brent said "If you mean
> precompiled binaries, not yet. Parrot is still under development,
> so we aren't shipping binaries.",
This doesn't make sense to me. People who don't like hacking C can
still use a precompiled binary to hack in PASM or IMC. Heck, most of
the languages in languages/* are written in Perl -- no whatsoever to
configure and compile.
/s
Brent Dax
> work something out. :-) However, Brent said "If you mean precompiled
> binaries, not yet. Parrot is still under development, so we aren't
shipping
> binaries.", so I'm guessing maybe I shouldn't do a ZIP with the
executables
> in? But in that case I guess there's no point me doing anything like that
I wasn't saying "we shouldn't do it", I was saying that "at this point in
the development cycle we aren't doing it." I have neither the authority nor
the knowledge to set that kind of policy.
Translation: if Dan doesn't say otherwise, go ahead--it's not my call
anyway. :^)
(BTW, such a thing would actually help me now, while I'm away from my
toolkit...)
Melvin Smith
>Jonathan Worthington:
> > work something out. :-) However, Brent said "If you mean precompiled
> > binaries, not yet. Parrot is still under development, so we aren't
>shipping
> > binaries.", so I'm guessing maybe I shouldn't do a ZIP with the
>executables
> > in? But in that case I guess there's no point me doing anything like that
>
>I wasn't saying "we shouldn't do it", I was saying that "at this point in
>the development cycle we aren't doing it." I have neither the authority nor
>the knowledge to set that kind of policy.
>
>Translation: if Dan doesn't say otherwise, go ahead--it's not my call
>anyway. :^)
Dan is usually very happy when people volunteer to do things.
I would expect everyone would be happy if someone built
a Win32 distro. All that would be required of it is to pass the same
set of tests as the reference compile, if there is one.
It doesn't have to be the "official blessed by the Parrot team build" since
it is free software you can build it an call it anything you want as long
as you follow the copyright, just like ActiveState.
-Melvin
Leopold Toetsch
> What needs to go into the ZIP? My guesses are:-
> - parrot executable
> - imcc executable
These 2 executables are the same.
> - The docs directory
> - The examples directory
> - The languages directory
And Tests.
Anyway, MANIFEST should contain all necessary information in the right
column (though t/* isn't marked and we should ship tests).
> cd classes && NMAKE && cd ..
Same here on i386/linux. Dependency quirks or such ...
> Jonathan
leo
Dan Sugalski
>At 11:37 PM 8/4/2003 -0400, Brent Dax wrote:
>>Jonathan Worthington:
>>> work something out. :-) However, Brent said "If you mean precompiled
>>> binaries, not yet. Parrot is still under development, so we aren't
>>shipping
>>> binaries.", so I'm guessing maybe I shouldn't do a ZIP with the
>>executables
>>> in? But in that case I guess there's no point me doing anything like that
>>
>>I wasn't saying "we shouldn't do it", I was saying that "at this point in
>>the development cycle we aren't doing it." I have neither the authority nor
>>the knowledge to set that kind of policy.
>>
>>Translation: if Dan doesn't say otherwise, go ahead--it's not my call
>>anyway. :^)
>
>Dan is usually very happy when people volunteer to do things.
>I would expect everyone would be happy if someone built
>a Win32 distro. All that would be required of it is to pass the same
>set of tests as the reference compile, if there is one.
And this would be one of those cases. :) I'd be happy if someone with
a Win32 box could make regular snapshot builds. (If I had a spare x86
box I would, but alas I don't) There certainly are enough people
who'd like to play with Parrot but not mess around with C and, while
that's possible on most Unix platforms (since you get a C compiler
whether you like it or not) it isn't on Windows.
If someone wanted to take a look at the "make install" target as they
did this (yes, we do have one :) to make sure that what it provides
is sufficient, well, that'd be cool too.
Jonathan Worthington
thoughts on this, and I hope my efforts will be helpful.
> If someone wanted to take a look at the "make install" target as they
> did this (yes, we do have one :) to make sure that what it provides
> is sufficient, well, that'd be cool too.
In dev/tools/install_files.pl, I suspect the problem is in these lines:-
my %options = ( buildprefix => '',
prefix => '/usr',
exec_prefix => '/usr',
bindir => '/usr/bin',
libdir => '/usr/lib',
includedir => '/usr/include',
);
Is it as simple as checking whether the OS is Windows, and setting %options
to contain appropriate paths, e.g.
%options = ( buildprefix => '',
prefix => 'c:\parrot',
exec_prefix => 'c:\parrot',
bindir => 'c:\parrot\bin',
libdir => 'c:\parrot\lib',
includedir => 'c:\parrot\include',
);
As these directories may not exist in Windows, and I don't see anything that
creates non-existent directories, I believe I'll need to write something
that checks if they are there and creates them if they are not.
I'll put together a patch for this later tonight, unless anyone tells me I'm
on the wrong track before I get round to it. :-)
Jonathan
Jonathan Worthington
Sorting out make install on Win32 wasn't as simple as I'd first guessed, but
I'm getting there. I've now got it outputting 'correct' paths etc for Win32
to the makefile, and "tools/dev/install_files.pl" piping to "command" rather
than "sh" on Win32 as well. Now I've hit the next snag - there is no
install program under Win32. I see two possible approaches (and await
somebody to suggest the third, which will be perfect ;):-
1) Create a Perl script that resembles the functionality of install, then we
print:-
print "perl dev/tools/install.pl -d $_\n"; # If there is no install
program
2) Write Perl to implement that functionality directly into
dev/tools/install_files.pl if the install program is not available.
What's the best choice here?
Thanks,
Jonathan
Vladimir Lipskiy
> Is it as simple as checking whether the OS is Windows, and setting
%options
> to contain appropriate paths, e.g.
It's no use while checking if the OS is Windows, 'cause the distribution is
intended
for only Win 32 users. So you should predefine the hash below.
> %options = ( buildprefix => '',
> prefix => 'c:\parrot',
> exec_prefix => 'c:\parrot',
> bindir => 'c:\parrot\bin',
> libdir => 'c:\parrot\lib',
> includedir => 'c:\parrot\include',
> );
>
>As these directories may not exist in Windows, and I don't see anything
that
>creates non-existent directories, I believe I'll need to write something
>that checks if they are there and creates them if they are not.
IMHO, you better try tweaking some directories out of Perl.
So if I had my perl installed at D:\Perl\5.6.1, I would be overflowed
with joy having found your script installed Parrot as D:\Perl\Parrot
and be cussing if it woudn't be so.
Jonathan Worthington
From: "Vladimir Lipskiy" <fors...@kaluga.ru>
To: "perl6-internals" <perl6-i...@perl.org>; "Jonathan Worthington"
<jona...@jwcs.net>
Sent: Wednesday, August 06, 2003 1:47 AM
Subject: Re: Re[2]: parrot, win32, stand-alone distribution, separate Parrot
maillist
> > Is it as simple as checking whether the OS is Windows, and setting
> %options
> > to contain appropriate paths, e.g.
>
> It's no use while checking if the OS is Windows, 'cause the distribution
is
> intended
> for only Win 32 users. So you should predefine the hash below.
Sorry, looks like I've caused confusion. That bit of my email was about
getting "make install" to work when building from the source under Win32,
and not about the standalone distribution. I've made another post about the
"make install" issue now.
> IMHO, you better try tweaking some directories out of Perl.
> So if I had my perl installed at D:\Perl\5.6.1, I would be overflowed
> with joy having found your script installed Parrot as D:\Perl\Parrot
> and be cussing if it woudn't be so.
Now I'm not sure if you're talking about "make install" or my executable
distribution. :-) Executable distro, I plan that you will just unzip it
where you want it. As for make install, I agree; it does need to allow the
user to choose where it will be put. Would that be done as a flag on the
configure script (maybe it's already implemented?), or when you do make
install, e.g. something like:-
make install PREFIX=D:\Perl\Parrot
Hope this helps,
Jonathan
Vladimir Lipskiy
> where you want it.
Shucks, my bad (~: For a moment, I was totally convinced
that we did need to make install the distro (~: Sorry.
>Sorry, looks like I've caused confusion. That bit of my email was about
>getting "make install" to work when building from the source under Win32,
>and not about the standalone distribution. I've made another post about
the
>"make install" issue now.
Yeah. These threads mixed up in my head (~:
Vladimir Lipskiy
> Sorting out make install on Win32 wasn't as simple as I'd first guessed,
but
> I'm getting there. I've now got it outputting 'correct' paths etc for
Win32
> to the makefile, and "tools/dev/install_files.pl" piping to "command"
Wait a minute. Could we pipe to anything under dos?
>I see two possible approaches (and await
>somebody to suggest the third, which will be perfect ;):-
Have a look at ExtUtils::MakeMaker
Piers Cawley
> At 8:48 PM +0200 8/4/03, Valery A.Khamenya wrote:
>>Hi All,
>>
>> are there any info on getting ready-to-try
>> Parrot for win32 as stand-alone distribution?
>
> Not that I know of. If someone's got a working build and can put
> together a tarball or zip file, we can get it up for download.
>
>> What about separate Parrot maillist?
>> (I am really sorry, I am not interested in Perl,
>> but in Parrot)
>
> This is the parrot mailing list--perl doesn't really get any more talk
> than any other language targetting parrot. (Though I should get the
> list namechange taken care of and out of the way)
So long as the mail to it keeps going to perl6-all...
Personally, I'm not that keen on changing the name, but if that's what
people want.
--
Piers