Chromatic, All,
Fair enough. What with the recent merges, and maybe a problem with
PMC** in the pmc compiler, I've not had a chance to recut the patch.
Since about 1/3 time seemed to be spend in the GC (and some more in
memory allocation), this is one area where huge wins might be
possible. (Some
NotFound,
That would look cleaner, wouldn't it? I'll give it a go.
Nick
On Thu, Oct 2, 2008 at 3:35 PM, NotFound <[EMAIL PROTECTED]> wrote:
> I think will be better the other way, using the return value to flag
> existence, and passing a pointer to store the result. This will allow
> shorter and
All,
Sorry, I see that I said opcode a new times, when of course I meant
PMC vtable entry.
Nick
ere aren't many
objects to consider, and it seems to have only shaved off 5% or so
(not the 20 or so I was hoping for).
Will see if I can improve things over the coming days.
Nick
On Mon, Sep 29, 2008 at 5:28 PM, Andrew Whitworth <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 29, 2008 at 12:15
Hi all,
I've given the perl6 wiki 'november'
(http://github.com/viklund/november/tree/master) a go out of
curiosity, and being surprised at the run times (page 35 of
http://viklund.pp.se/november.pdf) have done some profiling using
valgrind.
For the test case all I've been using is running test_w
Hi All!
On 28/03/07, Ron Blaschke <[EMAIL PROTECTED]> wrote:
Joshua Gatcomb wrote:
> On 3/26/07, Ron Blaschke <[EMAIL PROTECTED]> wrote:
>>
>> Not sure about the details of this issue, but r17772 seems to build fine
>> on Cygwin.
>
> Really? No one on #parrot has been able to get parrot to work
On 02/08/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On 8/2/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> Am Mittwoch, 2. August 2006 19:52 schrieb [EMAIL PROTECTED]:
> > > There must be some other problem elsewhere.
> >
> > Found the problem... it was MY problem... I had rests of an ol
On 06/04/06, Sean Sieger <[EMAIL PROTECTED]> wrote:
> Is parrot broken? I am getting an error that reads,
> config.fpmc is truncated.
You'll probably find that runtime/parrot/include/config.fpmc is zero
bytes, in which case try removing it and rerunning make. If the
problem persists, there's a pro
e a bit of thought
to the problem. My solution is either to remove -L's which Perl
supplies, or move them later in the link line)
Nick
On 27/03/06, Andrew Dougherty <[EMAIL PROTECTED]> wrote:
> On Mon, 27 Mar 2006, Nick Glencross wrote:
>
> > On 26/03/06, Sean Sieger <[EMAIL
On 26/03/06, Sean Sieger <[EMAIL PROTECTED]> wrote:
> On 3/25/06, Nick Glencross <[EMAIL PROTECTED]> wrote:
>
> > Is it possible that a 'make install' has previously been done on this
> > computer, so that there is a libparrot in /usr/local/lib?
>
&
On 25/03/06, Sean Sieger <[EMAIL PROTECTED]> wrote:
> I cannot get Parrot from svn on Ubuntu 5.10 Server to run:
>
> parrot: error while loading shared libraries: libparrot.so.0.4.2: cannot
> open shared object file: No such file or directory
Sean,
I did briefly see this mentioned on pugs IRC the
On 2/20/06, Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 21, 2006 at 10:06:36AM +1100, Sisyphus wrote:
> > Yes, /usr/local/lib is already in /etc/ld.so.conf.
>
> Perhaps you need to run `ldconfig` as root.
>
> > $LD_LIBRARY_PATH is initially empty. If I don't add '/usr/local/lib' to it,
On 2/20/06, Sisyphus <[EMAIL PROTECTED]> wrote:
> Oh one other thing on Linux I had to add (the standard location)
> /usr/local/lib to LD_LIBRARY_PATH. I've not had to do that before ... and
> the README suggests that I shouldn't have to do it wrt parrot. It says:
>
> "But please note th
Leopold Toetsch (via RT) wrote:
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #38429]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38429 >
Platform x86/linux
Compiling a static Parrot sim
Leopold Toetsch wrote:
I've unapplied r11320.
* revert the whole patch
* some of it might be correct, though, please review
And a final note: please no checkins w/o testing, especially not for
config and build stuff. Thanks.
My apologies for causing breakage -- pretty serious breakage by th
Even with r11320, the extend tests are failing with linkage errors on
cygwin. I note that extend.h does not have PARROT_APIs in it. Should
it by right? (It's possible that extend.o is linked with directly)
I'm tempted as a short term fix to remove the sym_import/export
(cygwin) hints. Would anyone
I have committed a fix in r11320 so that the build doesn't pick up
system-wide libparrots, which has certainly been the cause of some
linkage problems over the last few days.
[As background, since my previous email didn't make it into RT, the
circumstances for this are:
* A system-wide libparro
Nick Glencross wrote:
There seem to be a few recent events which can now trigger a newish
problem:
The real problem is that -L/usr/local/lib is brought in from parrot,
so we have a few choices:
* Just remove -Ls brought in from 'lddflags', which seems safe to
me, or
*
Jonathan Worthington wrote:
"Greg Bacon" <[EMAIL PROTECTED]> wrote:
I'm still seeing a link failure with r11221.
Discovered I have cygwin on this PC, went to investigate
and..the link failure is gone as well as the
auto-import warnings. Sadly, there's a new problem that I really have
n
On 1/13/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> "Greg Bacon" <[EMAIL PROTECTED]> wrote:
> > Not quite. At r11144 on Cygwin, I see
> >
> > [...]
> > gcc -o miniparrot.exe -s -L/usr/local/lib compilers/imcc/main.o \
> > -L/home/gbacon/src/parrot/blib/lib -lparrot -lcrypt src/null_con
Greg Bacon (via RT) wrote:
# New Ticket Created by Greg Bacon
# Please include the string: [perl #38216]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38216 >
There appears to have been some slop in the ${foo} -> @foo@
On 1/10/06, Nick Glencross <[EMAIL PROTECTED]> wrote:
> On 1/10/06, Nick Glencross <[EMAIL PROTECTED]> wrote:
> > On 1/10/06, via RT Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
> > > # New Ticket Created by Joshua Hoblitt
> > > # Please include the strin
On 1/10/06, Nick Glencross <[EMAIL PROTECTED]> wrote:
> On 1/10/06, via RT Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
> > # New Ticket Created by Joshua Hoblitt
> > # Please include the string: [perl #38197]
> > # in the subject line of all future corresponde
On 1/10/06, via RT Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Joshua Hoblitt
> # Please include the string: [perl #38197]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/rt3/Ticket/Display.html?id=38197 >
>
>
> Using pkg-conf
On 1/10/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> "Jonathan Worthington" <[EMAIL PROTECTED]> wrote:
> > Note that dynamic op libs do not *work* on Win32 yet
> They do now - I'm using them with my .NET to PIR translator and they work
> nicely.
>
> I would really like some feedback from M
On 1/10/06, Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 10, 2006 at 01:06:29AM +0000, Nick Glencross wrote:
> > Joshua Hoblitt (via RT) wrote:
> >
> > >Parrot should support pkgconfig by installing a pc data file. It should
> > >probably be named
Joshua Hoblitt (via RT) wrote:
Parrot should support pkgconfig by installing a pc data file. It should
probably be named parrot.pc.
Ok, I can do this. I've had an initial stab at it, and one thing that
I've had to do is provide a quoting mechanism into the configuration
file substitution bec
(I've missed the window to get this into 0.41, but not a problem)
This cygwin patch is now required as both static and shared versions
of libparrot being built (which they weren't when I first wrote the
patch which went in last night).
Strangely, cygwin ld prefers to link with libparrot.a in pref
On 1/8/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> "Nick Glencross" <[EMAIL PROTECTED]> wrote:
> > I'd appreciate a few volunteers to try out this patch and make sure that
> > it doesn't break building on your favourite platform.
> >
I'd appreciate a few volunteers to try out this patch and make sure that
it doesn't break building on your favourite platform.
A similar change to the one in dynclasses_pl.in may be required in
application directories at some point to run on certain win32 flavours
(e.g. mingw).
Cheers,
Nick
On 1/6/06, Alberto Simões <[EMAIL PROTECTED]> wrote:
>
> Probably, I'm doing something wrong... but this is the output compiling
> parrot on my cygwin...
>
> http://nopaste.snit.ch:8001/6180
I've seen more talk on cygwin in the last week or two than in the last year!
Yes, building the dynamicall
This patch does a check for the existence of the 'rpath' attribute before using it.There will be platforms which have dynamic loading, but no capability to hard code the path of the library into the executable. We therefore need to cater for the case where parrot_is_shared is set, but rpath is not.
This patch adds the necessary hints for HP-UX to build using shared libraries by default.I only have access to gcc on HP-UX, but the necessary compiler flags for the HP commericial compiler are there too.Cheers,
Nick
Index: config/init/hints/hpux.pm
=
Guys,
I've been wanting to relax the dependency that parrot's core has on
parrot_config. As things stand at the moment, src/global_setup.c makes
a call to parrot_get_config which is linked into the executable itself
by selecting either null_config.o, parrot_config.o or
install_config.o.
Qu
blib/lib/libparrot.a. Also it's an advantage to have both static and
> shared libraries installed. Executables are linked against one of them,
> preferably the shared one.
>
> Here's a patch that addresses this issue that ^conner already raised
> when Nick Glencross poste
On 1/5/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> Nick Glencross wrote:
> > The first patch modifies the parrot VM so as not to call
> > parrot_get_config_string on startup, which currently resides in the
> > calling executable. Instead, the
Guys,
I shall shortly update the relevant calls, but I'd just like to check
a few things first.
These patches update the patches in #37303 and #36836, relating to
parrot_get_config_string and cygwin dynclasses.
The first patch modifies the parrot VM so as not to call
parrot_get_config_string on
Thanks to everyone, particularly rafl, for getting shared libraries
in. I hope that it hasn't been too painful, and that we get support
for most platforms.
Here's a patch which provides initial support for Darwin. I've only
just got a Mac, so am learning as I go along (e.g.
http://fink.sourceforge
Guy,
There are a few red splodged in smoke on HP-UX which I can elaborate on.
The actual line causing problems is list.c:1042 (r10861) , and I
suspect are caused by pointer alignment, but frustratingly gdb doesn't
help much.
# ./parrot t/pmc/floatvalarray_4.pasm
Bus error(coredump)
A typical ba
This tidy patch makes cwd work on HP-UX. As it stands at the moment it
gives an 'invalid argument' exception (although it gave a more
meaningful message earlier this morning).
The manual page for getcwd says:
If buf is a NULL pointer, getcwd() obtains size bytes of space using
malloc(
On 12/27/05, Peter Schwenn <[EMAIL PROTECTED]> wrote:
> Dear Nick
>
> thanks. by the way how does one signal Pugs that Parrot is to be used
> "Externally".?
Although I've played with pugs for a few hours, it was on Linux, and I
didn't get around to investigating the backends (especially as the
pa
On 12/26/05, jerry gay <[EMAIL PROTECTED]> wrote:
> cygwin *should* compile parrot just fine. the last report i see on
> http://smoke.parrotcode.org/smoke/ for i386-cygwin-gcc is from r10487,
> which is a few weeks old, though. can any other cygwin users confirm
> peter's report? there have been so
On 12/25/05, Nick Glencross <[EMAIL PROTECTED]> wrote:
> Guys,
Sorry, it wasn't intentional that I was sending HTML emails; only just noticed.
Nick
Guys,
On 12/24/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 24, 2005, at 21:07, Nick Glencross wrote:
>
> > ... The configuration comes when the application is additionally linked
> > with null_config.o, parrot_config.o or install_config.
>
&
On 12/23/05, Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
>
> Below are my thoughts on this patch in it's current form.
>
> I don't like the function of ld_libparrot_soname because it has the
> soname mixed up with the linker flags. I'd rather see something like
> ld_soflags and libparrot_soname (I d
On 12/23/05, Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
>
> Nick,
>
> I'll try to take a look at all of this patch today. Quick questions -
> why is:
>
> +src/install_config.o [main]lib
>
> being added to MANIFEST.generated?
>
> -J
>
>
Let me explain my reasoning on this
Nick Glencross wrote:
Guys,
Here's an updated version of the libparrot shared library patch.
Sorry, omitted one of the configure files!
I should mention that you probably want to remove
config/inter/libparrot.pm before ever reapplying the patch otherwise
you'll get the same con
Guys,
Here's an updated version of the libparrot shared library patch. It
primarily adds back the functionality for SOVERSION. To do this I have
created two new compile flags which will usually be set in the platform
hints.
* ld_libparrot_soname: Supplied to ld to set the library version o
On 12/23/05, François PERRAD <[EMAIL PROTECTED]> wrote:
>
> OK with static on Win32 + gcc (MinGW).
>
> Shared on Win32, always the same linking problem with
> parrot_get_config_string()
> (see https://rt.perl.org/rt3/Ticket/Display.html?id=37303)
>
> g++ -shared -o blib\lib\libparrot.dll ...
>
>
On 12/22/05, Florian Ragwitz <[EMAIL PROTECTED]> wrote:
>
> On Thu, Dec 22, 2005 at 12:51:39PM +, Nick Glencross wrote:
> > I'd like to revive this patch which I posted a while back, but has
> > needed bringing up to date due to subsequent changes.
>
&g
Guys,
I'd like to revive this patch which I posted a while back, but has
needed bringing up to date due to subsequent changes.
It has a few key intentions:
* Makes libparrot.so a 'first class citizen'
* Allows the installed version of parrot and its utilities to be
either shared or static
On 12/21/05, via RT Justin Koser <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Justin Koser
> # Please include the string: [perl #37997]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/rt3/Ticket/Display.html?id=37997 >
>
>
> Hello Parrot hac
jerry gay wrote:
it seems punie's using way too much memory. in fact, it's running out
of memory on my 512MB system, and peaks at 480MB usage during PAST
generation on my machine with 1.5GB. these are win32, using msvc, and
the command i ran was ...
Seems like way too much memory considering th
Leopold Toetsch wrote:
- please test on all available platforms and 'make smoke' and/or
update PLATFORMS
With the recent Stash changes and (I presume) a fix to avoid reloading
pbc files, we're passing all tests on HP-UX!
Something's happened to spoil languages in the last day, but I don't b
On 11/16/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Nick Glencross wrote:
> > coroutine_3.pasm seems to have some problems with scratchpads, but I
> > don't know whether the problem is with parrot or the test.
>
> > ==15739== Thread 1:
> > ==15739=
coroutine_3.pasm seems to have some problems with scratchpads, but I
don't know whether the problem is with parrot or the test.
In line 105 of lexical.c (r10019) there is a buffer being overflowed
because the buffer for base is larger than pad_pmc.
valgrind reports 4 occurrences of this for t
Roger Browne wrote:
Nick Glencross wrote:
.hll_debug_end line
.hll_debug_begin line 2
I don't think the "end" directives add much. There's almost always going
to be an "end line" before a "begin line", so why not let 'begin line'
On 11/14/05, Nick Glencross <[EMAIL PROTECTED]> wrote:
> Jonathan Worthington wrote:
>
> > I'm looking to work
> > on enabling Parrot to store away HLL debug info - that is, the file name,
> > line number, columns etc in the high level language source code. Thi
[Disclaimer: I've only just started thinking about this in the last
hour, and don't want to appear all knowledgeable or anything!]
On 11/14/05, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> My current thinking on this is that a HLL will define a sub that knows how
> to print errors for that HL
[Sorry if this doesn't thread in your reader]
Jonathan Worthington wrote:
> I'm looking to work
> on enabling Parrot to store away HLL debug info - that is, the file name,
> line number, columns etc in the high level language source code. This data
> can then be used to emit useful error message
Nick Glencross wrote:
A few new red splodges have appeared on the HP-UX smokes. In future
does it seem helpful if I investigate these?
I've just had a quick look at some of them now:
freeze_26/27: exposes a potential problem in the imcc optmiser which I
also see in valgrind on Linu
A few new red splodges have appeared on the HP-UX smokes. In future
does it seem helpful if I investigate these?
I've just had a quick look at some of them now:
freeze_26/27: exposes a potential problem in the imcc optmiser which I
also see in valgrind on Linux. In try_allocate, mem_sys_allocate
On 11/5/05, Joshua Hoblitt via RT <[EMAIL PROTECTED]> 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 (
Here's another update to the ffcall POC that I posted a week or two
ago. It's now got a Configure test to work out which backend to use
(and an --ask option to override).
It still needs more work (which is fine as there's a feature freeze),
and some work on memory allocation and stuff. I also need
Garrett Goebel wrote:
Nick Glencross wrote:
As mentioned on the list yesterday I started evaluating ffcall
as a way of providing NCI functionality.
http://www.haible.de/bruno/packages-ffcall.html
I actually really like the current NCI implementation, although
it suffers from a large nci.c
Nick Glencross wrote:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way of providing NCI functionality.
Ok, here's an updated version with (hopefully) working callbacks -- at
least enough for a POC.
If you tried out my previous version, run 'rm
Leopold Toetsch wrote:
On Oct 30, 2005, at 1:54, Nick Glencross wrote:
Quick question...
I've been looking through inter_run and extend to see how to pass
arguments to a parrot method/function from C, but all the prototypes
that I've seen have '...' or 'va_list
Quick question...
I've been looking through inter_run and extend to see how to pass
arguments to a parrot method/function from C, but all the prototypes
that I've seen have '...' or 'va_list' to accept the arguments.
If I don't know what the arguments or their respective types are at
compile
Leopold Toetsch wrote:
On Oct 28, 2005, at 22:22, Nick Glencross wrote:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way of providing NCI functionality.
http://www.haible.de/bruno/packages-ffcall.html
I've downloaded it and had a short look into so
Nick Glencross wrote:
Nick Glencross wrote:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way of providing NCI functionality.
I seem to be seeing rather strange, and it's probably a
misunderstanding on my part.
Ok, I see what the problem is. PMC_data(
Nick Glencross wrote:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way of providing NCI functionality.
I seem to be seeing rather strange, and it's probably a misunderstanding
on my part.
I've pinched the GET_NCI_x(n) macros and accompanying
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a way
of providing NCI functionality.
http://www.haible.de/bruno/packages-ffcall.html
I actually really like the current NCI implementation, although it
suffers from a large nci.c file and all the usable prototypes need
Leopold Toetsch wrote:
On Oct 27, 2005, at 22:31, Nick Glencross wrote:
There are a few cases of -1 being assigned to unsigneds. Anyone know
if that's deliberate?
Yup. Some special out-of-band values.
I thought as much. Nothing to worry about there then...
One other thing I forg
Gabriel Dos Reis wrote:
Matt Fowles <[EMAIL PROTECTED]> writes:
| Nick~
|
| On 10/26/05, Nick Glencross <[EMAIL PROTECTED]> wrote:
| > Guy,
| >
| > As a follow-up to a discussion a few days ago about binding parrot to
| > C++ functions, is making it possible to
Leopold Toetsch wrote:
On Oct 25, 2005, at 23:32, Nick Glencross wrote:
I was looking at callbacks the other evening. Am I right in thinking
that only two callback prototypes are supported, or have I missed a
trick there as well?
That's right. There are 2 callbacks (functions w
Guy,
As a follow-up to a discussion a few days ago about binding parrot to
C++ functions, is making it possible to compile parrot with a C++
compiler a 'Bad Thing'?
If anything, it should strengthen the code base. I had a dabble a few
weeks ago to see how big a job it would be, and quickly c
Leopold Toetsch via RT wrote:
On Oct 23, 2005, at 17:08, Nick Glencross (via RT) wrote:
Guys,
call_list.txt lists 'T' and 'L' as being prototypes for passing arrays
to nci functions, but no implementation exists in build_nativecall.pl.
This patch provides an implementa
On 10/19/05, Bernhard Schmalhofer via RT
<[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] - Mi 19. Okt 2005, 08:05:56]:
>
> > Configure picks up the osname of a cygwin system as 'thread' which
> > isn't very helpful (see the smoke screen). This patch does something
> > similar to other platforms an
Strange... I could have sworn I attached the patch. Here it is.
Nick
Index: runtime/parrot/library/pcre.imc
===
--- runtime/parrot/library/pcre.imc (revision 9513)
+++ runtime/parrot/library/pcre.imc (working copy)
@@ -52,6 +5
Nick Glencross (via RT) wrote:
More low hanging fruit.
This patch provides pcre.imc with the correct DLL name for libpcre,
enabling the pcre.t tests to pass.
Note: This patch has #37481 as a prerequisite to provide the correct osname.
I'm pretty sure that I attached the patch, but a
Leopold Toetsch wrote:
Nick Glencross wrote:
Let me try reposting the patch, which gives me the opportunity to bit
twiddle a bit more:
* Removed the mmap nonsense which was sent by accident
* Renamed config.c to config_string.c to make it less generic
* Moved a couple externs from a
For starters, it gives you a libparrot which doesn't have any external
dependencies. Much nicer, if only aesthetically.
Nick
On 10/18/05, Joshua Hoblitt via RT <[EMAIL PROTECTED]> wrote:
> Chip,
>
> Looks like a design call.
Let me try reposting the patch, which gives me the opportunity to bit
twiddle a bit more:
* Removed the mmap nonsense which was sent by accident
* Renamed config.c to config_string.c to make it less generic
* Moved a couple externs from a core parrot library into the main
executable, where
I promptly sent a follow-up after I spotted this, but it didn't seem
to make it into RT. Well spotted! (I'd been checking that an
HP-UX-related patch didn't break things)
I also think that it would also be cleaner to move the lines
const char* parrot_config_ptr;
unsigned int parrot_config_size;
Here's an updated version of a patch to change how parrot picks up its
built-in configuration values. They are currently picked up by the
parrot library through globals linked against the executable.
This patch changes the API so that the parrot environment starts without
a config (which makes
eval_12.pir is one of the few tests which are failing on HP-UX. It
writes some bytecode to a file and executes it, and then does it again
with a slight variation.
Running the test gives:
# ./parrot t/pmc/eval_12.pir
hello from foo_1
Parrot VM: Can't mmap file /var/tmp/build/src/parrot_hpux/./t
Guys,
Nothing too much to this patch. A fix to a couple of typos
('unimplemented' and 'too') and a few paths in examples.
Regards,
Nick
Index: src/pmc_freeze.c
===
--- src/pmc_freeze.c(revision 9465)
+++ src/pmc_freeze.c(
Nick Glencross wrote:
Guys,
I have tried to submit a smoke from cygwin, but the server does not
accept the smoke file (which I've attached).
Can someone in-the-know about what criteria the server uses shed any
light on it? I note that the file is bzip'd whereas on Linux it
Joshua Hoblitt via RT wrote:
As a general comment, 36119 makes me a little nervous as 'chmod' isn't
something you can count on unless your on a POSIX like system and osname
ne 'MSWin32' certainly would encompass non-POSIX systems. Are you
planning on retool this patch to be more pedantic about
Joshua Hoblitt via RT wrote:
-copy("$_$LOAD_EXT", $dest) or die "Copy $_$LOAD_EXT failed ($?)\n";
+File::Copy::syscopy("$_$LOAD_EXT", $dest) or die "Copy $_$LOAD_EXT failed
($?)\n";
Certainly on cygwin File::Copy::syscopy also seems to lose execute
permissions, despite what th
Here (hopefully) is the generated smoke file which might hold some clues...
Nick
Nick Glencross wrote:
Guys,
I have tried to submit a smoke from cygwin, but the server does not
accept the smoke file (which I've attached).
Can someone in-the-know about what criteria the server uses
Strange, something has stripped the attachment (I didn't forget to
attach it, honest!). I'll try again in a few hours using SMTP instead of
NNTP.
Nick
Nick Glencross wrote:
Guys,
I have tried to submit a smoke from cygwin, but the server does not
accept the smoke file (
Guys,
I have tried to submit a smoke from cygwin, but the server does not
accept the smoke file (which I've attached).
Can someone in-the-know about what criteria the server uses shed any
light on it? I note that the file is bzip'd whereas on Linux it is gzip'd.
For the record, after runnin
Joshua Gatcomb wrote:
--- Joshua Hoblitt via RT
<[EMAIL PROTECTED]> wrote:
Can you still recreate this issue?
I haven't been involved in Parrot development for some
time now. When I was involved I was pretty much the
only Cygwin user actively participating so it was
frustrating not
Joshua Hoblitt via RT wrote:
[nickg - Thu Apr 14 15:12:00 2005]:
Here's another odd one, which looks const-related. Uncommenting the '+='
line causes a compile error when 'c' is subsequently used.
It looks like there is still support for .const in the lexer. Is this
still an issue?
I did t
Leopold Toetsch wrote:
Nick Glencross wrote:
I haven't seen this mentioned on the list, and it might be widely
known... on i386 linux there are two core dumps left behind after a
make test.
Well, there are several TODO tests, which execute and fail more or
less deadly. That
Guys,
This preliminary patch aims to add better support for a shared libparrot
library (don't apply it yet!).
* First I've added config/inter/libparrot.pl to interactively prompt
for whether a shared library should be built. This can be defaulted by
platform hints (defaulting off for now, w
I haven't seen this mentioned on the list, and it might be widely
known... on i386 linux there are two core dumps left behind after a make
test.
I believe one to be NCI related (japh_10.pasm).
(gdb) where
#0 0x0812f738 in clone_regs_interp (d=0x0, s=0x8276d88, dest=0x843ca98)
at parrotinte
s issue.
> # https://rt.perl.org/rt3/Ticket/Display.html?id=37303 >
>
>
> - Forwarded message from Nick Glencross <[EMAIL PROTECTED]> -
>
> From: Nick Glencross <[EMAIL PROTECTED]>
>
> Guys,
>
> I've been wanting to relax the dependency
Guys,
I've been wanting to relax the dependency that parrot's core has on
parrot_config. As things stand at the moment, src/global_setup.c makes
a call to parrot_get_config which is linked into the executable itself
by selecting either null_config.o, parrot_config.o or
install_config.o.
This work
1 - 100 of 195 matches
Mail list logo
