Re: [fonc] Reading Maxwell's Equations

[Brian Gilman]

http://vpri.org/mailman/private/fonc/2009/001145.html

cc1: warnings being treated as errors

CodeGenerator-local.o.c: In function
‘DynamicIntel32CodeGenerator__jeL_’:
CodeGenerator-local.o.c:4918: warning: value computed is not used
CodeGenerator-local.o.c: In function
‘DynamicIntel32CodeGenerator__jgeL_’:
CodeGenerator-local.o.c:4934: warning: value computed is not used
CodeGenerator-local.o.c: In function
‘DynamicIntel32CodeGenerator__jmpL_’:
CodeGenerator-local.o.c:4966: warning: value computed is not used
CodeGenerator-local.o.c: In function
‘DynamicIntel32CodeGenerator__jneL_’:
CodeGenerator-local.o.c:4982: warning: value computed is not used
make[2]: *** [CodeGenerator-local.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

If memory serves me correctly, I tried disabling warnings as errors, but
then ran into other issues.

This is on Snow Leopard, running Xcode 3.2 beta 1, had the same issue with
Xcode 3.1.
I tried both repos, as well as the source tarball that's posted.

On Mon, Mar 1, 2010 at 5:57 AM, Michael Haupt <
michael.ha...@hpi.uni-potsdam.de> wrote:

> Brian,
>
> Am 28.02.2010 um 16:29 schrieb Brian Gilman:
> > After hearing about the project, I downloaded the source, and attempted
> to compile on OS X, which wouldn't compile.
>
> any details?
>
> Best,
>
> Michael
>
> --
> Dr.-Ing. Michael Hauptmichael.ha...@hpi.uni-potsdam.de
> Software Architecture Group   Phone:  ++49 (0) 331-5509-542
> Hasso Plattner Institute for  Fax:++49 (0) 331-5509-229
> Software Systems Engineering  http://www.hpi.uni-potsdam.de/swa/
> Prof.-Dr.-Helmert-Str. 2-3, D-14482 Potsdam, Germany
>
> Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Potsdam
> Amtsgericht Potsdam, HRB 12184
> Geschäftsführung: Prof. Dr. Christoph Meinel
>
>
>
>
>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Dan Amelang]

On Sun, Feb 28, 2010 at 2:21 PM, Reuben Thomas  wrote:
> On 28 February 2010 22:16, Dan Amelang  wrote:
>> (standard disclaimer: I don't represent the official stance of VPRI or Alan 
>> Kay)
>>
>> On Sun, Feb 28, 2010 at 6:37 AM, Reuben Thomas  wrote:
>>
>>> and the projects directly linked to on the "Our work" page
>>> did not originate at VPRI (Squeak Etoys & Croquet).
>>
>> It was the pretty much the same group of people, but the group has
>> been hosted by different organizations over the years (Disney, HP,
>> etc.)
>
> Indeed, but all this stuff is rather old now. That it's still in the
> headlines is worrying.

Obviously one's definition of "old" factors into the discussion.

I'm more worried about how all the supposedly "new stuff" dominates headlines :)

Dan

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Dan Amelang]

On Sun, Feb 28, 2010 at 1:48 PM, Reuben Thomas  wrote:
> On 28 February 2010 17:53, Andrey Fedorov  wrote:
>> Considering the ambition of the project relative to its resources, I think
>> it's reasonable for STEPS to keep a low profile and spend less effort on
>> "educating" than one might like.
>
> A software research project that does not aggressively push its code
> out is a waste of time.

We'll have to agree to disagree, then. My understanding of the history
of computer science does not seem to line up with this assertion,
though.

Dan

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Reuben Thomas]

On 28 February 2010 22:38, Dan Amelang  wrote:
> On Sun, Feb 28, 2010 at 8:50 AM, Reuben Thomas  wrote:
>>
>> I think it's scandalous that a publically-funded non-secret project
>> does not have far stricter requirements for public engagement than are
>> apparent here.
>
> Scandalous!

Oh dear, I was simultaneously wearing my Victorian and my tax-payer's
hat (though I pay taxes to a government that spends rather less on
research than the US government). Still...

> :) Actually, in my experience, many publically (sic)
> -funded projects don't have public repositories that are updated in
> real-time (like many of ours are). So the scandal may be more
> widespread than we initially suspected!

...this really is a scandal. Nothing to do with VPRI, though.

> please consider what I said about incubating great ideas.

>From what I recall of academia, ideas have to put up with the worst
scrutiny long before they go public...

-- 
http://rrt.sc3d.org

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Dan Amelang]

On Sun, Feb 28, 2010 at 9:53 AM, Andrey Fedorov  wrote:
> Considering the ambition of the project relative to its resources, I think
> it's reasonable for STEPS to keep a low profile and spend less effort on
> "educating" than one might like.

Thank you :) We do have limited resources and wild ambitions. And I
won't be able to answer emails as thoroughly as I am today for that
reason.

> That said, I'd appreciate a simple "suggested reading" list for independent
> study - in my case, for someone with an undergrad in CS.

A reasonable suggestions. Besides the list on the vpri website, you
could also look at the references in the writings. Also, Alan likes to
give people references to read, so you could try him, and report back
here (with his permission).

Dan

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Dan Amelang]

On Sun, Feb 28, 2010 at 8:50 AM, Reuben Thomas  wrote:
>
> Think of a software project as like Plato's model of the soul as a
> charioteer with two horses, one immortal and one mortal, only without
> the goal of reaching heaven. The mortal horse is the imperatives of
> the real world: developers, money, users, releases and so on, while
> the immortal horse represents elegance, simplicity, performance,
> design perfection. A successful project usually manages to keep the
> two horses in relative harmony, making something good and practical.
> VPRI seems to have started off with just the immortal horse

This could well be. How else should an ambitious research project start off?

Research in general involves incubating fragile ideas that might not
be ready to face what you call the "real world" (assuming earth is
more real than heaven :)
Money, users, releases, etc.

> In other words, I think you have it the wrong way round: it is
> precisely by caring about one's public that one fixes the rough edges

One man's rough edge is another's great idea in the making :)

> I think it's scandalous that a publically-funded non-secret project
> does not have far stricter requirements for public engagement than are
> apparent here.

Scandalous! :) Actually, in my experience, many publically (sic)
-funded projects don't have public repositories that are updated in
real-time (like many of ours are). So the scandal may be more
widespread than we initially suspected!

> I would add that the reason I care is because I have a great deal of
> respect for Ian Piumarta in particular: I was blown away by his
> Virtual Virtual Machine work when I went to INRIA Rocquencourt in
> 1999, greatly impressed by his code generation work on Smalltalk (at
> least that did get out the door), and really excited when I first came
> across COLA. This stuff should be out there!

Ian does do great stuff. And much of his work is out there:

http://piumarta.com/software/

And there is more coming. But please consider what I said about
incubating great ideas.

Dan

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Reuben Thomas]

On 28 February 2010 22:16, Dan Amelang  wrote:
> (standard disclaimer: I don't represent the official stance of VPRI or Alan 
> Kay)
>
> On Sun, Feb 28, 2010 at 6:37 AM, Reuben Thomas  wrote:
>
>> and the projects directly linked to on the "Our work" page
>> did not originate at VPRI (Squeak Etoys & Croquet).
>
> It was the pretty much the same group of people, but the group has
> been hosted by different organizations over the years (Disney, HP,
> etc.)

Indeed, but all this stuff is rather old now. That it's still in the
headlines is worrying.

-- 
http://rrt.sc3d.org

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Dan Amelang]

(standard disclaimer: I don't represent the official stance of VPRI or Alan Kay)

On Sun, Feb 28, 2010 at 6:37 AM, Reuben Thomas  wrote:
> On 27 February 2010 08:08, Dan Amelang  wrote:
>> (Regarding your puzzling over Alan's views, though, you might want to
>> try emailing him directly. After you've done due diligence reading up
>> on the subject, of course.)
>
> Although it would be of far greater value if such an exchange took
> place in public, e.g. on this list.

Sure. FYI, Alan may not be on this list. Of course, one can write him
and invite him to participate in a discussion here about clarifying
certain views of his.

Either way, I suggest going to the source and clarifying before
drawing conclusions.

> VPRI seems really bad at actually getting publicity for its work:

Could be. Obviously this is not a top goal at this point in the
project. Getting publicity isn't always good (yes, I'm familiar with
the popular phrase :). And even when you want it, it does take effort.
And it commits you to a certain extent, because people want to have a
consistent story, so backtracking is harder. But often to make
progress, you have to change your mind. Also, in the exploratory
stages of an ambitious project, you don't want to get bogged down
handling bug reports.

Things may very well change later in the project when it might make
more sense to "productize" the research.

> There isn't even a "software" link on the home page of
> vpri.org,

That may be a mistake, as the link _does_ show up on the other pages
(it would help if you emailed i...@vpri.org about this)

> and the projects directly linked to on the "Our work" page
> did not originate at VPRI (Squeak Etoys & Croquet).

It was the pretty much the same group of people, but the group has
been hosted by different organizations over the years (Disney, HP,
etc.)

Dan

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Michael Haupt]

Brian,

Am 28.02.2010 um 16:29 schrieb Brian Gilman:
> After hearing about the project, I downloaded the source, and attempted to 
> compile on OS X, which wouldn't compile.

any details?

Best,

Michael

-- 
Dr.-Ing. Michael Hauptmichael.ha...@hpi.uni-potsdam.de
Software Architecture Group   Phone:  ++49 (0) 331-5509-542
Hasso Plattner Institute for  Fax:++49 (0) 331-5509-229
Software Systems Engineering  http://www.hpi.uni-potsdam.de/swa/
Prof.-Dr.-Helmert-Str. 2-3, D-14482 Potsdam, Germany 

Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Potsdam
Amtsgericht Potsdam, HRB 12184
Geschäftsführung: Prof. Dr. Christoph Meinel






___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Reuben Thomas]

On 28 February 2010 17:53, Andrey Fedorov  wrote:
> Considering the ambition of the project relative to its resources, I think
> it's reasonable for STEPS to keep a low profile and spend less effort on
> "educating" than one might like.

A software research project that does not aggressively push its code
out is a waste of time. Many quite possibly excellent ideas have sunk
in the past few decades for lack of exposure. ("Quite possibly"
because without that exposure it's well-night impossible to tell how
good they are.)

> *That* said, this section is wonderful.

Thanks very much for that pointer. Interesting reading, but code is
worth more...

-- 
http://rrt.sc3d.org

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Reuben Thomas]

On 28 February 2010 20:09, Kurt Stephens  wrote:
> Reuben Thomas wrote:
>>
>> On 26 February 2010 23:15, John Zabroski  wrote:
>>>
>>> These three physical coupling issues
>>> (block-structured, procedural message passing; manual memory management;
>>> manual concurrency) are things the average programmer should never have
>>> to
>>> touch,
>>
>> I don't remember seeing block struturing ever being described as one
>> of the "things the average programmer should never have to touch";
>> could you elaborate on how it's bad, please?
>>
> I agree with Reuben here.

I should point out that I'm not disagreeing with the assertion that
block structuring is bad; rather, just that to me it's always been
axiomatically an attribute of most non-trivial programming languages,
neither good nor bad, but in fact unexamined. Hence, I was intrigued
to see it mentioned as a bad thing, especially so prominently.

-- 
http://rrt.sc3d.org

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Smalltalk hardware (was: Reading Maxwell's Equations)

[Jecel Assumpcao Jr]

Kurt Stephens wrote:

> Smalltalk did not spawn an entire industry of specialized hardware like 
> Lisp.

There was a lot more development in that area than most people are aware
of:

http://www.merlintec.com:8080/hardware/26

> However Lisp hardware is a collector's item now. :)

Only two architectures from that era have modern implementations. Being
*the* C/Unix machine for years and years didn't save the VAX, for
example. So I am for trying again to see what happens.

-- Jecel


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Kurt Stephens]

Alejandro F. Reimondo wrote:

John,
 
 >Where else should I look?
 
In my opinion what is "missing" in the languages

 formulations is sustainability of the system. [*]
In case of formula/abstract based declaration of systems
 all alternatives make people put on the idea(L) side
 and not in the system itself (the natural side).
Smalltalk is the only alternative of sustainable system
 development used commertially today.


Smalltalk did not spawn an entire industry of specialized hardware like 
Lisp.  However Lisp hardware is a collector's item now. :)


There are plenty of commercial projects using Common Lisp today and from 
what I can tell, there has been renewed, grassroots interest in Lisp (CL 
and Scheme) over the last 5 years.  Smalltalk is not the only 
alternative.  Both have ANSI standard specifications.


KAS

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Kurt Stephens]

Reuben Thomas wrote:

On 26 February 2010 23:15, John Zabroski  wrote:

These three physical coupling issues
(block-structured, procedural message passing; manual memory management;
manual concurrency) are things the average programmer should never have to
touch,


I don't remember seeing block struturing ever being described as one
of the "things the average programmer should never have to touch";
could you elaborate on how it's bad, please?

I agree with Reuben here.  Languages that elevate block-structures to 
first-class status: Smalltalk and Self (and even Ruby), lead to less 
coupling and greater expressiveness -- they are the poor-man's lambda. 
Lack of such first-class constructs make languages like Java completely 
unpalatable, even with its anonymous classes.  I hope that modern 
environments allow more specialization of "block-structure" semantics. 
What would replace blocks in Smalltalk?  I would like to subclass and 
decompose them.


KAS


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Andrey Fedorov]

Considering the ambition of the project relative to its resources, I think
it's reasonable for STEPS to keep a low profile and spend less effort on
"educating" than one might like.

That said, I'd appreciate a simple "suggested reading" list for independent
study - in my case, for someone with an undergrad in CS.

*That* said, this section  is wonderful.

Cheers,
Andrey

On Sun, Feb 28, 2010 at 11:50 AM, Reuben Thomas  wrote:

> On Sunday, February 28, 2010, Brian Gilman  wrote:
> > That having been said, I think the project is an interesting one, but I'm
> > not sure it's really ready for tons of publicity yet.
>
> Think of a software project as like Plato's model of the soul as a
> charioteer with two horses, one immortal and one mortal, only without
> the goal of reaching heaven. The mortal horse is the imperatives of
> the real world: developers, money, users, releases and so on, while
> the immortal horse represents elegance, simplicity, performance,
> design perfection. A successful project usually manages to keep the
> two horses in relative harmony, making something good and practical.
> VPRI seems to have started off with just the immortal horse (or, if
> you take the view that the project's members are gods, two immortal
> horses).
>
> In other words, I think you have it the wrong way round: it is
> precisely by caring about one's public that one fixes the rough edges
> so that the code is releasable and usable even when it's not finished
> (and it never is). This is the whole point of "release early, release
> often": stay in touch with the real world.
>
> I think it's scandalous that a publically-funded non-secret project
> does not have far stricter requirements for public engagement than are
> apparent here.
>
> I would add that the reason I care is because I have a great deal of
> respect for Ian Piumarta in particular: I was blown away by his
> Virtual Virtual Machine work when I went to INRIA Rocquencourt in
> 1999, greatly impressed by his code generation work on Smalltalk (at
> least that did get out the door), and really excited when I first came
> across COLA. This stuff should be out there!
>
> --
> http://rrt.sc3d.org
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Reuben Thomas]

On Sunday, February 28, 2010, Brian Gilman  wrote:
> That having been said, I think the project is an interesting one, but I'm
> not sure it's really ready for tons of publicity yet.

Think of a software project as like Plato's model of the soul as a
charioteer with two horses, one immortal and one mortal, only without
the goal of reaching heaven. The mortal horse is the imperatives of
the real world: developers, money, users, releases and so on, while
the immortal horse represents elegance, simplicity, performance,
design perfection. A successful project usually manages to keep the
two horses in relative harmony, making something good and practical.
VPRI seems to have started off with just the immortal horse (or, if
you take the view that the project's members are gods, two immortal
horses).

In other words, I think you have it the wrong way round: it is
precisely by caring about one's public that one fixes the rough edges
so that the code is releasable and usable even when it's not finished
(and it never is). This is the whole point of "release early, release
often": stay in touch with the real world.

I think it's scandalous that a publically-funded non-secret project
does not have far stricter requirements for public engagement than are
apparent here.

I would add that the reason I care is because I have a great deal of
respect for Ian Piumarta in particular: I was blown away by his
Virtual Virtual Machine work when I went to INRIA Rocquencourt in
1999, greatly impressed by his code generation work on Smalltalk (at
least that did get out the door), and really excited when I first came
across COLA. This stuff should be out there!

-- 
http://rrt.sc3d.org

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Reuben Thomas]

On 26 February 2010 23:15, John Zabroski  wrote:
> These three physical coupling issues
> (block-structured, procedural message passing; manual memory management;
> manual concurrency) are things the average programmer should never have to
> touch,

I don't remember seeing block struturing ever being described as one
of the "things the average programmer should never have to touch";
could you elaborate on how it's bad, please?

-- 
http://rrt.sc3d.org

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Brian Gilman]

On Feb 28, 2010, at 10:37 PM, Reuben Thomas wrote:

> On 27 February 2010 08:08, Dan Amelang  wrote:
>> (Regarding your puzzling over Alan's views, though, you might want to
>> try emailing him directly. After you've done due diligence reading up
>> on the subject, of course.)
> 
> Although it would be of far greater value if such an exchange took
> place in public, e.g. on this list.
I agree, the discussion was interesting, it would be a shame if it was 
continued on a back-channel. 

> VPRI seems really bad at actually getting publicity for its work: much
> of the most interesting stuff, like FONC's COLA/idst, isn't even
> widely available in Linux distributions, or even packaged as source
> from an obvious place, which is pretty much the minimum requirement
> for getting the attention of all but the determined and/or really
> interested...
Right now the barrier for anyone interested in the project is absurdly high.  

After hearing about the project, I downloaded the source, and attempted to 
compile on OS X, which wouldn't compile.  I went as far as installing a Ubuntu 
image in VMWare, just for the sake of trying to get fonc to compile.  It 
compiled, but then jolt2 gave a segmentation fault whenever I tried to use it.  
I did some research and noticed that the seg faults were probably related to 
the fact that I have a newer CPU in my machine, but at that point I felt it 
would be best to cut my losses and move on.

That having been said, I think the project is an interesting one, but I'm not 
sure it's really ready for tons of publicity yet.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Reading Maxwell's Equations

[Reuben Thomas]

On 27 February 2010 08:08, Dan Amelang  wrote:
> (Regarding your puzzling over Alan's views, though, you might want to
> try emailing him directly. After you've done due diligence reading up
> on the subject, of course.)

Although it would be of far greater value if such an exchange took
place in public, e.g. on this list.

VPRI seems really bad at actually getting publicity for its work: much
of the most interesting stuff, like FONC's COLA/idst, isn't even
widely available in Linux distributions, or even packaged as source
from an obvious place, which is pretty much the minimum requirement
for getting the attention of all but the determined and/or really
interested. There isn't even a "software" link on the home page of
vpri.org, and the projects directly linked to on the "Our work" page
did not originate at VPRI (Squeak Etoys & Croquet). It takes another
two clicks to get to the FONC wiki, from which the closest thing to
code is a link to the SVN repo. Sigh...

(Observation: although I quickly checked what I wrote above, it may
not be 100% accurate. It doesn't matter: almost no-one I talk to has
heard of any of this stuff.)

-- 
http://rrt.sc3d.org

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc