headers
quiet_lad | 1 Jul 2010 11:14
Picon

plan9 from user space on openbsd 4.7 amd64 fails to build

# cd
plan9/
# ./
INSTALL
+ Mailing list: http://groups.google.com/group/plan9port-dev
+ Issue tracker: http://code.swtch.com/plan9port/issues/
+ Submitting changes: http://swtch.com/go/codereview

* Resetting /usr/local/plan9/config
* Compiler version:
        gcc version 3.3.5 (propolice)
* Building mk...
>>> pwd
>>> pwd
>>> pwd
>>> pwd
* Building everything (be patient)...
>>> cd /usr/local/plan9/src/libdraw; mk all
9c  openfont.c
openfont.c:12: warning: `n' might be used uninitialized in this
function
>>> mk: don't know how to make '/usr/local/plan9/lib/libthread.a(OpenBSD-x86_64-asm.o)' in /usr/local/plan9/src/libthread
mk: for i in ...  : exit status=exit(1)
Permalink | Reply | 2 comments |
headers
Ethan Grammatikidis | 1 Jul 2010 17:06

Re: xml


On 30 Jun 2010, at 9:53 pm, Wes Kussmaul wrote:

>
> If you gathered up a bunch of old, proven data representation  
> methods, packaged it as XML 2.0, formed an XML 2.0 consortium and  
> put it out there energetically with bullet points and with a  
> straight face, people would buy it.
>
> No, listen, it's true, they would. The straight face part is  
> important though.

Oh absolutely! You want to be successful in the computing world, pick  
an idea that's been forgotten and market it. It's been done over and  
over again, often to bad effect, reintroducing ideas which should  
have long been buried. I do wonder if this is what the Go authors are  
trying to do in a different area to xml; reintroduce good practice  
under new terminology.

Perhaps there is a hard part to it: writing the idea up in such a way  
as to not offend the misled sensibilities of the average sheep. Those  
"misled sensibilities" are certainly a very serious problem for Go.

>
> http://fudili.com/
>
> "If God had not meant them to be shorn, He would not have made them  
> sheep."
> - Pancho Villa
>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Russ Cox | 1 Jul 2010 19:12

Re: xml

> I do wonder if this is what the Go authors are trying to do in a
> different area to xml; reintroduce good practice under new terminology.

I'd like to know which good practices Go is merely reintroducing.
The concurrency model, sure, but I believe the approaches to
interfaces and name visibility are new, as is having a garbage
collected language that lets you take the address of fields
in the middle of objects.  If you know of earlier work that already
did these, I'd be interested to hear about it.

Thanks.
Russ
Permalink | Reply | 6 comments |
headers
Bakul Shah | 1 Jul 2010 19:43

Re: xml

On Thu, 01 Jul 2010 10:12:00 PDT Russ Cox <rsc <at> swtch.com>  wrote:
> > I do wonder if this is what the Go authors are trying to do in a
> > different area to xml; reintroduce good practice under new terminology.
> 
> I'd like to know which good practices Go is merely reintroducing.
> The concurrency model, sure, but I believe the approaches to
> interfaces and name visibility are new, as is having a garbage
> collected language that lets you take the address of fields
> in the middle of objects.  If you know of earlier work that already
> did these, I'd be interested to hear about it.

I haven't played with go much but aren't go's interfaces much
like Haskell's type classes? The latter do seem much nicer to me.
    http://www.haskell.org/tutorial/classes.html

Apple's Obj C is now GCed so I think it will allow you to
take address of a field in the middle of an object. You can
use Bohm-Demers-Weiser conservative GC with C too!

Perhaps not the same as in go but in the same neighbourhood, no?!
Permalink | Reply | 5 comments |
headers
Jorden M | 1 Jul 2010 20:37
Picon

Re: xml

On Thu, Jul 1, 2010 at 1:43 PM, Bakul Shah <bakul+plan9 <at> bitblocks.com> wrote:
> On Thu, 01 Jul 2010 10:12:00 PDT Russ Cox <rsc <at> swtch.com>  wrote:
>> > I do wonder if this is what the Go authors are trying to do in a
>> > different area to xml; reintroduce good practice under new terminology.
>>
>> I'd like to know which good practices Go is merely reintroducing.
>> The concurrency model, sure, but I believe the approaches to
>> interfaces and name visibility are new, as is having a garbage
>> collected language that lets you take the address of fields
>> in the middle of objects.  If you know of earlier work that already
>> did these, I'd be interested to hear about it.
>
> I haven't played with go much but aren't go's interfaces much
> like Haskell's type classes? The latter do seem much nicer to me.
>    http://www.haskell.org/tutorial/classes.html

Of the many languages that try to do type parameterization with type
classes as restrictions, they all seem to be very clunky compared to
Haskell.

`Interfaces', the way they are invariably implemented, don't cut it --
too limiting and imposing. `Templates' and `Concepts' together are
close to the Haskell way in spirit, but the execution seemed to suffer
from being bolted onto C++ and fighting with its flavor of OO. Duck
Typing isn't a solution, it's ignoration just asking for trouble.

In any case, getting a type system to be sane and please more than 90%
of the users is hard (insoluble?). Haskell is getting bigger, and you
can see some of the expansion is related to corner-cases in dealing
with the type system (multi-param type classes & fundeps, existential
(Continue reading)

Permalink | Reply | 4 comments |
headers
Rob Pike | 1 Jul 2010 20:49
Picon

Re: xml

> `Interfaces', the way they are invariably implemented, don't cut it --
> too limiting and imposing.

I do not claim that Go's interfaces can match the type system of
Haskell but this sentence tells me you aren't very familiar with them.
 They are not implemented, invariably or otherwise, like any other
things called interfaces that I know.  They also don't work very much
like the same-named things in other languages.

As for limiting? Maybe. Imposing? Not at all. If anything, I'd call
them liberating.

As Russ said, there's more new in Go than many observers seem to
realize.  The language looks much more traditional than it really is.

-rob
Permalink | Reply | 3 comments |
headers
Bakul Shah | 1 Jul 2010 21:33

Re: xml

On Thu, 01 Jul 2010 11:49:31 PDT Rob Pike <robpike <at> gmail.com>  wrote:
> 
> I do not claim that Go's interfaces can match the type system of
> Haskell

Given that all variables have to be explicitly typed (as far
as I can remember), I thought it would be even easier to do
something like Haskell type classes!  So if you see

	a == b

== would map to a function depending on which type clas a &
b's type belongs to. But this is all idle speculation and I 
am sure I am missing something fundamental.

> As Russ said, there's more new in Go than many observers seem to
> realize.  The language looks much more traditional than it really is.

Agreed. Go seems like a very nice language. In a sense
everything has been done before but a good combination of
features can still be quite eye opening and provide a
pleasing, easy to use environment [Though I still prefer
Scheme :-)]
Permalink | Reply | 0 comments |
headers
Jorden M | 1 Jul 2010 21:34
Picon

Re: xml

On Thu, Jul 1, 2010 at 2:49 PM, Rob Pike <robpike <at> gmail.com> wrote:
>> `Interfaces', the way they are invariably implemented, don't cut it --
>> too limiting and imposing.
>
> I do not claim that Go's interfaces can match the type system of
> Haskell but this sentence tells me you aren't very familiar with them.
>  They are not implemented, invariably or otherwise, like any other
> things called interfaces that I know.  They also don't work very much
> like the same-named things in other languages.
>
> As for limiting? Maybe. Imposing? Not at all. If anything, I'd call
> them liberating.
>
> As Russ said, there's more new in Go than many observers seem to
> realize.  The language looks much more traditional than it really is.
>
> -rob
>
>

I wasn't making a particular statement about Go, as I am not that
familiar with it. Syntactically, it's eerily similar to Algol, but
obviously there's more to a language than syntax. We all know how
sweeping generalizations are.

Go's interfaces definitely cut down on coupling compared with, let's
say Java and C++, since they're fun to beat on. I am left to wonder if
the implicitness of Go interfaces causes problems until I explore the
language more. Lack of polymorphism in the interfaces seems to limit
the extent to which they can be compared to Haskell type classes, but
(Continue reading)

Permalink | Reply | 1 comment |
headers
Francisco J Ballesteros | 1 Jul 2010 21:36
Favicon

i.e.

http://lsub.org/who/nemo/iepanels.swf

This is how panels are going to be handled in i.e.
The thing I used to make the screencast generates .swf,
but I think that'll be ok for most people.

Text panels with fonts and inlined images are done but not
yet integrated with the rest, the boxes you see in the video
are just "debug panels" only useful for the obvious purpose.

Also, I don't know why, but the screencast didn't take all the
pixels and there are some pixels shown that did not have that
color on my screen; don't ask me why.

enjoy
Permalink | Reply | 3 comments |
headers
Jacob Todd | 2 Jul 2010 01:13
Picon

Re: i.e.

On Thu, Jul 01, 2010 at 09:36:03PM +0200, Francisco J Ballesteros wrote:
> http://lsub.org/who/nemo/iepanels.swf
> 
> This is how panels are going to be handled in i.e.
> The thing I used to make the screencast generates .swf,
> but I think that'll be ok for most people.
> 
> Text panels with fonts and inlined images are done but not
> yet integrated with the rest, the boxes you see in the video
> are just "debug panels" only useful for the obvious purpose.
> 
> Also, I don't know why, but the screencast didn't take all the
> pixels and there are some pixels shown that did not have that
> color on my screen; don't ask me why.
mplayer doesn't find any video in the file, just audio.
> 
> enjoy
>
Permalink | Reply | 1 comment |

Gmane