[27306] in Perl-Users-Digest
Perl-Users Digest, Issue: 9042 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Mar 11 11:06:49 2006
Date: Sat, 11 Mar 2006 08:05:05 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 11 Mar 2006 Volume: 10 Number: 9042
Today's topics:
Cross-Site Multi-Platform Development Concerns <dustin_atm_99-NOSPAM@yahoo.com>
Re: Cross-Site Multi-Platform Development Concerns <matthew.garrish@sympatico.ca>
Re: Cross-Site Multi-Platform Development Concerns <jwkenne@attglobal.net>
Re: Cross-Site Multi-Platform Development Concerns <matthew.garrish@sympatico.ca>
Re: Cross-Site Multi-Platform Development Concerns <matthew.garrish@sympatico.ca>
Re: Cross-Site Multi-Platform Development Concerns <1usa@llenroc.ude.invalid>
Re: Cross-Site Multi-Platform Development Concerns <karlheinz.weindl@arcor.de>
Re: merge event loops and threads (was Re: simple point <tassilo.von.parseval@rwth-aachen.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 11 Mar 2006 11:32:59 GMT
From: "Dustin" <dustin_atm_99-NOSPAM@yahoo.com>
Subject: Cross-Site Multi-Platform Development Concerns
Message-Id: <LzyQf.7902$%X2.5070@tornado.texas.rr.com>
I'm currently developing a web-based application on multiple machines and
multiple networks. I have multiple computers on my home network which I'm
using for development, as well as multiple computers at work. I'm using CVS
for revision control.
Up until now I've been doing the development on each machine and keeping the
code in sync with CVS. This has worked fine, but now I'm running into some
hurdles. Now that much of the backend is complete and I'm ready to start
developing/testing the web-based front-end, I am stuck.
I'd really like to have one central development web server to handle my
testing. The problem is, everytime I want to push changes onto the server,
I have to do a cvs commit, and then a cvs update on the server side. To me,
there's just something inherently wrong with rev'ing your source everytime
you want to push it onto the server, especially for small, incremental
changes--but perhaps this is a normal way to handle this, and I should just
get over it.
So, the second option I've considered is actually installing a testing
platform on every development machine. This means installing Apache, mysql,
and any other supporting infrastructure for my app on every machine. I knew
this was a bad idea from the beginning, but went forward with it anyway.
Problems include platform-specific coding requirements (i.e.
#!c:\perl\bin\perl.exe in windows vs. #!/usr/bin/perl in unix at the top of
the code), issues keeping the mysql db in sync, etc.
Can anyone advise me on how to proceed? I guess my best option right now is
to manage the whole process with CVS and have one central testing server.
I've considered other options, such as the built in ftp/ssh functionality of
vim, to modify code remotely in a local vim session, but this is slow and
tedious. I'm not a big fan of developing inside of a ssh/telnet session for
the same reasons.
I guess ideally I'd like to be able to develop my code locally under any
platform, and then push a button and have the changes propogate to the
testing server. Perhaps something like cvs that doesn't require two steps,
i.e. commiting on the local side and updating on the server side, and also
doesn't require rev'ing the hell out of your code just so you can validate
changes.
Does anyone have any creative ideas or advice on how to handle this?
------------------------------
Date: Sat, 11 Mar 2006 07:31:05 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: Cross-Site Multi-Platform Development Concerns
Message-Id: <bqzQf.35748$Qh1.234005@news20.bellglobal.com>
"Dustin" <dustin_atm_99-NOSPAM@yahoo.com> wrote in message
news:LzyQf.7902$%X2.5070@tornado.texas.rr.com...
> Problems include platform-specific coding requirements (i.e.
> #!c:\perl\bin\perl.exe in windows vs. #!/usr/bin/perl in unix at the top
> of
> the code), issues keeping the mysql db in sync, etc.
>
You don't need the shebang line on Windows. Use the registry
(ScriptInterpreterSource), then you can leave the unix shebang intact and
still use Apache on both platforms.
Matt
------------------------------
Date: Sat, 11 Mar 2006 08:33:47 -0500
From: "John W. Kennedy" <jwkenne@attglobal.net>
Subject: Re: Cross-Site Multi-Platform Development Concerns
Message-Id: <3lAQf.2009$7y3.153@fe10.lga>
Matt Garrish wrote:
> You don't need the shebang line on Windows. Use the registry
> (ScriptInterpreterSource),
Safer -- use the ASSOC and FTYPE commands.
then you can leave the unix shebang intact and
> still use Apache on both platforms.
The shebang is observed by Apache on Windows.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
------------------------------
Date: Sat, 11 Mar 2006 09:10:57 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: Cross-Site Multi-Platform Development Concerns
Message-Id: <PTAQf.5358$xM2.445200@news20.bellglobal.com>
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:3lAQf.2009$7y3.153@fe10.lga...
> Matt Garrish wrote:
>> You don't need the shebang line on Windows. Use the registry
>> (ScriptInterpreterSource),
>
> Safer -- use the ASSOC and FTYPE commands.
>
I don't think you misunderstood. You can use the httpd conf file to set
Apache to use the registry. I'm not talking about file associations in
Windows.
> then you can leave the unix shebang intact and
>> still use Apache on both platforms.
>
> The shebang is observed by Apache on Windows.
>
Not if you set ScriptInterpreterSource to the registry. It will be ignored,
which is why I suggested what I did. So the OP could move any files from the
unix boxes to the windows boxes and not have to worry about changing the
shebang. It will work in unix where it's needed and be ignored on windows
when apache looks to the registry.
Matt
------------------------------
Date: Sat, 11 Mar 2006 09:13:30 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: Cross-Site Multi-Platform Development Concerns
Message-Id: <cWAQf.5360$xM2.445647@news20.bellglobal.com>
"Matt Garrish" <matthew.garrish@sympatico.ca> wrote in message
news:PTAQf.5358$xM2.445200@news20.bellglobal.com...
>
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:3lAQf.2009$7y3.153@fe10.lga...
>> Matt Garrish wrote:
>>> You don't need the shebang line on Windows. Use the registry
>>> (ScriptInterpreterSource),
>>
>> Safer -- use the ASSOC and FTYPE commands.
>>
>
> I don't think you misunderstood.
So much for the quick rewrite of that sentence... : )
Nevermind that "don't".
Matt
------------------------------
Date: Sat, 11 Mar 2006 14:50:00 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Cross-Site Multi-Platform Development Concerns
Message-Id: <Xns97836424DD2D5asu1cornelledu@127.0.0.1>
"John W. Kennedy" <jwkenne@attglobal.net> wrote in news:3lAQf.2009
$7y3.153@fe10.lga:
> Matt Garrish wrote:
>> You don't need the shebang line on Windows. Use the registry
>> (ScriptInterpreterSource),
>
> Safer -- use the ASSOC and FTYPE commands.
No. it is actually safer to use
ScriptInterpreterSource Registry-Strict
http://httpd.apache.org/docs/2.0/mod/core.html#scriptinterpretersource
> then you can leave the unix shebang intact and
>> still use Apache on both platforms.
>
> The shebang is observed by Apache on Windows.
Not is the above is set.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Sat, 11 Mar 2006 15:51:27 +0100
From: Karlheinz Weindl <karlheinz.weindl@arcor.de>
Subject: Re: Cross-Site Multi-Platform Development Concerns
Message-Id: <4412e3ef$0$12920$9b4e6d93@newsread4.arcor-online.net>
John W. Kennedy schrieb:
> Matt Garrish wrote:
>
>> You don't need the shebang line on Windows. Use the registry
>> (ScriptInterpreterSource),
>
>
> Safer -- use the ASSOC and FTYPE commands.
>
> then you can leave the unix shebang intact and
>
>> still use Apache on both platforms.
>
>
> The shebang is observed by Apache on Windows.
>
TIMTOWTDI even if so it's got nothing to do with Perl!
If your shebang is #!/usr/bin/perl in unix and you're running Apache on
Windows, then just leave this line as it is.
Create the directory structure \usr\bin on drive c: and put a copy of
your perl.exe in there and you're done.
At least for the pourpose of testing this should do.
Karlheinz
------------------------------
Date: Sat, 11 Mar 2006 08:50:40 +0100
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: merge event loops and threads (was Re: simple pointer operations (newbe))
Message-Id: <47fdqjFfetq4U1@news.dfncis.de>
Also sprach robic0:
> On Thu, 9 Mar 2006 08:54:27 +0100, "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de> wrote:
> I don't know what profound ng reader your using, I'm using forte' agent.
> Set in my options is to keep thread responses grouped together
> no matter what the thread responder posts in the subject line.
>
> Changing the subject line on a response without starting a new thread
> helps no one, and adds confusion and that's a problem.
>
> Start a new thread from the root (Once again: thats root). If you have the need to
> have a private discussion with someone outside the thread, exchange e-mails.
> Otherwise its still "simple pointer operations (newbie)".
A thread on clpm has a tendency to move away from the original topic.
Nothing of what I wrote and that you replied to had anything to do with
the original subject any longer. The choice of newsreader is irrelevant.
The contents of the posting you are replying to matters.
> Turning to portable, async IO in Perl, and event driven queue's.
> Lets take out the word portable and think of windows.
> Threadwise, if Perl can't natively provide non-blocking mechanisms
> for IO (disk IO), then the best that can be hoped for is the
> ability to instantiate a module within a thread that will provide
> a non-blockin create/read/write/close (the only IO in all of windows)
> interface. You provide the callback when the readfile completes,
> otherwise the native thread will release (the module dll runs in this thread)
> until it completes the io, then calls your ithread callback.
Once your IO is asynchronous, it doesn't have to be non-blocking any
longer. In fact, you expect it to block, that's why you make it async.
> The modules dll could support waiting for multiple signals (windows events) in
> something like "WaitForMultipleObjects()" in a complex signal system servicing
> several queue'd up requests from the instantiated object, or it could a single
> Overlapped io scheme on a single for ReadFile. Either way the async IO is performed
> by threads OUTSIDE of your thread (by the api), but within your process (in kernel space).
> It is not necessary to create a new thread for multiple requests. A single thread
> would do just fine.
You better have each request in its own thread as each one might block
on its own and differently from the other requests. But by and large,
this is how it would be done. Synchronization of these worker threads
also needs to be done, though. Pipes, sockets or even signals come to
mind.
> Windows IO, like I said, is a simple interface. But one that requires alot of thought
> in design. The "WaitForMultipleObjects()" is a non-blocking function that checks the
> event queue of the thread in which its called (there is only 1 for each thread), and
> de-queue's when it gets a time slice. Many event's (signals) can be allocated and set
> in the Overlapped io structure that is (or not) sent as a parameter in the IO request.
>
> Once signaled, the callback can be discerned and passed the appropriate io data.
> So a single thread can be used to wait for many completion signals (or not). The level
> of intricacy grows exponentially.
>
> This is just windows. Its simple IO model covers drivers, files, pipes, mail, etc.., et all.
> But as you can see, its really *NOT* simple at all.
Essentially, each platform offers its own set of relatively simple IO
primitives. Many don't have asynchronous IO in any way so it has to be
put together using those primitives. As this invariably involves things
that many programmers find fickle (threads, inter-thread communication
via pipes etc.), it's not simple and may take several stabs to get it
right.
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9042
***************************************
