In article <·······················@u2g2000hsc.googlegroups.com>,
gavino <·········@gmail.com> wrote:
> http://www.codeforpeople.com/lib/ruby/rq/rq-all-2.3.2/README
> is there anything like this for lisp?
Don't feed the troll Gavino.
--
http://lispm.dyndns.org
On Jun 15, 2:13 pm, Rainer Joswig <······@lisp.de> wrote:
> In article <·······················@u2g2000hsc.googlegroups.com>,
>
> gavino <·········@gmail.com> wrote:
> >http://www.codeforpeople.com/lib/ruby/rq/rq-all-2.3.2/README
> > is there anything like this for lisp?
>
> Don't feed the troll Gavino.
>
> --http://lispm.dyndns.org
Even if he is, it's you that is being trolled and doing the feeding.
On Jun 16, 5:09 am, ·············@gmail.com" <············@gmail.com>
wrote:
> On Jun 15, 2:13 pm, Rainer Joswig <······@lisp.de> wrote:
>
> > In article <·······················@u2g2000hsc.googlegroups.com>,
>
> > gavino <·········@gmail.com> wrote:
> > >http://www.codeforpeople.com/lib/ruby/rq/rq-all-2.3.2/README
> > > is there anything like this for lisp?
>
> > Don't feed the troll Gavino.
>
> > --http://lispm.dyndns.org
>
> Even if he is, it's you that is being trolled and doing the feeding.
What do you think about new approach for dealing with trolls here at
c.l.l., when someone sniffs a trollish thread he'll give the
potential troll a lisp programming problem. If he gives a correct
answer het got replies else silence.
Slobodan Blazeski
My apologies to those who like Java, C#, PHP, Delphi, Visual Basic,
Perl, Python, Ruby, COBOL, or any other language. I know you think
you
know a better language than lisp. All I can say is I do, too!
On Jun 16, 7:10 am, fireblade <·················@gmail.com> wrote:
> On Jun 16, 5:09 am, ·············@gmail.com" <············@gmail.com>
> wrote:
>
> > On Jun 15, 2:13 pm, Rainer Joswig <······@lisp.de> wrote:
>
> > > In article <·······················@u2g2000hsc.googlegroups.com>,
>
> > > gavino <·········@gmail.com> wrote:
> > > >http://www.codeforpeople.com/lib/ruby/rq/rq-all-2.3.2/README
> > > > is there anything like this for lisp?
>
> > > Don't feed the troll Gavino.
>
> > > --http://lispm.dyndns.org
>
> > Even if he is, it's you that is being trolled and doing the feeding.
>
> What do you think about new approach for dealing with trolls here at
> c.l.l., when someone sniffs a trollish thread he'll give the
> potential troll a lisp programming problem. If he gives a correct
> answer het got replies else silence.
>
> Slobodan Blazeski
>
> My apologies to those who like Java, C#, PHP, Delphi, Visual Basic,
> Perl, Python, Ruby, COBOL, or any other language. I know you think
> you
> know a better language than lisp. All I can say is I do, too!
The problem is that some people don't know that a "Why is Lisp better
than Python" question is inappropriate. The other problem is that
"trolling" has been transmogrified into "I don't like what you said"
by so many people. Gavino probably isn't a troll, but also probably
doesn't know that many people will perceive his questions as
inappropriate. A lot of the bigger threads, e.g. "A problem statement
(and a proposed solution)" could almost be perceived as trolling. But
hey, Lisp is dead (or just smells funny), so at least some of these
big threads are the only thing we got left;)
I think the Lisp question anti-trolling measure is useless.
On 2007-06-16 17:36:41 -0400, ·············@gmail.com"
<············@gmail.com> said:
> Gavino probably isn't a troll, but also probably
> doesn't know that many people will perceive his questions as
> inappropriate.
Gavino should not be responded to because he makes posts with troll
*content* - a quick look at his posting history will show this.
Whether or not he has trolling *intent* is ultimately impossible to
know - I'm inclined to agree that he isn't technically a troll (i.e.,
he doesn't intend merely to draw numerous contentious responses) - but
he may just be a clever troll. Ultimately it doesn't much matter - he
makes troll posts, so he shouldn't be responded to.
Raffael Cavallaro wrote:
> On 2007-06-16 17:36:41 -0400, ·············@gmail.com"
> <············@gmail.com> said:
>
>> Gavino probably isn't a troll,
Proving there is no hope for the human race. Prior art: George Bush,
American voters, Red Sox fans...
On Jun 17, 3:36 am, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2007-06-16 17:36:41 -0400, ·············@gmail.com"
> <············@gmail.com> said:
>
> > Gavino probably isn't a troll, but also probably
> > doesn't know that many people will perceive his questions as
> > inappropriate.
>
> Gavino should not be responded to because he makes posts with troll
> *content* - a quick look at his posting history will show this.
>
> Whether or not he has trolling *intent* is ultimately impossible to
> know - I'm inclined to agree that he isn't technically a troll (i.e.,
> he doesn't intend merely to draw numerous contentious responses) - but
> he may just be a clever troll. Ultimately it doesn't much matter - he
> makes troll posts, so he shouldn't be responded to.
That's probably the best idea with dealing with trolls and flamewars
don't feed them. But people sometimes can't resist, too bad I'm one of
them, so i'll risk of being trolled as long as *potentials - trolls *
at least understands something about programming in lisp, else the
conversation is pure waste of time.
Slobodan Blazeski
I've created a perfect application to predict tomorrows weather. It
only takes 48 hours to do it. Optimization is not an option.
On Jun 16, 11:36 pm, ·············@gmail.com" <············@gmail.com>
wrote:
> On Jun 16, 7:10 am, fireblade <·················@gmail.com> wrote:
>
>
>
>
>
> > On Jun 16, 5:09 am, ·············@gmail.com" <············@gmail.com>
> > wrote:
>
> > > On Jun 15, 2:13 pm, Rainer Joswig <······@lisp.de> wrote:
>
> > > > In article <·······················@u2g2000hsc.googlegroups.com>,
>
> > > > gavino <·········@gmail.com> wrote:
> > > > >http://www.codeforpeople.com/lib/ruby/rq/rq-all-2.3.2/README
> > > > > is there anything like this for lisp?
>
> > > > Don't feed the troll Gavino.
>
> > > > --http://lispm.dyndns.org
>
> > > Even if he is, it's you that is being trolled and doing the feeding.
>
> > What do you think about new approach for dealing with trolls here at
> > c.l.l., when someone sniffs a trollish thread he'll give the
> > potential troll a lisp programming problem. If he gives a correct
> > answer het got replies else silence.
>
> > Slobodan Blazeski
>
> > My apologies to those who like Java, C#, PHP, Delphi, Visual Basic,
> > Perl, Python, Ruby, COBOL, or any other language. I know you think
> > you
> > know a better language than lisp. All I can say is I do, too!
>
> The problem is that some people don't know that a "Why is Lisp better
> than Python" question is inappropriate. The other problem is that
> "trolling" has been transmogrified into "I don't like what you said"
> by so many people. Gavino probably isn't a troll, but also probably
> doesn't know that many people will perceive his questions as
> inappropriate. A lot of the bigger threads, e.g. "A problem statement
> (and a proposed solution)" could almost be perceived as trolling. But
> hey, Lisp is dead (or just smells funny), so at least some of these
> big threads are the only thing we got left;)
>
> I think the Lisp question anti-trolling measure is useless.- Hide quoted text -
>
I don't mind answering even to a troll as long as he at least
understands the subject that this newsgroup is entitled to :
discussion about lisp. From my own experience with this newsgroup the
trollish posts comes from people who don't know a damn thing about
programming lisp.(Harrop, Gavino etc). So it's Ok if he asks why is
Lisp better Python as longs as it has any idea what the hell is
talking about. Or the thread is there anything in lisp like Erlangs
mnesia? Well nothing in his posts doesn't proved that gavino wrote
even a single line of lisp or erlang so I understand his posts as
plain killing time.
Slobodan Blazeski
My apologies to those who like Java, C#, PHP, Delphi, Visual
Basic,Perl, Python, Ruby, COBOL, or any other language. I know you
thinkyou know a better language than lisp. All I can say is I do, too!
············@gmail.com wrote:
> The problem is that some people don't know that a "Why is Lisp better
> than Python" question is inappropriate.
Trying to compare Lisp with any language other than Java is clearly
trolling. I see that now.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
gavino <·········@gmail.com> writes:
> http://www.codeforpeople.com/lib/ruby/rq/rq-all-2.3.2/README
I don't see that there is anything that would prevent using this with
a Lisp-based application.
The combination of usage of:
a) SQLite as the 'locking manager' and
b) The assumption of an NFS-mounted work queue
seem a tad flimsy to me. These aren't components I'd regard as
"really industrial grade" for the more general purpose of job
scheduling.
I don't see why one couldn't build a more sophisticated scheduler
where there would be:
a) A request agent that would submit jobs and specify things about how
they are to be run;
b) An SQL DBMS (probably NOT shared across NFS) to manage storage of
information about the jobs;
c) An "agent" that would run on each machine, polling the DBMS as
needed to determine what jobs it should be spawning, and then
reporting back on results.
I think I'd expect to have a few more features, such as the notion of
marking that Job B should run after Job A finishes successfully, or
that if Job A fails (maybe sends back a failure message / return code)
the agent should spawn job C instead...
I was just chatting with a coworker about this and he mentioned that
he'd set up a rule system for such a scheduler (when developing at one
of those Three Letter Acronymed companies) implemented in Prolog...
--
let name="cbbrowne" and tld="acm.org" in name ^ ·@" ^ tld;;
http://linuxfinances.info/info/rdbms.html
Rules of the Evil Overlord #7. "When I've captured my adversary and he
says, "Look, before you kill me, will you at least tell me what this
is all about?" I'll say, "No." and shoot him. No, on second thought
I'll shoot him then say "No."" <http://www.eviloverlord.com/>
On Jun 15, 2:25 pm, Christopher Browne <········@ca.afilias.info>
wrote:
> gavino <·········@gmail.com> writes:
> >http://www.codeforpeople.com/lib/ruby/rq/rq-all-2.3.2/README
>
> I don't see that there is anything that would prevent using this with
> a Lisp-based application.
>
> The combination of usage of:
> a) SQLite as the 'locking manager' and
> b) The assumption of an NFS-mounted work queue
> seem a tad flimsy to me. These aren't components I'd regard as
> "really industrial grade" for the more general purpose of job
> scheduling.
>
> I don't see why one couldn't build a more sophisticated scheduler
> where there would be:
>
> a) A request agent that would submit jobs and specify things about how
> they are to be run;
>
> b) An SQL DBMS (probably NOT shared across NFS) to manage storage of
> information about the jobs;
>
> c) An "agent" that would run on each machine, polling the DBMS as
> needed to determine what jobs it should be spawning, and then
> reporting back on results.
>
> I think I'd expect to have a few more features, such as the notion of
> marking that Job B should run after Job A finishes successfully, or
> that if Job A fails (maybe sends back a failure message / return code)
> the agent should spawn job C instead...
>
> I was just chatting with a coworker about this and he mentioned that
> he'd set up a rule system for such a scheduler (when developing at one
> of those Three Letter Acronymed companies) implemented in Prolog...
> --
> let name="cbbrowne" and tld="acm.org" in name ^ ·@" ^ tld;;http://linuxfinances.info/info/rdbms.html
> Rules of the Evil Overlord #7. "When I've captured my adversary and he
> says, "Look, before you kill me, will you at least tell me what this
> is all about?" I'll say, "No." and shoot him. No, on second thought
> I'll shoot him then say "No."" <http://www.eviloverlord.com/>
Interesting. I am NOT a troll by the way. This is a fascinating app.
I might have to learn ruby just to check it out. Really cool. SO the
concept could be extended to lisp without much trouble? I work in a
company where we have say 60 servers. about 10 work hard
intermittantly. the other 50 have close to a 0 load avg. I think
this is gross inefficiency. Using rubyqueue would let all the
processors and ram be used and proably speed response time up by
tons. This is the dream. I am amazed more people aren't focusing on
this problem.
So you bought about a 35 or so superflouous machines, did ya ?
Time to hire some network savvy dude.
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
The biggest problem LISP has, is that it does not appeal to dumb people
If that fails to satisfy read the HyperSpec, woman frig or Tuxoharata
mailpolicy @ http://www.clsnet.nl/mail.php
In article <························@q75g2000hsh.googlegroups.com>,
gavino <·········@gmail.com> wrote:
> On Jun 15, 2:25 pm, Christopher Browne <········@ca.afilias.info>
> wrote:
> > gavino <·········@gmail.com> writes:
> > >http://www.codeforpeople.com/lib/ruby/rq/rq-all-2.3.2/README
> >
> > I don't see that there is anything that would prevent using this with
> > a Lisp-based application.
> >
> > The combination of usage of:
> > a) SQLite as the 'locking manager' and
> > b) The assumption of an NFS-mounted work queue
> > seem a tad flimsy to me. These aren't components I'd regard as
> > "really industrial grade" for the more general purpose of job
> > scheduling.
> >
> > I don't see why one couldn't build a more sophisticated scheduler
> > where there would be:
> >
> > a) A request agent that would submit jobs and specify things about how
> > they are to be run;
> >
> > b) An SQL DBMS (probably NOT shared across NFS) to manage storage of
> > information about the jobs;
> >
> > c) An "agent" that would run on each machine, polling the DBMS as
> > needed to determine what jobs it should be spawning, and then
> > reporting back on results.
> >
> > I think I'd expect to have a few more features, such as the notion of
> > marking that Job B should run after Job A finishes successfully, or
> > that if Job A fails (maybe sends back a failure message / return code)
> > the agent should spawn job C instead...
> >
> > I was just chatting with a coworker about this and he mentioned that
> > he'd set up a rule system for such a scheduler (when developing at one
> > of those Three Letter Acronymed companies) implemented in Prolog...
> > --
> > let name="cbbrowne" and tld="acm.org" in name ^ ·@" ^ tld;;http://linuxfinances.info/info/rdbms.html
> > Rules of the Evil Overlord #7. "When I've captured my adversary and he
> > says, "Look, before you kill me, will you at least tell me what this
> > is all about?" I'll say, "No." and shoot him. No, on second thought
> > I'll shoot him then say "No."" <http://www.eviloverlord.com/>
>
> Interesting. I am NOT a troll by the way. This is a fascinating app.
> I might have to learn ruby just to check it out. Really cool. SO the
> concept could be extended to lisp without much trouble? I work in a
> company where we have say 60 servers. about 10 work hard
> intermittantly. the other 50 have close to a 0 load avg. I think
> this is gross inefficiency. Using rubyqueue would let all the
> processors and ram be used and proably speed response time up by
> tons. This is the dream. I am amazed more people aren't focusing on
> this problem.
You are a troll.
--
http://lispm.dyndns.org
On Jun 16, 2:42 am, gavino <·········@gmail.com> wrote:
> Interesting. I am NOT a troll by the way.
Everything in your history says you are. But I'll give you a chance.
Everytime you ask some trollish question I'll give you a lisp problem.
If you solve it you'll get an answer.Deal ?
Here we go:
Extract a given number of randomly selected elements from a list.
The selected items shall be returned in a list.
Example:
* (rnd-select '(a b c d e f g h) 3)
(E D A)
Slobodan Blazeski
On Jun 16, 1:42 am, gavino <·········@gmail.com> wrote:
I am amazed more people aren't focusing on
> this problem.
You've heard of that whole "virtualisation" bandwagon, right? Well.
The world rejoiced as Tim Bradshaw <··········@tfeb.org> wrote:
> On Jun 16, 1:42 am, gavino <·········@gmail.com> wrote:
> I am amazed more people aren't focusing on
>> this problem.
>
> You've heard of that whole "virtualisation" bandwagon, right? Well.
But virtualization is more or less the opposite of this.
With virtualization, you try to run a bunch of virtual machines on one
physical server. The idea tends to be: "I want to put in a few BIG
servers, and run services on them, each on its own virtual machine."
The "supercomputer view" of job scheduling was very much the opposite;
you simply had calc work to get done, and a bunch of machines that
tend to look sufficiently similar to one another.
Then there's the "mainframe view" of job scheduling, which tends to be
all about the dependancies of which jobs can hit the database
simultaneously, and which jobs have to run after other jobs. e.g. -
first, you need to run the batch jobs that handle salary updates, and
only after that is done can you run a payroll calc. And after the
payroll calc, you print paychecks. And you can, concurrently with
that, post cost allocations to the cost accounting system.
The latter one is one I'm interested in answers to; we've got way too
many servers at the office running way too many instances of "cron."
And cron is way too primitive to manage things well enough...
--
(format nil ···@~S" "cbbrowne" "linuxfinances.info")
http://linuxdatabases.info/info/internet.html
Health is merely the slowest possible rate at which one can die.
On Jun 18, 2:27 am, Christopher Browne <········@acm.org> wrote:
>
> > You've heard of that whole "virtualisation" bandwagon, right? Well.
>
> But virtualization is more or less the opposite of this.
I was being confusing, or perhaps confused. I was responding to the
bit of his message where he talked about machine utilisation (though
not in those terms). Virtualisation ought to be, and occasionally is,
a mechanism of driving up machine utilisation by, well, virtualising
things (in just the same way that virtual memory is, among other
things, a way of driving up physical memory utilisation). Of course,
in practice, it tends to be used for taking a bunch of creaky old
machines running some poorly-understood-yet-vital applcation on
Windows 98 and OS/2 and piling them all into one shiny new machine
without having to think about too hard about the horror of it all.
Even this, though, is driving up utilisation, generally particularly
in the sense of saving expensive rack space.
--tim
In an attempt to throw the authorities off his trail, Tim Bradshaw <··········@tfeb.org> transmitted:
> Even this, though, is driving up utilisation, generally particularly
> in the sense of saving expensive rack space.
That's fine; when it comes to running batch jobs in such an
environment:
1. If the point is merely to drive up utilization, that's the easy
problem. And I don't you needed virtualization to do that...
2. Spreading the jobs "smoothly, like smooth peanut butter" is
usually pretty easy. The challenge is when you have a set of jobs
that have mutual-exclusivity requirements and the likes.
In effect, when they have non-idempotent effects on data where there
are codependancies.
If you can solve the harder problems, the smaller problems wind up
being trivial...
--
(format nil ···@~S" "cbbrowne" "gmail.com")
http://linuxdatabases.info/info/spreadsheets.html
"It has every known bug fix to everything." -- KLH (out of context)
Christopher Browne wrote:
> The world rejoiced as Tim Bradshaw <··········@tfeb.org> wrote:
>> On Jun 16, 1:42 am, gavino <·········@gmail.com> wrote:
>> I am amazed more people aren't focusing on
>>> this problem.
>>
>> You've heard of that whole "virtualisation" bandwagon, right? Well.
>
> But virtualization is more or less the opposite of this.
Not always. XenSource can do this for you, for example.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
gavino wrote:
> This is the dream. I am amazed more people aren't focusing on
> this problem.
They are, just using better languages. Check out JoCaml, for example.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet