[27298] in Perl-Users-Digest
Perl-Users Digest, Issue: 9041 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 10 21:05:46 2006
Date: Fri, 10 Mar 2006 18:05:06 -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 Fri, 10 Mar 2006 Volume: 10 Number: 9041
Today's topics:
Re: export a variable from a module <uri@stemsystems.com>
Re: merge event loops and threads (was Re: simple point robic0
Re: Native Cut&Paste on Win*: CON: buggy? <nospam-abuse@ilyaz.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 10 Mar 2006 15:01:28 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: export a variable from a module
Message-Id: <x71wxahxwn.fsf@mail.sysarch.com>
>>>>> "b" == bugbear <bugbear@trim_papermule.co.uk_trim> writes:
b> Sisyphus wrote:
b> (a perfect and complete answer to my question)
b> Thank you very much - you're a life saver.
b> I always run "use strict", so rather
b> a lot of the examples I found didn't work.
b> The key magic here is the "our"
b> word, which is a new one on me.
the reason you didn't see it is that you should rarely export
variables. the most common exported thing are named subs and they never
needed an our declaration since they are always package globals. most
modules that have variables you need can be accessed by their full name
or you could declare them with our:
use strict ;
package Foo ;
our $bar ;
our $bar2 ;
package main ;
$bar = 3 ;
$Foo::bar2 = 4 ;
print "$Foo::bar\n" ;
print "$bar2\n" ;
OUTPUT--------
3
4
now for the rest of this file or enclosing block, you can directly
access $some_var in the other class. our is really just a shorthand to
declare a lexical alias to some variable in the current package.
but this still brings up the question as to why you want to export a
scalar? direct access or using our like i showed does the same thing
with much less work. and on top of that, having global vars in a module
is not a good idea. you can either make the module OO or wrap the
variables with class method accessors.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Fri, 10 Mar 2006 16:40:52 -0800
From: robic0
Subject: Re: merge event loops and threads (was Re: simple pointer operations (newbe))
Message-Id: <bb24121l7dm4g1p6ncdhddn08mpnbrck6j@4ax.com>
On Thu, 9 Mar 2006 08:54:27 +0100, "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de> wrote:
>Also sprach robic0:
>> On Mon, 6 Mar 2006 08:59:07 +0100, "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de> wrote:
>>
>>>Also sprach Uri Guttman:
>
>>>> i have an idea and most of the design for a module that will allow event
>>>> loops to work well with kernel (not perl!) threads that will run
>>>> blocking operations. of course it involves xs which i have done very
>>>> little with. would you (or anyone else) be interested in working on it
>>>> with (or for :) me? one variation on it (which could use this new module
>>>> or be its own module) would do true async file i/o and be synchronized
>>>> with the event loop. i have done such a beast before in pure c and it
>>>> worked very well. i think these modules are wanted and would be useful
>>>> to many event loop apps. imagine a simple api for async file i/o in perl
>>>> that was actually portable and bypasses all those wacko kernel aio apis
>>>> that each OS provides.
>>>
>>>The specifications sound tempting although you didn't state how you'd
>>>actually want to achieve the asynchronity when you avoid the existing
>>>async IO mechanisms (of which each is unportable by nature). Does your
>>>plan include rolling your own async IO scheme?
>>>
>>>Also, I don't yet see how kernel threads come into this. Perl programs
>>>don't have access to them other than through perl's ithreads.
>>>
>> Now wait a minute. Are you saying Perl programs "don't" have direct access
>> to the underlying OS api core?
>
>I did not say this. Perl programs can be given access to whatever
>interface the underlying operating system has to offer.
>
>> Well, how come? Apparently, Perl programs can do "pointer arithmatic".
>> Heh, where the fuck does those docs exist?
>
>You are talking gibberish. No one was talking about pointer arithmetic
>in this thread. The topic was async IO and how to do it portably in
>Perl.
>
>> So, the whole Perl thing is just a blow-me bullshit cover for really doing
>> C pointers. Well, holy GOD, why didn't they just say so. I could have used
>> any number of regex c-libs out there. Didn't know Perl was just a neo training
>> camp for the stupedist of C programmers. I didn't realize there was such a lack
>> of C/C++ (which is not the point), and of course the most important, a/the
>> OS Api.
>
>The topic was async IO and how to do it portably in Perl.
>
>> Control and synchronization programming (blocking, etc) is a talent that you
>> can't just read-up on. Windows kernel, which provides "all" control programming
>> to user apps, uses "multiple blocking nomenclature and schem's", pseudo (name)
>> categories, hard/soft/level.
>
>Once again: The topic was async IO and how to do it portably in Perl.
>
>Who cares about the Windows kernel in this context?
>
>> You guys don't know your ass from your elbow!
>
>You're well advised to just lurk if you have nothing to contribute which
>you so seldom have.
>
>Tassilo
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)".
===========================
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.
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.
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.
-robic0-
for a thread
------------------------------
Date: Fri, 10 Mar 2006 22:02:50 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Native Cut&Paste on Win*: CON: buggy?
Message-Id: <dust2a$8l4$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
A. Sinan Unur
<1usa@llenroc.ude.invalid>], who wrote in article <Xns977B6E9C96B0Casu1cornelledu@132.236.56.8>:
> SetConsoleMode failed, LastError=|6| at
> C:/opt/Perl/site/lib/Term/ReadKey.pm line 265.
> at C:/opt/Perl/site/lib/Term/ReadLine/readline.pm line 1475
> readline::readline('Enter arithmetic or Perl expression: ',
> 'exit') called at C:/opt/Perl/site/lib/Term/ReadLine/Perl.pm line 11
> Term::ReadLine::Perl::readline('Term::ReadLine::Perl=ARRAY
> (0x1a67b14)',
> 'Enter arithmetic or Perl expression: ', 'exit') called at test.pl line
> 38
> Enter arithmetic or Perl expression:
As Adam Kennedy informed me, this may be not a bug in Perl
installation, but a bug in the Windows device driver for 'CON:'. A
temporary workaround for the test script is to run it as
perl -Mblib test.pl std
See the discussion in
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-02/msg01018.html
Looks like a permanent workaround should be put in Term::ReadLine, if
the communication path between Term::ReadLine and Term::ReadLine::Perl
is flexible enough (as I hope it is).
Anyone knowing how Term::ReadLine::Gnu is handling this bug of Windows?
Thanks,
Ilya
------------------------------
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 9041
***************************************
