Re: [perl #41095] [BUG] Segfault in test.exe during Configuration
Windows 2000 SP4 Visual Studio 2003 SP1 The hardware is: Pentium MMX (586) with 128mb ram. The problem with the test file is that it does not work reliably for the processors that do not support the fcomip cpu instruction (586 and earlier). I tried to fix this myself by using CPUID, but I don't have enough knowledge and also I don't know how to handle the non-x86 CPUs (because they don't support CPUID). - Original Message - From: Will Coleda [EMAIL PROTECTED] To: Nikolay Ananiev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, December 07, 2008 6:57 PM Subject: Re: [perl #41095] [BUG] Segfault in test.exe during Configuration Thanks - can you also let us know the following: What version of windows are you using? Which compiler (including version)? On Sat, Dec 6, 2008 at 11:47 AM, Nikolay Ananiev [EMAIL PROTECTED] wrote: Tested with r33568. The bug is still there. - Original Message - From: Will Coleda via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 03, 2008 10:00 PM Subject: [perl #41095] [BUG] Segfault in test.exe during Configuration Can someone test this with a recent parrot? Based on a recent conversation on list, we should probably start getting OS / Compiler versions as well with bug reports. On Wed Apr 16 14:58:24 2008, [EMAIL PROTECTED] wrote: Confirmed. This bug is still there as of r27009 Nikolay Ananiev [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'll be able to test Parrot in the next 48 hours on my pentium mmx and tell you what the result is. - Original Message - From: James Keenan via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 14, 2008 5:36 AM Subject: [perl #41095] [BUG] Segfault in test.exe during Configuration Jonathan: Do you know if we've overcome this problem? Thank you very much. kid51 -- Will Coke Coleda -- Will Coke Coleda
Re: [perl #41095] [BUG] Segfault in test.exe during Configuration
Tested with r33568. The bug is still there. - Original Message - From: Will Coleda via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 03, 2008 10:00 PM Subject: [perl #41095] [BUG] Segfault in test.exe during Configuration Can someone test this with a recent parrot? Based on a recent conversation on list, we should probably start getting OS / Compiler versions as well with bug reports. On Wed Apr 16 14:58:24 2008, [EMAIL PROTECTED] wrote: Confirmed. This bug is still there as of r27009 Nikolay Ananiev [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'll be able to test Parrot in the next 48 hours on my pentium mmx and tell you what the result is. - Original Message - From: James Keenan via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 14, 2008 5:36 AM Subject: [perl #41095] [BUG] Segfault in test.exe during Configuration Jonathan: Do you know if we've overcome this problem? Thank you very much. kid51 -- Will Coke Coleda
Problem building parrot
I'm trying to build parrot r31477 with visual studio 2008 on vista home and
i get the following error
src\pmc\exceptionhandler.c
.\src\pmc\exceptionhandler.pmc(34) : error C2275:
'Parrot_ExceptionHandler_attri
butes' : illegal use of this type as an expression
d:\dev\projects_out\parrot\src\pmc\pmc_exceptionhandler.h(109) : see
dec
laration of 'Parrot_ExceptionHandler_attributes'
.\src\pmc\exceptionhandler.pmc(34) : error C2059: syntax error : 'const'
.\src\pmc\exceptionhandler.pmc(40) : error C2065: 'core_struct' : undeclared
ide
ntifier
.\src\pmc\exceptionhandler.pmc(40) : warning C4047: '=' : 'DPOINTER *'
differs i
n levels of indirection from 'int'
.\src\pmc\exceptionhandler.pmc(41) : error C2065: 'core_struct' : undeclared
ide
ntifier
.\src\pmc\exceptionhandler.pmc(41) : error C2223: left of '-min_severity'
must
point to struct/union
.\src\pmc\exceptionhandler.pmc(42) : error C2065: 'core_struct' : undeclared
ide
ntifier
.\src\pmc\exceptionhandler.pmc(42) : error C2223: left of '-max_severity'
must
point to struct/union
.\src\pmc\exceptionhandler.pmc(43) : error C2065: 'core_struct' : undeclared
ide
ntifier
.\src\pmc\exceptionhandler.pmc(43) : error C2223: left of '-handled_types'
must
point to struct/union
.\src\pmc\exceptionhandler.c(106) : error C2143: syntax error : missing '{'
befo
re '*'
.\src\pmc\exceptionhandler.c(108) : warning C4431: missing type specifier -
int
assumed. Note: C no longer supports default-int
.\src\pmc\exceptionhandler.c(108) : warning C4142: benign redefinition of
type
.\src\pmc\exceptionhandler.pmc(147) : warning C4057: 'return' : 'int *'
differs
in indirection to slightly different base types from 'opcode_t *'
.\src\pmc\exceptionhandler.pmc(232) : warning C4098:
'Parrot_ExceptionHandler_nc
i_min_severity' : 'void' function returning a value
.\src\pmc\exceptionhandler.pmc(251) : warning C4098:
'Parrot_ExceptionHandler_nc
i_max_severity' : 'void' function returning a value
.\src\pmc\exceptionhandler.c(1215) : warning C4057: 'initializing' :
'invoke_met
hod_t' differs in indirection to slightly different base types from 'int
*(__cde
cl *)(Parrot_Interp,PMC *,void *)'
.\src\pmc\exceptionhandler.c(1376) : warning C4057: 'initializing' :
'invoke_met
hod_t' differs in indirection to slightly different base types from 'int
*(__cde
cl *)(Parrot_Interp,PMC *,void *)'
NMAKE : fatal error U1077: 'D:\dev\vms\perl5.10\bin\perl.exe' : return code
'0x2
'
Stop.
Questions about GSOC
Hey guys, Today I saw Andrew's last post in his blog about the end of gsoc. Since I could not find much information about the NCI and GC projects I'm asking here: What's the status of these projects? Andrew's last post seems discouraging. How much of the new GC is completed? Are we going to have a new GC this year? What are the main problems that remain and have to be solved? And about the NCI project... I couldn't find any information about it. What's going on there?
Re: [perl #41095] [BUG] Segfault in test.exe during Configuration
Confirmed. This bug is still there as of r27009 Nikolay Ananiev [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'll be able to test Parrot in the next 48 hours on my pentium mmx and tell you what the result is. - Original Message - From: James Keenan via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 14, 2008 5:36 AM Subject: [perl #41095] [BUG] Segfault in test.exe during Configuration Jonathan: Do you know if we've overcome this problem? Thank you very much. kid51
Re: [perl #41095] [BUG] Segfault in test.exe during Configuration
I'll be able to test Parrot in the next 48 hours on my pentium mmx and tell you what the result is. - Original Message - From: James Keenan via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 14, 2008 5:36 AM Subject: [perl #41095] [BUG] Segfault in test.exe during Configuration Jonathan: Do you know if we've overcome this problem? Thank you very much. kid51
Re: mod_perl6 update
You've hit different child processes. James E Keenan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Jeff Horwitz wrote: Counter: http://www.smashing.org/sandbox/perl6-handlers/counter When I first clicked on this link, the counter stood at 30. Then, when I hit the Refresh button, it surprised me by jumping directly to 45. Subsequent refreshes incremented the counter by 1, as I would have expected.
Re: dlopen(NULL) ?
It doesn't work on Win32 too.
chromatic [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Sunday 13 May 2007 16:30:23 Mike Mattie wrote:
I am working on src/dynext.c and I ran across this in get_path.
if (lib == NULL) {
*handle = Parrot_dlopen((char *)NULL);
It may be a RTFM, but what does a null dlopen mean if it
succeeds, and why is it here ?
First answer: get a handle to load symbols from the main program.
Second answer: I'm not sure, but I know it doesn't work on Mac OS X 10.2
and
earlier.
-- c
Re: Is Parrot 1.0 too late?
I've already started a project that embeds Parrot Allison Randal [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Nikolay, Here's a few things you (and others) can do: - give a talk about Parrot at your local linux/ruby/python/php/perl/etc user group (recruiting new developers, and raising general awareness), show working code - contribute a patch (accelerating our path to the 1.0 release) - document a feature (making it easier for new users/developers to get involved) This list isn't really the right place to talk about the business side of the project, but we have good connections with significant companies who who have an eye on Parrot. They can't do anything until we ship a production (or at least beta) release, though. 1.0 is our top priority right now, as soon as possible. Allison
Re: Is Parrot 1.0 too late?
BTW, seems like the game has already started http://blogs.msdn.com/hugunin/archive/2007/04/30/a-dynamic-language-runtime-dlr.aspx Allison Randal [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Nikolay, Here's a few things you (and others) can do: - give a talk about Parrot at your local linux/ruby/python/php/perl/etc user group (recruiting new developers, and raising general awareness), show working code - contribute a patch (accelerating our path to the 1.0 release) - document a feature (making it easier for new users/developers to get involved) This list isn't really the right place to talk about the business side of the project, but we have good connections with significant companies who who have an eye on Parrot. They can't do anything until we ship a production (or at least beta) release, though. 1.0 is our top priority right now, as soon as possible. Allison
Re: Is Parrot 1.0 too late?
Nicholas Clark [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Wed, Apr 25, 2007 at 11:48:07AM +0300, Nikolay Ananiev wrote: Maybe we have to search harder for new ways to advertise Parrot to other communities and get new developers and supporters to the project. Currently, Parrot looks too Perlish and is mainly supported by the Perl community. I think that has to change. Do you have any ideas on how to achieve this? No. If I knew how to tie a large group of people to a specific project I would've been a very rich guy. :-) But I hope that by discussing these topics, some ideas or suggestions may come up.
Re: Is Parrot 1.0 too late?
Allison Randal [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Nikolay Ananiev wrote: Yes I know about Parrot's great features, but Parrot is still not ready for the mainstream and won't be ready in the next two years (maybe?). That's a lot of time for commercial projects like CLR and JVM and the competition between MS and Sun is quite serious, so I expect the dynamic features in their VMs to progress very fast. I'm also afraid they have the resources to create compiler tools comparable to PGE and TGE (you know that MS can always steal). That's a possibility, but what are you afraid of? I'm afraid these companies have the opportunity to take the niche that Parrot aims at, before we get there. This is how open source software works. We develop in the open to promote the greater advance of all technology. We don't hoard our advances in the fear that others will use them (that's what proprietary companies do). I just want Parrot to make it an be successful as a project. I think this will happen if we manage to make it popular among other communities, before JVM or CLR become popular as platforms for dynamic languages. One of the greatest advantages of the open source model is the fact that Parrot isn't tied to a particular company's profit strategy. This gives us a much greater flexibility to take bold risks on new technology. I expect that this will keep Parrot consistently ahead of the CLR and the JVM. They have more resources to throw at it, but they also have strong motivations not to radically change their architecture. New technology doesn't make a popular project. And a big project like Parrot needs a popularity to survive. But, there's really no way to be certain how the game will play out until we play the game. If poker players all threw in their cards as soon as they were dealt, it would make for a pretty boring game. But we have to be prepared for the game before it starts. Maybe we have to search harder for new ways to advertise Parrot to other communities and get new developers and supporters to the project. On that I completely agree, but as a simple matter of practicality, not some desperate bid for market dominance. If you want to recruit new C developers, you go where C developers hang out. (chromatic and I are speaking at a Linux conference this weekend.) Currently, Parrot looks too Perlish On that I completely disagree. Parrot looks very Perlish because it's highly dynamic and intended to be easy to use (which happen to also be goals of Perl). This is an advantage. By too Perlish I mean that not many developers outside the Perl community have heard of Parrot. If you go to the PHP community and ask them about this project, they'll tell you they don't care. And the ones that know something will tell you Why to use Parrot? We have Zend 2.0. Anyway, I expect Zend will never officially support Parrot, because they are working too closely with Sun. Maybe the big question here is: What do you think Parrot needs to get to 1.0? Does it need the masses from the Perl and other communities? Is it ready for this? or it needs just a few more highly motivated developers?
Re: Is Parrot 1.0 too late?
Yes I know about Parrot's great features, but Parrot is still not ready for the mainstream and won't be ready in the next two years (maybe?). That's a lot of time for commercial projects like CLR and JVM and the competition between MS and Sun is quite serious, so I expect the dynamic features in their VMs to progress very fast. I'm also afraid they have the resources to create compiler tools comparable to PGE and TGE (you know that MS can always steal). I think in 2-3 years CLR and JVM will be a serious competition to Parrot and I just hope people won't say uh, another VM for dynamic languages about Parrot 1.0. Maybe we have to search harder for new ways to advertise Parrot to other communities and get new developers and supporters to the project. Currently, Parrot looks too Perlish and is mainly supported by the Perl community. I think that has to change. Allison Randal [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Nikolay Ananiev wrote: So, is one of parrot's biggest strengths gone? Are we too late? Why would the developers use Parrot instead of JVM/CLR/Mono? We're certainly pleased that we kicked off a revolution in virtual machines, and that others are beginning to catch on to the fact that they'll have to support dynamic languages to compete. But, it would be a little silly to throw in the towel just when others are beginning to follow your lead. (And I do mean beginning. They're making great strides, but I still hear strange comments like We support all features of dynamic languages. Of course some features, like multiple inheritance, may be slow, but we don't encourage the use of those features. from the JVM team.) The plan to run Perl, Python, PHP, Ruby, etc. is not the only innovative feature of Parrot. To list a few: - PGE provides parsing tools that are light years ahead of what's in common use today (what's commonly used today hasn't seen much in the way of technological advances in the past 20 years). - TGE is a powerful tool for manipulating trees of data, like the output of a parse, or an abstract syntax tree (think of it as XSLT on steroids). - Those parsing and transformation tools are valuable both for writing compilers and for data processing tasks (handling database output, screen scraping, combination and modification of Atom streams in an AJAXian way, etc.), giving a big boost in ease of use for both areas. - Parrot is a register-based virtual machine instead of stack-based like .NET, Mono, JVM. Register-based machines require fewer instructions to complete the same operations (no need to push and pop the stack), eliminating some unnecessary overhead. JIT-ed code is also register-based (since the actual machine under the virtual machine is register-based), so the register-based bytecode makes that transformation simpler. - Parrot moves beyond the fragile stack-based control flow common to virtual machines today, to a continuation-based control flow. (I can recommend a few good books and articles if you're curious.) While the other VMs are catching up to supporting the features of dynamic languages from 10-40 years ago, we plan to open the way for a whole new breed of dynamic languages. Will others follow our example? I won't complain if they do. Imitation is the sincerest form of flattery. Allison
Is Parrot 1.0 too late?
As we all know, parrot has been in development for 7 years now. That's a lot of time and many things have changed since then. From my point of view one of the biggest strengths of Parrot is that it's a target for many (and why not all?) dynamic languages and as I know there's no other VM like it. Well... since now. Check this article: http://blogs.zdnet.com/microsoft/?p=404 Microsoft announces a dynamic layer for CLR, so they will be able to support dynamic languages on their VM. And JVM 1.6 already has this, plus it's opensource and has support for the mainstream platforms. So, is one of parrot's biggest strengths gone? Are we too late? Why would the developers use Parrot instead of JVM/CLR/Mono?
Re: [perl #41132] [BUG] Segfault in Parrot_call_sub_ret_int
Nikolay Ananiev [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
forgot to attach the files. Attached in this message.
The attached patch fixes the problem. The code is taken from Parrot_call_sub
(which works).
But I don't know why it was not applied to the other two function. Maybe
it's just a hack?
begin 666 extend.c.patch
[EMAIL PROTECTED](5X=5N9YC#0H]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]#0HM+2T@
M97AT96YD+F,)*')E=FES:6]N(#$V,C8W*0T**RLK(5X=5N9YC2AW;W)K
M:6YG(-O'DI#0I 0 [EMAIL PROTECTED]V.2PX($! #0H@( @(%!!4E)/5%]#
M04Q,24Y?4U1!4E0H:6YT97)P*3L*( H@( @('9A7W-T87)T*%P+!S:6=N
M871UF4I.PHK( @($-/3E1%6%0H:6YT97)P+3YC='@I+3YC;VYS=%N=',@
M/0HK( @( @(!034-?W5B*'-U8BDM/G-E9RT^8V]NW1?=%B;4M/F-O
M;G-T86YTSL*( @(!R97-U;'0@/2!087)R;W1?G5N;W!S7V9R;VUC7V%R
M9VQIW1?F5T:2AI;G1EG L('-U8BP@VEG;F%T=7)E+!AD[B @( @
M=F%?96YD*%P*3L*( I 0 [EMAIL PROTECTED]@*SX.PX($! #0H@( @(%!!4E)/
M5%]#04Q,24Y?4U1!4E0H:6YT97)P*3L*( H@( @('9A7W-T87)T*%P+!S
M:6=N871UF4I.PHK( @($-/3E1%6%0H:6YT97)P+3YC='@I+3YC;VYS=%N
M=',@/0HK( @( @(!034-?W5B*'-U8BDM/G-E9RT^8V]NW1?=%B;4M
M/F-O;G-T86YTSL*( @(!R97-U;'0@/2!087)R;W1?G5N;W!S7V9R;VUC
M7V%R9VQIW1?F5T9BAI;G1EG L('-U8BP@VEG;F%T=7)E+!AD[B @
1( @=F%?96YD*%P*3L*( H`
`
end
[perl #41125] [PATCH] Fix small typo in root.in
# New Ticket Created by Nikolay Ananiev # Please include the string: [perl #41125] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41125 Fixes the reallyinstall target on Win32 root.in.patch Description: Binary data
[perl #41132] [BUG] Segfault in Parrot_call_sub_ret_int
# New Ticket Created by Nikolay Ananiev # Please include the string: [perl #41132] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41132 Check the attached examples.
Re: [perl #41132] [BUG] Segfault in Parrot_call_sub_ret_int
forgot to attach the files. Attached in this message.
test.pir
Description: Binary data
#include parrot/parrot.h
#include parrot/embed.h
#include parrot/extend.h
Parrot_STRING pw_new_string(Parrot_Interp interp, char *str) {
return Parrot_new_string(interp,
str,
strlen(str),
NULL,
PObj_external_FLAG|PObj_constant_FLAG);
}
Parrot_PMC pw_get_func(Parrot_Interp interp, char *func_name) {
Parrot_STRING func_string;
func_string = pw_new_string(interp, func_name);
return Parrot_find_global_cur(interp, func_string);
}
int main() {
Parrot_PackFile pf;
Parrot_Interp interp;
Parrot_PMC init_func;
Parrot_Int result;
interp = Parrot_new(NULL);
pf = Parrot_readbc(interp, test.pbc);
Parrot_loadbc(interp, pf);
init_func = pw_get_func(interp, init);
result = Parrot_call_sub_ret_int(interp, init_func, I);
}
[perl #41095] [BUG] Segfault in test.exe during Configuration
# New Ticket Created by Nikolay Ananiev # Please include the string: [perl #41095] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41095 test.exe or config/auto/jit/test_c.in segfault during configuration on Win32. Note that this happent on Pentium MMX ( 586 ). The test tests for fucomip cpu instruction, but the 586 generation CPUs don't have it. It's first introduced in Pentium PRO (686). The segfault opens a debug window in win32, where the user must press OK for the Configure script to continue. After this the configuration and compilation are successful, because test.exe returns false after the segfault and fucomip is not used.
Re: [perl #40998] [PATCH] Fix build error on Win32
OK, so no one seems interested.
Anyway, the attached patch in this message is a
better version of the previous one.
It checks for a white space in build_dir and makes the value
short path only when a space exists.
Nikolay Ananiev [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Ron Blaschke [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Nikolay Ananiev (via RT) wrote:
# New Ticket Created by Nikolay Ananiev
# Please include the string: [perl #40998]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40998
When build_dir contains spaces the build process fails.
The fix is to translate build_dir to a short path name.
In my opinion it would be better to escape/quote the relevant paths
properly. I think the short file names were introduced for backwards
compatibility, as a kludge. Besides, they are ugly to read. ;-)
Ron
If we use quotes, we'll have to refactor some of the scripts in the build
tree,
because there are many concatenations and currently they won't work
if we use quotes on build_dir. There's one more way. We can check
build_dir
and use short path names only if there are spaces.
begin 666 win32build.patch
[EMAIL PROTECTED](-O;F9I9R]I;FET+VAI;G1S+VUS=VEN,S(NT-CT]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T-BTM+2!C;VYF:6O:6YI=]H:6YTR]MW=I;C,R
M+G!M2AR979IVEO;B [EMAIL PROTECTED]BLK*R!C;VYF:6O:6YI=]H:6YTR]M
MW=I;C,R+G!M2AW;W)K:6YG(-O'DI#0I 0 M-PV(LT+#@0$ -B!P
M86-K86=E(EN:70Z.FAI;G1S.CIMW=I;C,R.PH@B!UV4@W1R:6-T.PHK
M=7-E(%=I;C,R.PH@B!S=6(@G5NW1E H@PI 0 M,CL-B K,[EMAIL PROTECTED],3(@
M0$ -B @( @( @(UA:V5?8R @( @( @( @(#T^(D*%!%4DPI(UE
M()C:1IB!S:EF=! 05)'5CL@WES=5M(%PG)A-04M%*5PG+! 05)'
[EMAIL PROTECTED] D)#\@/[EMAIL PROTECTED])RP*( @( @( @;F-I;EB7VQI;FM?97AT
MF$@/3X@)RUD968ZW)C+VQI8FYC:5]T97-T+F1E9BLB @( @*3L**R @
M( **R @(!M2 D8G5I;1?9ER(#T@)-O;F8M/F1A=$M/F=E=@G8G5I
M;1?9ER)RD[BL@( @BL@( @:68H))U:6QD7V1IB!^/2 O7',O*2![
MBL@( @( @(1C;VYF+3YD871A+3YS970H8G5I;1?9ER(#T^(%=I;C,R
M.CI'9713:]R=%!A=A.86UE*1B=6EL9%]D:7(I*3L**R @(!]B *( @
4(!I9B H)ES7VUS=F,I('L*( H`
`
end
Re: [perl #40998] [PATCH] Fix build error on Win32
Ron Blaschke [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Nikolay Ananiev (via RT) wrote: # New Ticket Created by Nikolay Ananiev # Please include the string: [perl #40998] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40998 When build_dir contains spaces the build process fails. The fix is to translate build_dir to a short path name. In my opinion it would be better to escape/quote the relevant paths properly. I think the short file names were introduced for backwards compatibility, as a kludge. Besides, they are ugly to read. ;-) Ron If we use quotes, we'll have to refactor some of the scripts in the build tree, because there are many concatenations and currently they won't work if we use quotes on build_dir. There's one more way. We can check build_dir and use short path names only if there are spaces.
[perl #40998] [PATCH] Fix build error on Win32
# New Ticket Created by Nikolay Ananiev # Please include the string: [perl #40998] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40998 When build_dir contains spaces the build process fails. The fix is to translate build_dir to a short path name. win32build.patch Description: Binary data
Can I use Parrot's subsystems in an embedded code?
Hi there! I'm starting an experimental C project that will embed parrot. I'd like my program to be as portable as parrot itself, so my question is: Can I take advantage of parrot's portableness? For example, if my program does some IO stuff, can I use Parrot's IO subsystem in my C code to do this stuff instead of using the platform's native functions? I didn't find much info about embedding parrot.
