From: Kenny Tilton
Subject: (Summer of (Lisp) Code)
Date: 
Message-ID: <9Zfve.14352$XB2.3730192@twister.nyc.rr.com>
Google has approved nine applicants to be mentored by Lisp-NYC. Franz 
seems to be funding one as well, so that makes ten.

Who says there are no Lisp jobs? :)

Which nine is not clear, but I have heard from two: one to take UFFI to 
the next level (extending my Hello-C fork), and one to autogen bindings 
and glue for C/C++. My dream is listing a C header in a defsystem file 
as the only step necessary to "link" to a library.

Franz, if all goes well, is sponsoring a FireFox Lisp plugin. Watch this 
space for announcements in re applying (same deal, students only).

As for the rejected applications, we have heard rumblings that some will 
do their projects anyway. It is up to the individual mentor, of course, 
but Lisp-NYC will likely also mentor anyway.

btw, Lisp-NYC was just a convenient place for Google to place its Lisp 
hat.* All projects, by reason and Google edict, will be hosted on 
something like SourceForge (ie, on common-lisp.net <g>). Anyone from the 
CL community interested in a project can and should help out. Watch this 
space for announcments.

* otoh, Lisp-NYC is formally the mentor in re final approval of 
applicant's work.


-- 
Kenny

Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film

"If you plan to enter text which our system might consider to be 
obscene, check here to certify that you are old enough to hear the 
resulting output." -- Bell Labs text-to-speech interactive Web page

From: Rahul
Subject: Re: (Summer of (Lisp) Code)
Date: 
Message-ID: <1119732041.527892.310870@g44g2000cwa.googlegroups.com>
Hi.
it seems that the list has come up on the lispnyc.org's summer of code
page.
it includes :
1.hello-c
2.portable sockets using hello-c
3.stepper for slime
and some others.
hello-c and portable sockets are particularly good news.
hey kenny you are the mentor for the hello-c thing?
rahul

Kenny Tilton wrote:
> Google has approved nine applicants to be mentored by Lisp-NYC. Franz
> seems to be funding one as well, so that makes ten.
>
> Who says there are no Lisp jobs? :)
>
> Which nine is not clear, but I have heard from two: one to take UFFI to
> the next level (extending my Hello-C fork), and one to autogen bindings
> and glue for C/C++. My dream is listing a C header in a defsystem file
> as the only step necessary to "link" to a library.
>
> Franz, if all goes well, is sponsoring a FireFox Lisp plugin. Watch this
> space for announcements in re applying (same deal, students only).
>
> As for the rejected applications, we have heard rumblings that some will
> do their projects anyway. It is up to the individual mentor, of course,
> but Lisp-NYC will likely also mentor anyway.
>
> btw, Lisp-NYC was just a convenient place for Google to place its Lisp
> hat.* All projects, by reason and Google edict, will be hosted on
> something like SourceForge (ie, on common-lisp.net <g>). Anyone from the
> CL community interested in a project can and should help out. Watch this
> space for announcments.
>
> * otoh, Lisp-NYC is formally the mentor in re final approval of
> applicant's work.
>
>
> --
> Kenny
>
> Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
>
> "If you plan to enter text which our system might consider to be
> obscene, check here to certify that you are old enough to hear the
> resulting output." -- Bell Labs text-to-speech interactive Web page
From: Kenny Tilton
Subject: Re: (Summer of (Lisp) Code)
Date: 
Message-ID: <5mjve.14983$XB2.3746896@twister.nyc.rr.com>
Rahul wrote:

> Hi.
> it seems that the list has come up on the lispnyc.org's summer of code
> page.
> it includes :
> 1.hello-c
> 2.portable sockets using hello-c
> 3.stepper for slime
> and some others.
> hello-c and portable sockets are particularly good news.
> hey kenny you are the mentor for the hello-c thing?

technically, Lisp-NYC is the mentor, and I would love anyone with a deep 
interest to track the project mailing list and offer insights. This goes 
for the whole cl community. Especially since an early task is 
identifying any and all issues with UFFI as it stands, since I gather 
there are a couple of things to address. And then you have the many Lisp 
implementations and OSes to cover, so folks with special expertise or 
who can simply DL and use the thing to identify flaws would be 
especuially helpful.

I am just the lead person who proposed the project and worked with Luis 
on the proposal.

ps. I told Brian I was sitting next to you at his talk, so back me up on 
that if he asks, OK?

-- 
Kenny

Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film

"If you plan to enter text which our system might consider to be 
obscene, check here to certify that you are old enough to hear the 
resulting output." -- Bell Labs text-to-speech interactive Web page
From: Rahul
Subject: Re: (Summer of (Lisp) Code)
Date: 
Message-ID: <1119734748.413442.171260@o13g2000cwo.googlegroups.com>
Kenny Tilton wrote:
> Rahul wrote:
>
> > Hi.
> > it seems that the list has come up on the lispnyc.org's summer of code
> > page.
> > it includes :
> > 1.hello-c
> > 2.portable sockets using hello-c
> > 3.stepper for slime
> > and some others.
> > hello-c and portable sockets are particularly good news.
> > hey kenny you are the mentor for the hello-c thing?
>
> technically, Lisp-NYC is the mentor, and I would love anyone with a deep
> interest to track the project mailing list and offer insights. This goes
> for the whole cl community. Especially since an early task is
> identifying any and all issues with UFFI as it stands, since I gather
> there are a couple of things to address. And then you have the many Lisp
> implementations and OSes to cover, so folks with special expertise or
> who can simply DL and use the thing to identify flaws would be
> especuially helpful.
>
> I am just the lead person who proposed the project and worked with Luis
> on the proposal.
>
> ps. I told Brian I was sitting next to you at his talk, so back me up on
> that if he asks, OK?

well...i am not THE rahul who was there....i am a different rahul.
From: William Bland
Subject: Re: (Summer of (Lisp) Code)
Date: 
Message-ID: <pan.2005.06.25.21.18.30.790632@abstractnonsense.com>
On Sat, 25 Jun 2005 13:40:41 -0700, Rahul wrote:

> Hi.
> it seems that the list has come up on the lispnyc.org's summer of code
> page.
> it includes :
> 3.stepper for slime

Does anyone actually find step-debuggers useful?  I find they work on
completely the wrong level of abstraction and are useless for actually
finding bugs.  Maybe that's just me though?

Cheers,
	Bill.
From: Steven E. Harris
Subject: Re: (Summer of (Lisp) Code)
Date: 
Message-ID: <83vf42aw89.fsf@torus.sehlabs.com>
William Bland <·······@abstractnonsense.com> writes:

> I find they work on completely the wrong level of abstraction and
> are useless for actually finding bugs.

What level of abstraction are you looking for instead?

-- 
Steven E. Harris
From: William Bland
Subject: Re: (Summer of (Lisp) Code)
Date: 
Message-ID: <pan.2005.06.25.23.27.39.917361@abstractnonsense.com>
On Sat, 25 Jun 2005 15:48:54 -0700, Steven E. Harris wrote:

> William Bland <·······@abstractnonsense.com> writes:
> 
>> I find they work on completely the wrong level of abstraction and
>> are useless for actually finding bugs.
> 
> What level of abstraction are you looking for instead?

The one where you treat code as a black, or at least grey, box and stop poking
around in its internals for a while.

Bugs get fixed when people form hypotheses, think of tests for those
hypotheses, and either verify them or not.  Repeat until problem is found
and fixed.  It's a simple application of the Scientific Method.

Jumping into the code and stepping through it to "just see what it's
doing" seems like a waste of time to me.  From what I've seen it only
encourages people to believe that they don't need to form mental models of
the programs they write, and hypotheses about the causes of their bugs.

Cheers,
	Bill.
From: Tim X
Subject: Re: (Summer of (Lisp) Code)
Date: 
Message-ID: <87psu9bwyq.fsf@tiger.rapttech.com.au>
William Bland <·······@abstractnonsense.com> writes:

> On Sat, 25 Jun 2005 15:48:54 -0700, Steven E. Harris wrote:
> 
> > What level of abstraction are you looking for instead?
> 
> The one where you treat code as a black, or at least grey, box and stop poking
> around in its internals for a while.
> 
> Bugs get fixed when people form hypotheses, think of tests for those
> hypotheses, and either verify them or not.  Repeat until problem is found
> and fixed.  It's a simple application of the Scientific Method.
> 
> Jumping into the code and stepping through it to "just see what it's
> doing" seems like a waste of time to me.  From what I've seen it only
> encourages people to believe that they don't need to form mental models of
> the programs they write, and hypotheses about the causes of their bugs.
> 

Yes, Yes - exactly my feelings on this. I believe I've actually
observed a loss of skill wrt debugging with the growth in IDEs with
integrated debuggers which allow you to step through code. While
'steppers' can be useful in some very difficult bug squashing -
especially low level 'system' type bugs, I have observed a growing
tendency amongst new programmers in which thy rely on stepping through
code and watching variables/pointers change rather than develop a good
mental model of how the system fits together and how it works - I also
find they are often slower at debugging and often introduce fixes
which introduce new bugs because they don't actually understand what
is going on and will often address a symptom rather than the root
cause of a problem. 

-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!
From: justinhj
Subject: Re: (Summer of (Lisp) Code)
Date: 
Message-ID: <1119803600.070904.187960@g44g2000cwa.googlegroups.com>
Personally I find stepping through new code in a debugger after it is
written is a great way to test it.

Every new tool gives you a new way to write better code, although I
agree that over using any one particular tool is a bad thing.
From: Steven E. Harris
Subject: Re: (Summer of (Lisp) Code)
Date: 
Message-ID: <838y0xnfkp.fsf@torus.sehlabs.com>
Tim X <····@spamto.devnul.com> writes:

> While 'steppers' can be useful in some very difficult bug squashing
> - especially low level 'system' type bugs,

My most recent difficult C++ debugging session was exactly of this
sort: Trying to figure out why some bitmask check converted to an
integer later interpreted as a boolean yielded the wrong answer.

It turned out that the boolean variable in question was not a true C++
"bool"; it was an integer interpreted with 0 as false and 1 as
true. The bitmask test would have yielded a proper answer as a bool,
but yielded neither true nor false in many cases with the
pseudo-bool-int variable and was hence misinterpreted by other parts
of the program.

Poor use of types or sloppy conversion was the culprit, but no amount
of higher-level conceptualizing would have helped here. Perhaps some
concentrated "desk checking" of the code would have been more
fruitful.

-- 
Steven E. Harris