[32863] in Perl-Users-Digest
Perl-Users Digest, Issue: 4129 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Feb 2 03:09:38 2014
Date: Sun, 2 Feb 2014 00:09:04 -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 Sun, 2 Feb 2014 Volume: 11 Number: 4129
Today's topics:
any memcched users in here? <visphatesjava@gmail.com>
client/server <gravitalsun@hotmail.foo>
Re: client/server <jurgenex@hotmail.com>
Re: creating a custom newsreader <news@todbe.com>
Re: creating a custom newsreader <ben@morrow.me.uk>
Re: creating a custom newsreader <news@todbe.com>
Re: creating a custom newsreader <rvtol+usenet@xs4all.nl>
Re: creating a custom newsreader <ben@morrow.me.uk>
Re: creating a custom newsreader <ben@morrow.me.uk>
Re: creating a custom newsreader <news@todbe.com>
Re: use MCE; marioeroy@gmail.com
Re: use MCE; marioeroy@gmail.com
web web web!!! hows the perl web startup market going? <visphatesjava@gmail.com>
Re: web web web!!! hows the perl web startup market goi <marius@ieval.ro>
Re: web web web!!! hows the perl web startup market goi <kw@codebykevin.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 1 Feb 2014 04:14:31 -0800 (PST)
From: johannes falcone <visphatesjava@gmail.com>
Subject: any memcched users in here?
Message-Id: <f8d95d6e-78f8-4fd6-addf-9bfd1fd6ae52@googlegroups.com>
curious about ability of memcached to replace a windows share?
------------------------------
Date: Sat, 01 Feb 2014 00:58:24 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: client/server
Message-Id: <lch9qg$1tbb$1@news.ntua.gr>
Let’s say I have n servers and each one should have a client and a
server component (in Perl) . The client connect to other servers,
process their answers and the server component serves these answers (to
the other servers clients) . What do you think is the best way to build it.
1) As one service that is both client & server (easier to have shared
variables between them)
2) Two completely separate scripts (client / server) , which will be
easier to write , but more problematic for the client to read server’s data
------------------------------
Date: Fri, 31 Jan 2014 15:15:47 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: client/server
Message-Id: <mcboe9p6e3usef6j7bfas2a1d4dqi3k4ac@4ax.com>
George Mpouras <gravitalsun@hotmail.foo> wrote:
>Let’s say I have n servers and each one should have a client and a
>server component (in Perl) . The client connect to other servers,
>process their answers and the server component serves these answers (to
>the other servers clients) . What do you think is the best way to build it.
>
>1) As one service that is both client & server (easier to have shared
>variables between them)
>
>2) Two completely separate scripts (client / server) , which will be
>easier to write , but more problematic for the client to read server’s data
That would depend to a very large degree on what kind of service you are
talking about, what kind and size of data you are expecting, how long
retrieving the data takes, if your server and the client on same machine
need to synchronize their actions or if your client can retrieve the
data asynchroniously and cache it locally, etc, etc, etc.
And none of these questions has anything to do with Perl.
jue
------------------------------
Date: Fri, 31 Jan 2014 18:14:44 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: creating a custom newsreader
Message-Id: <lchlae$3nt$1@dont-email.me>
On 1/30/2014 20:26, Ben Morrow wrote:
>
> Quoth "$Bill" <news@todbe.com>:
>> On 1/30/2014 08:42, Ben Morrow wrote:
>>>
>>> The remote machine needs to be running sshd or telnetd or something
>>> equivalent. (This, in practice, means it needs to Not Be Running
>>> Windows.) If that is the case then you want PuTTY (put it into Google).
>>
>> I don't follow that - why can't the remote daemon just run on a different
>> port and 'fork' off a terminal window with a shell running in it ?
>
> I'm not sure I understand... what do you mean by 'run on a different
> port'?
I mean listen on a port other than the standard sshd port for incoming
connections.
> If you mean, 'why can't the remote (Windows) machine create a new
> cmd.exe window when a connection comes in', then how is the display of
> that cmd window supposed to be communicated back to the client?
No window is needed on the server - just a process running a shell. The
terminal window would be on the client - the same as running a remote Xterm
under an old UNIX system with XWindows (I used to do it all the time under
Solaris) - same as a local Xterm, but you added a host arg to the open to
log into a remote host. The server's shell input and output are simply
routed back to the client terminal window.
> This is
> what a pty does for you on Unix: it provides a terminal device with a
> 'back door' that programs like telnetd and sshd can use to see what's
> been sent to the terminal, but a pty is a kernel facility and Windows
> doesn't provide anything equivalent.
>
> What you could do, these days, I believe, is invoke cmd.exe via Windows
> Terminal Services (assuming you're running a version of Windows which
> supports that), forward the whole GUI mess to the client over RDP, and
> then display it 'seamlessly' in a window on the client machine. (Or do
> the same with VNC, of course.) This isn't really equivalent to a ssh
> connection to a Unix machine, though.
Sounds plausible - how does one do that complicated mess though?
------------------------------
Date: Sat, 1 Feb 2014 05:17:24 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: creating a custom newsreader
Message-Id: <4kcura-kql2.ln1@anubis.morrow.me.uk>
Quoth "$Bill" <news@todbe.com>:
> On 1/30/2014 20:26, Ben Morrow wrote:
> > Quoth "$Bill" <news@todbe.com>:
> >> On 1/30/2014 08:42, Ben Morrow wrote:
> >>>
> >>> The remote machine needs to be running sshd or telnetd or something
> >>> equivalent. (This, in practice, means it needs to Not Be Running
> >>> Windows.) If that is the case then you want PuTTY (put it into Google).
> >>
> >> I don't follow that - why can't the remote daemon just run on a different
> >> port and 'fork' off a terminal window with a shell running in it ?
> >
> > I'm not sure I understand... what do you mean by 'run on a different
> > port'?
>
> I mean listen on a port other than the standard sshd port for incoming
> connections.
Why would you need to do that? (I'm confused, here; maybe it's not
important.)
> > If you mean, 'why can't the remote (Windows) machine create a new
> > cmd.exe window when a connection comes in', then how is the display of
> > that cmd window supposed to be communicated back to the client?
>
> No window is needed on the server - just a process running a shell. The
> terminal window would be on the client - the same as running a remote Xterm
> under an old UNIX system with XWindows (I used to do it all the time under
> Solaris) - same as a local Xterm, but you added a host arg to the open to
> log into a remote host. The server's shell input and output are simply
> routed back to the client terminal window.
OK, you're talking about two different things here. The first is when
you're sitting in front of a terminal (emulator), you type 'ssh rhost',
and you get a shell running on rhost. If you were running a process
which expects to be running on the end of a pipe, this wouldn't need any
special handling: the sshd runs the process on the remote machine on the
end of a pipe, and forwards the data over the TCP connection (which is
just another kind of pipe).
However, if you're running an *interactive shell*, the shell process
needs to be directly connected to a terminal device. (That is, a device
for which the Perl -t operator returns true.) Part of the mechanics of
doing prompting and line editing and such means that the shell needs to
be able to issue terminal-specific ioctls against its terminal, to
control things like local echo and whether characters are returned
immediately or wait for a return. This means that if you attempt to run
an interactive program with stdin and stdout connected to a pipe, it
won't work properly; instead, you have to run it on a pty, which is a
special kernel device that looks like a terminal to the shell, and looks
like a pipe to sshd.
Win32 doesn't have ptys; the equivalent of the 'terminal control ioctls'
are special functions in the Win32 API which only work if the process is
running directly under the control of an instance of cmd.exe. A sshd
running under Win32 can only implement the 'run a program on the end of
a pipe' scenario above, so it's useless for interactive logins.
The second thing you're talking about (if I'm understanding you
correctly) is remote X: this is where you're sitting at a shell running
on some other machine (via ssh, or whatever) and you run an X program
with the -display argument, and the window pops up on your local
display. (Or you do something equivalent that skips some steps.) This is
much more like the RDP case I described below (there are differences,
but they're not important), and, like that, it forwards a picture of a
window over the network rather than a terminal data stream, so it uses
much more bandwidth than ssh and requires appropriate GUI libraries on
the remote end. (In the X case the remote machine only needs the X
client libraries, rather than the full Windows GUI needed in the RDP
case, but again that's not really an important difference.)
> > This is
> > what a pty does for you on Unix: it provides a terminal device with a
> > 'back door' that programs like telnetd and sshd can use to see what's
> > been sent to the terminal, but a pty is a kernel facility and Windows
> > doesn't provide anything equivalent.
> >
> > What you could do, these days, I believe, is invoke cmd.exe via Windows
> > Terminal Services (assuming you're running a version of Windows which
> > supports that), forward the whole GUI mess to the client over RDP, and
> > then display it 'seamlessly' in a window on the client machine. (Or do
> > the same with VNC, of course.) This isn't really equivalent to a ssh
> > connection to a Unix machine, though.
>
> Sounds plausible - how does one do that complicated mess though?
Um, I don't know, I've never used RDP. There is a Unix client, called
'rdesktop'; I don't know which versions of Windows include Terminal
Services these days. It used to be something you paid a lot for, but
recent versions seem to include something called 'Remote Assistance'
which runs on top of Terminal Services; it all depends how determined MS
are to make you pay for the ability to use it for something useful.
Ben
------------------------------
Date: Fri, 31 Jan 2014 22:44:53 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: creating a custom newsreader
Message-Id: <lci54v$cl$1@dont-email.me>
On 1/31/2014 21:17, Ben Morrow wrote:
>
> Quoth "$Bill" <news@todbe.com>:
>> On 1/30/2014 20:26, Ben Morrow wrote:
>>> Quoth "$Bill" <news@todbe.com>:
>>>> On 1/30/2014 08:42, Ben Morrow wrote:
>>>>>
>>>>> The remote machine needs to be running sshd or telnetd or something
>>>>> equivalent. (This, in practice, means it needs to Not Be Running
>>>>> Windows.) If that is the case then you want PuTTY (put it into Google).
>>>>
>>>> I don't follow that - why can't the remote daemon just run on a different
>>>> port and 'fork' off a terminal window with a shell running in it ?
>>>
>>> I'm not sure I understand... what do you mean by 'run on a different
>>> port'?
>>
>> I mean listen on a port other than the standard sshd port for incoming
>> connections.
>
> Why would you need to do that? (I'm confused, here; maybe it's not
> important.)
To accept a remote client connection that wants to control the shell on
the server (basically the remote client is just the input and output of that
shell on the server and obviously you need to fake it out into thinking
the daemon [or a forked emulator from the daemon] is the terminal when in
reality it's the client GUI window).
> OK, you're talking about two different things here. The first is when
> you're sitting in front of a terminal (emulator), you type 'ssh rhost',
> and you get a shell running on rhost. If you were running a process
> which expects to be running on the end of a pipe, this wouldn't need any
> special handling: the sshd runs the process on the remote machine on the
> end of a pipe, and forwards the data over the TCP connection (which is
> just another kind of pipe).
No, the terminal would start by connecting to the server; the server would
either emulate the terminal itself or fork off a process to emulate a
terminal; that process would fork off a tcsh with the input/output redirected
back to itself; the inputs would come from the remote client and the tcsh
outputs would be sent back to the remote client. The remote client doesn't
need a shell, just the means to input and output data to the window that
come/go to the remote server shell.
> However, if you're running an *interactive shell*, the shell process
> needs to be directly connected to a terminal device. (That is, a device
> for which the Perl -t operator returns true.) Part of the mechanics of
> doing prompting and line editing and such means that the shell needs to
> be able to issue terminal-specific ioctls against its terminal, to
> control things like local echo and whether characters are returned
> immediately or wait for a return. This means that if you attempt to run
> an interactive program with stdin and stdout connected to a pipe, it
> won't work properly; instead, you have to run it on a pty, which is a
> special kernel device that looks like a terminal to the shell, and looks
> like a pipe to sshd.
The client is the terminal device/window - the data's just going through a
IP circuit to get there and back - hence the need to fake out the shell
on the server to think it's talking to a terminal.
The client is a terminal GUI that instead of sending keyboard sequences
to a local shell, sends them to the remote shell (I think that's pretty
simple) and accepts the shell output sequences and impresses them on the
local same window. The only difference in the client is the shell it's
talking to is on another host. As far as the server, it has to redirect
the input/output of the shell it forked off to the remote client GUI.
This is an interactive shell and GUI - not a one-shot. The shell has to
'think' it's talking to a terminal device - doesn't mean there has to be
one.
> Win32 doesn't have ptys; the equivalent of the 'terminal control ioctls'
> are special functions in the Win32 API which only work if the process is
> running directly under the control of an instance of cmd.exe. A sshd
> running under Win32 can only implement the 'run a program on the end of
> a pipe' scenario above, so it's useless for interactive logins.
I think you're intimating that you can't emulate a pty through an IP
connection on Doze. I'm hoping that's not true and worst case, if you
have the shell source, could be fixed. The terminal GUI might be more
of a challenge though.
> The second thing you're talking about (if I'm understanding you
> correctly) is remote X: this is where you're sitting at a shell running
> on some other machine (via ssh, or whatever) and you run an X program
> with the -display argument, and the window pops up on your local
> display. (Or you do something equivalent that skips some steps.) This is
> much more like the RDP case I described below (there are differences,
> but they're not important), and, like that, it forwards a picture of a
> window over the network rather than a terminal data stream, so it uses
> much more bandwidth than ssh and requires appropriate GUI libraries on
> the remote end. (In the X case the remote machine only needs the X
> client libraries, rather than the full Windows GUI needed in the RDP
> case, but again that's not really an important difference.)
No, I don't need to pass graphical data, just the normal text data you
would see at a terminal window. All I'm talking about is simulating
a keyboard/terminal through a TCP/UDP connection to a remote host. A
pretty simple situation if you can get the shell to 'think' it's input
and output are a terminal device. Having a graphical interface would
be OK, I just don't need it - I just need a text interface. An Xterm
'is' a terminal interface GUI that runs pretty much like a Windoze
terminal GUI, but can change hosts by invoking with an argument specifying
host server.
I'm still checking out PuTTY and it might have what I need ... OK, I got
PuTTY running and I can log in and run tcsh interactively, so this does
what I want, but I'll have to get used to the terminal GUI which is a
bit more complicated than a normal terminal window. I can even run vim
in the putty terminal seemingly ok, so that's a good thing.
Thanks to all who suggested PuTTY which will do the job for now, Bill
------------------------------
Date: Sat, 01 Feb 2014 12:22:16 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: creating a custom newsreader
Message-Id: <52ecd8e8$0$2896$e4fe514c@news2.news.xs4all.nl>
On 2014-02-01 06:17, Ben Morrow wrote:
> Win32 doesn't have ptys; the equivalent of the 'terminal control ioctls'
> are special functions in the Win32 API which only work if the process is
> running directly under the control of an instance of cmd.exe. A sshd
> running under Win32 can only implement the 'run a program on the end of
> a pipe' scenario above, so it's useless for interactive logins.
This looks decent, and is free to try:
http://www.extenua.com/silvershield
See also: http://www.freesshd.com/
but expect some security issues.
--
Ruud
------------------------------
Date: Sat, 1 Feb 2014 19:06:10 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: creating a custom newsreader
Message-Id: <26tvra-r4q2.ln1@anubis.morrow.me.uk>
Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
> On 2014-02-01 06:17, Ben Morrow wrote:
>
> > Win32 doesn't have ptys; the equivalent of the 'terminal control ioctls'
> > are special functions in the Win32 API which only work if the process is
> > running directly under the control of an instance of cmd.exe. A sshd
> > running under Win32 can only implement the 'run a program on the end of
> > a pipe' scenario above, so it's useless for interactive logins.
>
> This looks decent, and is free to try:
> http://www.extenua.com/silvershield
AFAICS this doesn't even pretend to support interactive logins: it just
talks about SFTP and running remote scripts. (Both of which are useful,
of course, and both of which can be done with Cygwin sshd or anything
else.)
> See also: http://www.freesshd.com/
> but expect some security issues.
I think this was the non-Cygwin sshd I mentioned before; if it is, then
it tries to start an interactive shell and it doesn't work properly
because the terminal control isn't there.
Ben
------------------------------
Date: Sat, 1 Feb 2014 20:16:11 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: creating a custom newsreader
Message-Id: <b910sa-7rq2.ln1@anubis.morrow.me.uk>
Quoth "$Bill" <news@todbe.com>:
> On 1/31/2014 21:17, Ben Morrow wrote:
[...]
> >
> > However, if you're running an *interactive shell*, the shell process
> > needs to be directly connected to a terminal device. (That is, a device
> > for which the Perl -t operator returns true.) Part of the mechanics of
> > doing prompting and line editing and such means that the shell needs to
> > be able to issue terminal-specific ioctls against its terminal, to
> > control things like local echo and whether characters are returned
> > immediately or wait for a return.
[...]
This:
> The client is the terminal device/window - the data's just going through a
> IP circuit to get there and back - hence the need to fake out the shell
^^^^^^^^^^^^^^^^^^
> on the server to think it's talking to a terminal.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
is impossible under Windows. (At least if you're talking about
unmodified native Win32 utilities.)
> > Win32 doesn't have ptys; the equivalent of the 'terminal control ioctls'
> > are special functions in the Win32 API which only work if the process is
> > running directly under the control of an instance of cmd.exe. A sshd
> > running under Win32 can only implement the 'run a program on the end of
> > a pipe' scenario above, so it's useless for interactive logins.
>
> I think you're intimating that you can't emulate a pty through an IP
> connection on Doze.
I am.
> I'm hoping that's not true
It is.
> and worst case, if you have the shell source,
You don't have the source to cmd.exe, the only shell that works properly
on Win32. More importantly, the whole point of the pty abstraction is
that you *don't need the source* to the programs you're running.
Otherwise, every interactive program you run from the shell (say, your
editor, or the perl debugger) also needs to be modified to support your
userland pty emulation.
Yes, as I said before, it's possible that Cygwin sshd can fake up
something that Cygwin programs can pretend is a pty, but this won't work
with native Win32 programs.
> could be fixed. The terminal GUI might be more of a challenge though.
The terminal GUI is running on the client. You can just use something
preexisting (xterm or putty or whatever).
> > The second thing you're talking about (if I'm understanding you
> > correctly) is remote X:
[...]
> No, I don't need to pass graphical data, just the normal text data you
> would see at a terminal window. All I'm talking about is simulating
> a keyboard/terminal through a TCP/UDP connection to a remote host. A
> pretty simple situation if you can get the shell to 'think' it's input
> and output are a terminal device. Having a graphical interface would
> be OK, I just don't need it - I just need a text interface. An Xterm
> 'is' a terminal interface GUI that runs pretty much like a Windoze
> terminal GUI, but can change hosts by invoking with an argument specifying
> host server.
I don't know what that hypothetical option to xterm might do: my xterm
doesn't have such an option. But I suspect you're actually talking about
xon(1), which works exactly as I described: it makes an rcmd (terminal-
level) connection to the remote machine, sets up DISPLAY to point back
to your workstation, and then runs an X application (by default xterm).
This application then makes an entirely separate connection back to your
workstation, and sends X protocol (pictures of windows) along that
connection.
Of course, this *still* needs pty support on the remote machine, because
xterm also uses a pty to make the shell it's running think it's running
on a terminal.
Ben
------------------------------
Date: Sat, 01 Feb 2014 20:14:07 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: creating a custom newsreader
Message-Id: <lckgm6$3td$1@dont-email.me>
On 2/1/2014 12:16, Ben Morrow wrote:
>
> I don't know what that hypothetical option to xterm might do: my xterm
> doesn't have such an option. But I suspect you're actually talking about
> xon(1), which works exactly as I described: it makes an rcmd (terminal-
> level) connection to the remote machine, sets up DISPLAY to point back
> to your workstation, and then runs an X application (by default xterm).
> This application then makes an entirely separate connection back to your
> workstation, and sends X protocol (pictures of windows) along that
> connection.
>
> Of course, this *still* needs pty support on the remote machine, because
> xterm also uses a pty to make the shell it's running think it's running
> on a terminal.
Well, I think we may be talking apples and oranges. The Xterm program
that I used years ago is probably extinct, so doubt you're still using
it. I ran it on Solaris in the 90s running under the X11 XWindows
server - it is a terminal emulator and could be used on like standalone
VT220 terminals and such with the server running on the UNIX workstation
or it could run as a window in that host or another emulating a VT220 or
whatever. I have to assume that it has long ago been replaced by something
bigger and better (but who knows, I still use vi [usually in the form of
Vim] that I used back in the 80s and emacs is still around and Perl itself
which I first used in the 80s). I'm not even sure if XWindows is still
in use anywhere (I've been stuck on Windoze at home for years now); I
assume GNOME/KDE and others have replaced it to whatever extent.
I think we were running GDM or xdm Window managers back then with the
Motif toolkit and Sun also had their own windowing system (Openlook I
believe) which wasn't as nice looking as Motif on XWindows.
PS: Arg to run on remote host: DISPLAY=<hostname>:0
That being said, I'm running Bitvise SSH server on my desktop and
PuTTY on the laptop and it does everything I described 'above' that
I needed (trying to tweak the terminal GUI a bit to make it more
friendly - closer to a standard terminal GUI). So apparently it can
be done at least with cmd.exe (which I immediately ran a tcsh under).
Not sure if it has the option of running tcsh directly (which I assume
is what you're saying it won't be able to do); I see nothing in the
config settings that would indicate you could change shells, so I'm
going to assume you're right about that caveat.
I just found reference to Xming (which uses a modified PuTTY client)
XWindows system for Windoze - will look into that as well.
Thanks to all for all the info/suggestions.
------------------------------
Date: Sat, 1 Feb 2014 21:49:36 -0800 (PST)
From: marioeroy@gmail.com
Subject: Re: use MCE;
Message-Id: <3c7ee396-6f14-47ff-a324-5695a5e95384@googlegroups.com>
Below, you will find the simulation performed in parallel using MCE.
use MCE::Loop;
## Callback functions.
my ($r, $result);
sub get_rand {
return if defined $result;
return rand();
}
sub recv_result {
return if defined $result;
($r, $result) = @_;
return;
}
## Configure MCE and common variables.
MCE::Loop::init {
chunk_size => 1, max_workers => 8,
input_data => \&get_rand,
gather => \&recv_result
};
my $var = 1;
my $foo = 2;
my $bar = 3;
## Compute in parallel.
mce_loop {
# my ($mce, $chunk_ref, $chunk_id) = @_;
my $r = $_;
my $result = $r * ($var+$foo+$bar);
my $anothervar = sqrt($var+$foo+$bar);
if ($result < $anothervar+0.001 && $result > $anothervar-0.001) {
MCE->gather($r, $result); MCE->abort();
}
return;
};
## Display the answer.
print "$r -> $result\n";
- mario
------------------------------
Date: Sat, 1 Feb 2014 21:56:34 -0800 (PST)
From: marioeroy@gmail.com
Subject: Re: use MCE;
Message-Id: <d1652afb-c242-493a-a43c-140a52122fb2@googlegroups.com>
The MCE example above is possible with MCE 1.508 or later releases.
https://metacpan.org/release/MCE
------------------------------
Date: Sat, 1 Feb 2014 03:41:59 -0800 (PST)
From: johannes falcone <visphatesjava@gmail.com>
Subject: web web web!!! hows the perl web startup market going?
Message-Id: <24b12d1b-20d5-4ad9-b70a-395c6159e406@googlegroups.com>
anyone trying some web frameworks old or new???
poet?
continuity?
catalyst???
show me what u got cookin!
or some site u made
thx guys
------------------------------
Date: Sat, 01 Feb 2014 13:57:52 +0200
From: Marius Gavrilescu <marius@ieval.ro>
Subject: Re: web web web!!! hows the perl web startup market going?
Message-Id: <87y51vm4e7.fsf@ieval.ro>
--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
johannes falcone <visphatesjava@gmail.com> writes:
> anyone trying some web frameworks old or new???
Here's a (short) list of Perl web startups, if that's what you're
looking for: http://www.builtinperl.com/startups
=2D-=20
Marius Gavrilescu
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJS7OFBAAoJEMoENb5ewbNiK0wP/1F0VKyttoiLqqQqlX7Jdpuc
txNmTDT4y8RGiKX7thLRACUO7dAsC4/m2WEespIgXc8fSyyEZoPYtVJYdrpWaZIy
vuG1CDDyv/22AfXBC0LsYl7UlsHOHXyEoqq/SnbhEzgOh+QSdNDRdEEq26QIx2XG
2+DkH7UpQwkM0fvRCaUXFJkj5wcw1yFF70MU6LbZl/N3Pi4ztc6unAXe9GmQyr7v
qjM1xDX1nhlYpj3V9+c/Qq49MIloI5/yn9AjfZWLEAsMWhl0loDtF2if1GJZmcOQ
BdLqAL/kAgpwik/UKUyNKTqPDnxG8JUAOgpb4dSLOmUmn0ByA2xcMMEl4YPtneIS
nRSELw+w/UTJFhjQC6PH+9/n9jTCbybRBd/ZUTbVc8yfs75R5qDAXuGLIpWkQSCU
wt2Qxg77AEAa9oeA09BeXNr7vAwABC2LJFOsyASgF1YsWlX7YC10jU8WhRJBN80J
HYGA1rBbL2AJrnDM1jDplfgDMTftMYAuZkaKlL1eSzSzW3JboiKwTBd0sIFy8i+g
K8R5fXausV1ALnlJE34++hfxJbvQz3VHr1oBeOs7FvW1FWPA1k1rbz690d75uJ3p
fZC1MC1Q94LdIWm06kuddu/cKRw1e/3IMteKlsKXrVvKr3E+Cw72cNzz28ubOe2h
jQg9/WJSIeuA9SMvdQDF
=6IHe
-----END PGP SIGNATURE-----
--=-=-=--
------------------------------
Date: Sat, 01 Feb 2014 12:50:02 -0500
From: Kevin Walzer <kw@codebykevin.com>
Subject: Re: web web web!!! hows the perl web startup market going?
Message-Id: <lcjc4d$tol$1@dont-email.me>
On 2/1/14, 6:57 AM, Marius Gavrilescu wrote:
> Here's a (short) list of Perl web startups, if that's what you're
> looking for:http://www.builtinperl.com/startups
How cool! Thank you for posting this.
--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 4129
***************************************
