Vladimir Sedach writes:
> Is there a portable way to create a simple-style-warning condition
> that when signaled with WARN won't cause SLIME to claim that file
> compilation failed, that works for all/most CL implementations?
>
> I'm trying to use this:
>
> (define-condition simple-style-warning
Is there a portable way to create a simple-style-warning condition
that when signaled with WARN won't cause SLIME to claim that file
compilation failed, that works for all/most CL implementations?
I'm trying to use this:
(define-condition simple-style-warning (style-warning simple-warning)
())
I really didn't appreciate this whole discussion, but I think I can
contribute a few points about how to think about the problem so that
things like this will stop happening.
There are two assertions being made here:
* "Lisp is falling behind"
* "To stop Lisp falling behind, we need to do "
No o
It causes me less heartburn during development being a Filer as I use several
foreign libraries. But I deploy executables.
-Luke
___
pro mailing list
pro@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
On 20 January 2011 13:16, Sam Steingold wrote:
> On Thu, Jan 20, 2011 at 4:02 PM, Drew Crampsie wrote:
>> The root of the perceived problem is a lack of resources, not a lack
>> of effort or desire on the part of the "lisp community".
>
> I think Franz, Lispworks, ITA et al are vital parts of th
Correction:
Daniel Weinreb wrote:
>
> As for me, if the Google acquisition of ITA happens, chances
> are that I won't be allowed to use Common Lisp,
Sorry, what I meant was that it was unlikely
that we'd be able to use Common Lisp for
NEW projects. I am confident that Google
is not so brain-dead
On Thu, Jan 20, 2011 at 10:16 PM, Sam Steingold wrote:
> I think Franz, Lispworks, ITA et al are vital parts of the "lisp community".
> I think the fact that none of them is paying anyone to maintain SLIME,
> ALU wiki, common-lisp.net &c
> is indicative of understandable but deplorable corporate
I would like to add, that in our community seems to be a very low
collaboration factor between random developers working on OSS
software, in comparison to other communities.
One would say, sure there are a lot of distinct interests, but this
happens even on common interests (decent utilities librar
Sam Steingold wrote on Thu, Jan 20, 2011 at 04:16:10PM -0500:
>
> I think Franz, Lispworks, ITA et al are vital parts of the "lisp community".
> I think the fact that none of them is paying anyone to maintain SLIME,
> ALU wiki, common-lisp.net &c
> is indicative of understandable but deplorable c
On Thu, Jan 20, 2011 at 4:02 PM, Drew Crampsie wrote:
>
> I do, however, think that comparing the work produced by the open
> source CL community to that produced by multi-billion dollar
> corporations is both unfair and counter-productive. Apple and Google
> have something to sell, and are aggres
On 20 January 2011 12:03, Daniel Weinreb wrote:
> Alexander,
>
> Here's my own interpretation of what Drew said, which I admit
> may or may not be what he had in mind. (I do agree that he
> said it in a rude way.)
In my own defense, i immediately followed up with this :
"Didn't quite mean to be
On Thu, 20 Jan 2011, Pascal Costanza wrote:
> One of the things you can also notice in the communities of more
> popular languages is that people get a lot more positive feedback,
> including for a lot more trivial contributions. I believe that this
> is one of the reasons (not the only one) why t
Alex,
I think your approach is counterproductive. The Common Lisp community is not
very large, and to the best of my knowledge, the majority of people _I_ know
who are part of this community really try hard to improve the infrastructure,
the libraries and the tools, to the extent they can affor
Alexander,
Here's my own interpretation of what Drew said, which I admit
may or may not be what he had in mind. (I do agree that he
said it in a rude way.) The heart of what he wrote is:
>>
>> And i'm not convinced a mailing list for professional lisp developers
>> needs more diatribes explainin
On 20 January 2011 11:46, Alexander Repenning wrote:
> Hi Drew,
> perhaps the point of a mailing list for professional lisp developers is to
> act, well ... professional?
Is it professional to publish what was intended as private
correspondence on a public mailing list?
> Remember one of the po
As one of the list moderators, might I interject two words here:
"please" and "stop"?
I agree with Drew's sentiments, if not completely with his tone.
But if his tone offends you or anyone else, please reply to him
off-list.
Let's keep this list very focused. Thanks!
--Scott
On Jan 20, 2011, a
Hi Drew,
perhaps the point of a mailing list for professional lisp developers is to act,
well ... professional?
Remember one of the points made in original article about the Lisp community:
"The community isn’t nearly as blood thirsty as some people might portrait it."
Seems to me you just co
Faré wrote:
> For making images, there is
> * Xach's buildapp, which is great but sbcl-only
> * my own cl-launch, which is portable, and can be complemented with my
> command-line-argument library, or Didier Verna's CLON (ported only to
> a few platforms).
More precisely, Clon supports SBCL, C
On Thu, Jan 20, 2011 at 07:45, Ala'a Mohammad wrote:
> I'm interested to hear what others use CL. How do
> they manage day to day work? how do their preferred style mesh into
> their production pipeline (coding, debugging, deployment and
> maintenance)? and what makes them prefer one way over anot
On Thursday 20 January 2011 11:49 PM, Peter Seibel wrote:
> I'm a filer. With ASDF and even more so these days with Quicklisp,
> it's just easier to load the stuff I need and it doesn't take that
> long and it saves me having to spend any mental energy keeping track
> of different images.
I agree.
Alexander Repenning wrote:
> is still mostly true but as I am tracking the speed of JavaScript
> versus Common Lisp I can see a scary performance cross over point in
> the near future (months). Already, in some of our benchmarks
> JavaScript running in OS X Chrome is getting very close (10% ga
I'd say I'm 70% imager, 30% filer. I usually save an image with
libraries I'm using, but then load more stuff on top of that when I
start.
-- Scott
___
pro mailing list
pro@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
[Forgot to reply all, so this went as a private mail to Alexander]
On Thursday 20 January 2011 09:34 PM, Alexander Repenning wrote:
> would be to compile it down to JavaScript, yes, JavaScript, not C
So you mean that Javascript will eventually become faster than C? If so,
then its not a problem
I use files and quicklisp when developing, but deliver and provision
binary images.
Most of my apps are web based, and i run the lisp image behind runit,
a service manager that handles logging as well as startup and
shutdown, and restarting the image if it crashes. It also makes
rolling back a rel
Alex: I realize this isn't your central point but I'm curious what
benchmark(s) you're citing?
On Thu, Jan 20, 2011 at 11:04 AM, Alexander Repenning wrote:
> One point made:
>
> > It’s probably faster than most dynamic languages.
>
> is still mostly true but as I am tracking the speed of JavaScr
[Once again I forgot to Reply All. Ala, you've seen part of this before.]
I'm a filer. With ASDF and even more so these days with Quicklisp,
it's just easier to load the stuff I need and it doesn't take that
long and it saves me having to spend any mental energy keeping track
of different images.
On Thu, Jan 20, 2011 at 11:38 AM, Alessio Stalla wrote:
> Are there big systems written in JS? I'm not aware of any.
>
Not stand-alone desktop apps, but Google's browser-hosted applications (the
GoogleDocs suite, GMail, Maps) are written in JavaScript (using their
unfortunately named Closure tool
On Jan 20, 2011, at 10:08 AM, Brian Taylor wrote:
> Alex: I realize this isn't your central point but I'm curious what
> benchmark(s) you're citing?
Hi Brian,
Here is an older list of application level (computation + visualization)
benchmarks: http://weup.sourceforge.net/demos/rm/index.html
Alessio Stalla wrote on Thu, Jan 20, 2011 at 05:46:15PM +0100:
> On Thu, Jan 20, 2011 at 5:43 PM, Martin Cracauer
> wrote:
> > Alessio Stalla wrote on Thu, Jan 20, 2011 at 05:38:03PM +0100:
> >> On Thu, Jan 20, 2011 at 5:04 PM, Alexander Repenning
> >> wrote:
> >> > One point made:
> >> >
> >> >
Ala'a Mohammad wrote on Thu, Jan 20, 2011 at 07:45:29PM +0400:
> Hi,
>
> I'm continually learning Common-lisp and trying to find the best style
> that suites me better. I've tried 'an imager' style (cooking a an
> image with all required libraries loaded when required), and 'a filer'
> style (loa
On Thu, Jan 20, 2011 at 5:43 PM, Martin Cracauer
wrote:
> Alessio Stalla wrote on Thu, Jan 20, 2011 at 05:38:03PM +0100:
>> On Thu, Jan 20, 2011 at 5:04 PM, Alexander Repenning
>> wrote:
>> > One point made:
>> >
>> >> It?s probably faster than most dynamic languages.
>> >
>> > is still mostly tr
On Thu, Jan 20, 2011 at 4:45 PM, Ala'a Mohammad wrote:
> I'm continually learning Common-lisp and trying to find the best style
> that suites me better. I've tried 'an imager' style (cooking a an
> image with all required libraries loaded when required), and 'a filer'
> style (loading files or sys
I haven't looked at cl-launch in a while, but remember it looking promising.
Thanks.
I also looked briefly into ASDF2 but can't remember recognizing any
advantages to moving to it from ASDF. I am sure the advantages are there
though. What am I missing?
On Thu, Jan 20, 2011 at 8:34 AM, Faré wro
Alessio Stalla wrote on Thu, Jan 20, 2011 at 05:38:03PM +0100:
> On Thu, Jan 20, 2011 at 5:04 PM, Alexander Repenning
> wrote:
> > One point made:
> >
> >> It?s probably faster than most dynamic languages.
> >
> > is still mostly true but as I am tracking the speed of JavaScript versus
> > Commo
On Thu, Jan 20, 2011 at 5:04 PM, Alexander Repenning
wrote:
> One point made:
>
>> It’s probably faster than most dynamic languages.
>
> is still mostly true but as I am tracking the speed of JavaScript versus
> Common Lisp I can see a scary performance cross over point > in the near
> future (m
On 20 January 2011 11:16, Jacob Kozinn wrote:
> This is the best thing I've read on the Pro list so far, I think.
> I'm a filer, but as I deploy multiple cloud instances, I'm starting to think
> about the advantages of imaging.
> However, I have little experience with it. Especially on Debian.
> A
This is the best thing I've read on the Pro list so far, I think.
I'm a filer, but as I deploy multiple cloud instances, I'm starting to think
about the advantages of imaging.
However, I have little experience with it. Especially on Debian.
Anybody have good resources on imaging that are not obt
One point made:
> It’s probably faster than most dynamic languages.
is still mostly true but as I am tracking the speed of JavaScript versus Common
Lisp I can see a scary performance cross over point in the near future
(months). Already, in some of our benchmarks JavaScript running in OS X Chro
Hi,
I'm continually learning Common-lisp and trying to find the best style
that suites me better. I've tried 'an imager' style (cooking a an
image with all required libraries loaded when required), and 'a filer'
style (loading files or systems each time I fire-up a CL
implementation). I'm interest
39 matches
Mail list logo
