Re: [9fans] nix at lsub

Re: [9fans] nix at lsub

[arnold]

> > having to write the same set of GUI interfaces
> > three times (X11, windows, Mac OS).
>
> I'd like to put in a good word for Plan 9, in case it gets forgotten.
> And, yes, Qt does not support Plan 9, I guess we'll need to find some
> compromise, if at all possible.
>
> ++L

Good point. Unfortunately, until Plan 9 grows a C++ compiler, Qt isn't
an option for it.  If/when that does happen, it would be a worthwhile
thing to have there (In My Humble Opinion, of course :-).

Arnold

Re: [9fans] nix at lsub

[hiro]

Is this a joke? Has cocoa been ported to qt now?

Re: [9fans] nix at lsub

[Jeff Sickel]

Qt's been ported to OSX.  It's not really worth it though,
better to go native drawing libraries with Cocoa or OpenGL.

On Apr 18, 2012, at 8:37 PM, hiro wrote:

> Is this a joke? Has cocoa been ported to qt now?

Re: [9fans] nix at lsub

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

OpenGL (within its scope) covers several platforms at once, and anyway has
to be handled somehow.
Early in Inferno's history, I looked at the then version OpenGL but since at
the time it kept drawing state hidden (similar to PostScript), and largely
global, and the
designers hadn't discovered data structures yet, it wasn't clear whether
one could do a pleasant interface to it. To judge from (say) the current
Python interface,
probably not. Still putrid, but there's apparently not a lot you can do.

(OpenVG by contrast seemed much better done, but that's 2D.)

On 19 April 2012 05:15, Jeff Sickel <jas@corpus-callosum.com> wrote:

> better to go native drawing libraries with Cocoa or OpenGL.

[-- Attachment #2: Type: text/html, Size: 1059 bytes --]

Re: [9fans] nix at lsub

[Joseph Stewart]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

I've intended to see if I can glean any wisdom from the Android interface
to OpenGL but have had neither the time nor motivation.

Anyone here know if it's a model to learn from?

-joe

On Thu, Apr 19, 2012 at 5:10 PM, Charles Forsyth
<charles.forsyth@gmail.com>wrote:

> OpenGL (within its scope) covers several platforms at once, and anyway has
> to be handled somehow.
> Early in Inferno's history, I looked at the then version OpenGL but since
> at
> the time it kept drawing state hidden (similar to PostScript), and largely
> global, and the
> designers hadn't discovered data structures yet, it wasn't clear whether
> one could do a pleasant interface to it. To judge from (say) the current
> Python interface,
> probably not. Still putrid, but there's apparently not a lot you can do.
>
> (OpenVG by contrast seemed much better done, but that's 2D.)
>
> On 19 April 2012 05:15, Jeff Sickel <jas@corpus-callosum.com> wrote:
>
>> better to go native drawing libraries with Cocoa or OpenGL.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1822 bytes --]

Re: [9fans] nix at lsub

[Charles Forsyth]

On 19 April 2012 09:16, Joseph Stewart <joseph.stewart@gmail.com> wrote:
>
> Anyone here know if it's a model to learn from?


Another glance, and I'd say it's similar to the others (except for the
onXYZ style of programming).
Because GL is fairly big and complicated, everyone copies the original
interface conventions precisely.
That way you can look it up in the manual. Unfortunately, it means you
get FORTRAN in every language.
(The original target might have been C, but it looks like "FORTRAN in
any language". There are older
graphics interfaces in C that have data structures, so it's not impossible.)
Thus, you get



// Enabled the vertices buffer for writing and to be used during
// rendering.
		gl.glFrontFace(GL10.GL_CCW); // OpenGL docs
		// Enable face culling.
		gl.glEnable(GL10.GL_CULL_FACE); // OpenGL docs
		// What faces to remove with the face culling.
		gl.glCullFace(GL10.GL_BACK); // OpenGL docs

		// Enabled the vertices buffer for writing and to be used during
		// rendering.
		gl.glEnableClientState(GL10.GL_VERTEX_ARRAY);// OpenGL docs.
		// Specifies the location and data format of an array of vertex
		// coordinates to use when rendering.
		gl.glVertexPointer(3, GL10.GL_FLOAT, 0, // OpenGL docs
                                 vertexBuffer);

		gl.glDrawElements(GL10.GL_TRIANGLES, indices.length,// OpenGL docs
				  GL10.GL_UNSIGNED_SHORT, indexBuffer);

		// Disable the vertices buffer.
		gl.glDisableClientState(GL10.GL_VERTEX_ARRAY); // OpenGL docs
		// Disable face culling.
		gl.glDisable(GL10.GL_CULL_FACE); // OpenGL docs

Note the state, and the stylish "gl.gl...". Stutter and suffer!

"But wait!", I hear you cry. State, callbacks, no data structures to
speak of, ... why don't we look
at how they handle this stuff in ... Haskell! (Monads, and a learning
curve, though you can then build
up something that's not entirely graphics machine code.)

Re: [9fans] nix at lsub

[Bakul Shah]

On Apr 19, 2012, at 1:46 AM, Charles Forsyth <charles.forsyth@gmail.com> wrote:
> "But wait!", I hear you cry. State, callbacks, no data structures to
> speak of, ... why don't we look
> at how they handle this stuff in ... Haskell! (Monads, and a learning
> curve, though you can then build
> up something that's not entirely graphics machine code.)

It is a big state machine because you have to give it a lot of state & the 3D h/w does do a lot of complicated things!   SGI had open inventor, a scene graph level C++ API but it didn't really go anywhere it seems.

But I think openGL 3.0+ and openGL ES 2.0 with their programmable pipeline can map well to a fileserver, where you write your data to the openGL server and the GPU does all the heavy lifting. This can also work reasonably well where the 3D h/w is a few tens of microseconds away from your cpu. I have a partial paper design but long way to go. A prototype is needed to see how well this will perform. An openInventor/coin3D/ivy (in scheme) kind of GUI library can be build on top of that.

Re: [9fans] nix at lsub

[Charles Forsyth]

I wasn't too worried about getting a file system interface to it.
I'd supposed that would be tedious (from the size of the language) but
straightforward, similar in principle to draw(2).
Draw's programming interface can, however, present Images, Screens,
Points, Rectangles, Screens, Fonts, and so on as values that can be
created and manipulated like any other.
Obviously there's still an underlying state in the image currently
drawn in an Image, or on a Display.
By contrast, OpenGL has things like this:

"None of the matrix manipulation commands have an explicit parameter
to control which matrix they affect. Instead, OpenGL maintains a
current matrix mode that determines which matrix type the previously
mentioned matrix manipulation commands actually affects" and "each
matrix type has its own a stack of matrices". (That's followed in a
document I'm looking at by all the ways you can get into trouble with
this,
but how much faster it all is!) And, that state is program global.

Still, that's what there is!

Re: [9fans] nix at lsub

[Bakul Shah]

On Thu, 19 Apr 2012 11:32:03 BST Charles Forsyth <charles.forsyth@gmail.com>  wrote:
> I wasn't too worried about getting a file system interface to it.
> I'd supposed that would be tedious (from the size of the language) but
> straightforward, similar in principle to draw(2).

A filesystem interface seems to simplify things quite a bit.

> Draw's programming interface can, however, present Images, Screens,
> Points, Rectangles, Screens, Fonts, and so on as values that can be
> created and manipulated like any other.

This can be built on top of the above. A /dev/draw shim
wouldn't be too hard either. In a sense openGL is at the
machine assembly language level while screens, rectangles,
fonts etc are at a higher language level.

> Obviously there's still an underlying state in the image currently
> drawn in an Image, or on a Display.
> By contrast, OpenGL has things like this:
>
> "None of the matrix manipulation commands have an explicit parameter
> to control which matrix they affect. Instead, OpenGL maintains a
> current matrix mode that determines which matrix type the previously
> mentioned matrix manipulation commands actually affects" and "each
> matrix type has its own a stack of matrices". (That's followed in a
> document I'm looking at by all the ways you can get into trouble with
> this,
> but how much faster it all is!) And, that state is program global.
>
> Still, that's what there is!

Indeed but GL ES 2 is simpler by virtue of leaving out fixed
pipeline functions etc. We may as well make the best use of it
when a $35 computer can provide a high performance openGL
implementation!

Re: [9fans] nix at lsub

[ComeauAt9Fans@gmail.com]

On Apr 18, 2012, at 2:05 PM, arnold@skeeve.com wrote:
>>> having to write the same set of GUI interfaces
>>> three times (X11, windows, Mac OS).
>> 
>> I'd like to put in a good word for Plan 9, in case it gets forgotten.
>> And, yes, Qt does not support Plan 9, I guess we'll need to find some
>> compromise, if at all possible.
>> ++L
> 
> Good point. Unfortunately, until Plan 9 grows a C++ compiler, Qt isn't
> an option for it.  If/when that does happen, it would be a worthwhile
> thing to have there (In My Humble Opinion, of course :-).

We would be glad to work further on such a C++ port with anybody who can handle the Qt end of things so anybody interested in exploring such an endeavor should discuss with us.

- Greg

Re: [9fans] nix at lsub

[Lucio De Re]

> We would be glad to work further on such a C++ port with anybody who
> can handle the Qt end of things so anybody interested in exploring
> such an endeavor should discuss with us.

I have a friend who is totally sold on LLVM, but I note that it is
itself written in C++, so bootstrapping would be difficult (I think I
still have a running version of GCC 3.0, . As for me, I guess I was
waiting for the opportunity to point out that the Go Nuts are
discussing options for a visual interface for Go which is where I
would place my bets.

Still, the point that the infrastructure could be based on an existing
code base is not to be frowned upon.  I suspect that in this
particular instance we're either going to get very strong leadership
producing a robust, but easily criticised outcome, or a weak community
that produces a wishy-washy compromise that pleases no one, but is
just good enough and will become the next bloated standard.

I'm happy to take part in the former project.

++L

Re: [9fans] nix at lsub

[ComeauAt9Fans@gmail.com]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

> On Apr 19, 2012, at 12:11 PM, Lucio De Re <lucio@proxima.alt.za> wrote:
>>> We would be glad to work further on such a C++ port with anybody who
>>> can handle the Qt end of things so anybody interested in exploring
>>> such an endeavor should discuss with us.
>> 
>> I have a friend who is totally sold on LLVM, but I note that it is
>> itself written in C++, so bootstrapping would be difficult (I think I
>> still have a running version of GCC 3.0,
> 
> Speaking with their developers a few years ago they did not think it was a good idea/reasonably feasible. 
> 
> I may be biased, but still sure some general flavor of Comeau for Plan 9 could be a near term and not expensive endeavor (though it depends upon ones definition of inexpensive too I guess).  And Qt definitely has its place in the world. 
> 
> - Greg

[-- Attachment #2: Type: text/html, Size: 2456 bytes --]

Re: [9fans] nix at lsub

[Lucio De Re]

> I may be biased, but still sure some general flavor of Comeau for
> Plan 9 could be a near term and not expensive endeavor (though it
> depends upon ones definition of inexpensive too I guess).  And Qt
> definitely has its place in the world.

I've bought the Go faith lock, stock and barrel, to mix a couple of
metaphors.  And I like Go specifically because its core belief is that
it is high time conventions were tossed out the window.  I am actually
quite frustrated because I feel that evolution in the IT field is
taking a path of least resistance (I have occasionally pressed Russ
Cox to relent on the policy of minimal change in the Go toolchain, I
seldom, if ever, won on principle) and wish "I had words like a
hammer" to promote a much more aggressive approach to do what is right
rather than what is expedient.

I'd like to mention, for example, the idea expressed here that a $35
device will give you 3D capabilities.  Sure, but the same $35 could
give you considerably more and accepting what's on offer is, in my
opinion, wimping out.  Maybe I can immodestly (and probably
untruthfully) say that _I_ could do better than that and that so could
many others in this forum and we are all compelled to sacrifice our
possible contributions to a better world by those in the industry that
know how to manipulate our gratification sensors.

I could list many examples (and so no doubt could each one of us here)
of benefits whose real cost is much higher than the amount of dollars
being spent on them.  In some respects I am fortunate: I live in an
old Apartheid-built small town in South Africa and the digital divide
is so obvious here, yet there is no real cause for it.  But I don't
have the skill to express how infuriating it all is...

What I'm looking for is to replace obsolescence with efficiency: 3000
pupils in my immediate vicinity could enjoy much better access to the
Internet (_any_ access to the Internet) if I could deploy KA9Q over
MSDOS as the primary software on 8088 based computers.  I know this
because back in 1992 I had precisely that hardware serving single
dial-up connections from a small community of BBSers.  These children
don't need pr0n or video clips, Facebook or twitter, they need text
access, e-mail, the much maligned and damaged e-news, just as I found
them useful back in the very early 1990s.  But we are stealing that
from them by moving the entry bar ever higher so that our obsolete
computers and our mobile phones with dead batteries and incompatible
SIM cards, VGA monitors, memory simms and all manners of perfectly
useful IT equipment cannot conceivably be deployed to improve their
standard of living and their ability to catch up.

What I'm looking for is the community that is savvy enough to embrace
new technology and caring enough to propagate their gains to those who
do not have the same access to that technology instead of making sure
of the opposite.  I don't believe that there is a conflict, in fact, I
think that's the only option open to us, I'm just waving its flag a
little ahead of the tsunami.  And that tsunami includes Go, Plan 9,
possibly Android, vx32 and Raspberry Pie.  I pray that I'm not just a
crazy visionary.

Anyway, sorry to rant like this, I don't even know if it made me feel
any better to do it, I do hope that some of you will see things from
my perspective and perhaps my feelings will resonate with your own.

Lucio.

Re: [9fans] nix at lsub

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 4192 bytes --]

On Thu, Apr 19, 2012 at 1:56 PM, Lucio De Re <lucio@proxima.alt.za> wrote:

> > I may be biased, but still sure some general flavor of Comeau for
> > Plan 9 could be a near term and not expensive endeavor (though it
> > depends upon ones definition of inexpensive too I guess).  And Qt
> > definitely has its place in the world.
>
> I've bought the Go faith lock, stock and barrel, to mix a couple of
> metaphors.  And I like Go specifically because its core belief is that
> it is high time conventions were tossed out the window.  I am actually
> quite frustrated because I feel that evolution in the IT field is
> taking a path of least resistance (I have occasionally pressed Russ
> Cox to relent on the policy of minimal change in the Go toolchain, I
> seldom, if ever, won on principle) and wish "I had words like a
> hammer" to promote a much more aggressive approach to do what is right
> rather than what is expedient.
>

IMO, there is nothing generally wrong with taking the path of least
resistence, so long as open is open minded and also so long as it is not
the only path being considered.


> I'd like to mention, for example, the idea expressed here that a $35
> device will give you 3D capabilities.  Sure, but the same $35 could
> give you considerably more and accepting what's on offer is, in my
> opinion, wimping out.  Maybe I can immodestly (and probably
> untruthfully) say that _I_ could do better than that and that so could
> many others in this forum and we are all compelled to sacrifice our
> possible contributions to a better world by those in the industry that
> know how to manipulate our gratification sensors.
>
> I could list many examples (and so no doubt could each one of us here)
> of benefits whose real cost is much higher than the amount of dollars
> being spent on them.  In some respects I am fortunate: I live in an
> old Apartheid-built small town in South Africa and the digital divide
> is so obvious here, yet there is no real cause for it.  But I don't
> have the skill to express how infuriating it all is...
>
> What I'm looking for is to replace obsolescence with efficiency: 3000
> pupils in my immediate vicinity could enjoy much better access to the
> Internet (_any_ access to the Internet) if I could deploy KA9Q over
> MSDOS as the primary software on 8088 based computers.  I know this
> because back in 1992 I had precisely that hardware serving single
> dial-up connections from a small community of BBSers.  These children
> don't need pr0n or video clips, Facebook or twitter, they need text
> access, e-mail, the much maligned and damaged e-news, just as I found
> them useful back in the very early 1990s.  But we are stealing that
> from them by moving the entry bar ever higher so that our obsolete
> computers and our mobile phones with dead batteries and incompatible
> SIM cards, VGA monitors, memory simms and all manners of perfectly
> useful IT equipment cannot conceivably be deployed to improve their
> standard of living and their ability to catch up.
>
Understood.


> What I'm looking for is the community that is savvy enough to embrace
> new technology and caring enough to propagate their gains to those who
> do not have the same access to that technology instead of making sure
> of the opposite.  I don't believe that there is a conflict, in fact, I
> think that's the only option open to us, I'm just waving its flag a
> little ahead of the tsunami.  And that tsunami includes Go, Plan 9,
> possibly Android, vx32 and Raspberry Pie.  I pray that I'm not just a
> crazy visionary.
>
Why not pray that you *are* a crazy visionary? :)


> Anyway, sorry to rant like this, I don't even know if it made me feel
> any better to do it, I do hope that some of you will see things from
> my perspective and perhaps my feelings will resonate with your own.
>
> Lucio.
>
>
>


--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 5184 bytes --]

Re: [9fans] nix at lsub

[Lucio De Re]

> IMO, there is nothing generally wrong with taking the path of least
> resistence, so long as open is open minded and also so long as it is not
> the only path being considered.

Except that by definition the path of least resistance is the only one
of its type.  You buy the reason, you paint yourself in the corner.  I
do grant that one may choose the path of least resistance for reasons
other than the ostensible one, but I doubt that would be anything more
than an accident.  Can you see where my reasonaing takes me?

++L

Re: [9fans] nix at lsub

[Lucio De Re]

> Why not pray that you *are* a crazy visionary? :)

Too many years of logic, I'm a very rational materialist.  But thank
you for the suggestion, it gave me reason to smile. I do get plenty,
in their lack of technical sophistication , my "previously
disadvantaged" neighbours have a great deal of warmth and friendship
to share.  All the more reason for me to wish to help them.

++L

Re: [9fans] nix at lsub

[arnold]

> Is it exported as files?
>
> I thought I knew Qt, but, if it provides a file interface, I missed that.

No - but I would suggest building on Qt, to let it handle all the interface
to the native graphics, and you provide the file service / translation
over it.

I think that would be challenging and interesting, and also save you an
*enormous* amount of work in having to write the same set of GUI interfaces
three times (X11, windows, Mac OS).

In other words, the GUI part is already a laregly solved problem; build
upon it instead of reinventing it.

Just an idea. :-)

Arnold

Re: [9fans] nix at lsub

[Nemo]

ah, if you said just to leverage a
native kit, yes, that was the plan I had.
but abstracting it.

--
iphone kbd. excuse typos :)


On Apr 18, 2012, at 6:09 PM, arnold@skeeve.com wrote:

>> Is it exported as files?
>>
>> I thought I knew Qt, but, if it provides a file interface, I missed that.
>
> No - but I would suggest building on Qt, to let it handle all the interface
> to the native graphics, and you provide the file service / translation
> over it.
>
> I think that would be challenging and interesting, and also save you an
> *enormous* amount of work in having to write the same set of GUI interfaces
> three times (X11, windows, Mac OS).
>
> In other words, the GUI part is already a laregly solved problem; build
> upon it instead of reinventing it.
>
> Just an idea. :-)
>
> Arnold

Re: [9fans] nix at lsub

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

i thought the easiest way to begin and be cross-platform would be to talk
to a component running in a browser,
similar in principle to a viewer in Octopus.
a browser client will be needed anyway, and there is a browser on many
things (often only a browser); thus
your first step won't be your last, but it would cover a big distance.
it might also make it quicker to experiment.

[-- Attachment #2: Type: text/html, Size: 445 bytes --]

Re: [9fans] nix at lsub

[Francisco J Ballesteros]

If you consider a set of abstract widgets, reasonable enough, you could map them
to native implementations in

-a browser
-cocoa
-gnome
-add your one here.

then, there could be a portable shared component speaking to those and gatewaying
to your favorite protocol (9p, ix), and you could have a clean interface and
reasonable bindings for it.

cocoa was going to be my first move here, btw.
didn't even start, though.

--
using ipad keyboard. excuse any typos.


On Apr 18, 2012, at 6:28 PM, Charles Forsyth <charles.forsyth@gmail.com> wrote:

> i thought the easiest way to begin and be cross-platform would be to talk to a component running in a browser,
> similar in principle to a viewer in Octopus.
> a browser client will be needed anyway, and there is a browser on many things (often only a browser); thus
> your first step won't be your last, but it would cover a big distance.
> it might also make it quicker to experiment.
> 

Re: [9fans] nix at lsub

[Lucio De Re]

> having to write the same set of GUI interfaces
> three times (X11, windows, Mac OS).

I'd like to put in a good word for Plan 9, in case it gets forgotten.
And, yes, Qt does not support Plan 9, I guess we'll need to find some
compromise, if at all possible.

++L

Re: [9fans] nix at lsub

[arnold]

Hi.

> To make it explicit, the plan I have is to
> throw away o/live and o/mero and write something native for
> macos, linux, and perhaps ios such that the UI widgets are abstract
> and handled in a similar way they are handled in o/live.
>
> Only that they'd be native widgets with the look of the native system
> (that's not to say you can't implement an editable text-pannel with
> the mouse language we all love).

Qt already provides this (and much more). It means working in C++ (which is
either a bug or a feature, depending upon how you look at it).

I have used Qt and find it well designed and pleasant to use, but many
9fans might find such a thougt to be heretical.

> Also, as Forsyth points out, the set of widgets has to be rethought, e.g.,
> there should be a web widget.

I think Qt even has that.

> Then it's a matter of using those files from inferno, and remote systems.
>
> But, as I said, I don't have a single line of code yet for all of this.

It sounds like interesting work!  Good luck!

Arnold

Re: [9fans] nix at lsub

[Francisco J Ballesteros]

Is it exported as files?

I thought I knew Qt, but, if it provides a file interface, I missed that.

On Apr 18, 2012, at 5:45 PM, arnold@skeeve.com wrote:

> Hi.
>
>> To make it explicit, the plan I have is to
>> throw away o/live and o/mero and write something native for
>> macos, linux, and perhaps ios such that the UI widgets are abstract
>> and handled in a similar way they are handled in o/live.
>>
>> Only that they'd be native widgets with the look of the native system
>> (that's not to say you can't implement an editable text-pannel with
>> the mouse language we all love).
>
> Qt already provides this (and much more). It means working in C++ (which is
> either a bug or a feature, depending upon how you look at it).
>
> I have used Qt and find it well designed and pleasant to use, but many
> 9fans might find such a thougt to be heretical.
>
>> Also, as Forsyth points out, the set of widgets has to be rethought, e.g.,
>> there should be a web widget.
>
> I think Qt even has that.
>
>> Then it's a matter of using those files from inferno, and remote systems.
>>
>> But, as I said, I don't have a single line of code yet for all of this.
>
> It sounds like interesting work!  Good luck!
>
> Arnold

[9fans] nix at lsub

[Nemo]

Hi,

just FYI,

http://lsub.org/ls/nix.html

has links and pointers for anyone to get the
distribution and updates and/or send changes.

hth

Re: [9fans] nix at lsub

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 232 bytes --]

Awesome!

On Saturday, April 14, 2012, Nemo wrote:

> Hi,
>
> just FYI,
>
> http://lsub.org/ls/nix.html
>
> has links and pointers for anyone to get the
> distribution and updates and/or send changes.
>
> hth
>
>
>

[-- Attachment #2: Type: text/html, Size: 452 bytes --]

Re: [9fans] nix at lsub

[Francisco J Ballesteros]

Just to say that we moved the development mailing list.
Sorry about that.

it's nix at lsub.org
and you can subscribe by a mail to nix-request at lsub.org,
should you want to do so.

Sorry again.

On Apr 14, 2012, at 11:02 PM, Nemo wrote:

> Hi,
>
> just FYI,
>
> http://lsub.org/ls/nix.html
>
> has links and pointers for anyone to get the
> distribution and updates and/or send changes.
>
> hth
>
>

Re: [9fans] nix at lsub

[Noah Evans]

To clarify, Nix development will be continuing at both
nix-dev@googlegroups.com and http://code.google.com/p/nix-os as well.
The project has forked.

Noah


On Mon, Apr 16, 2012 at 12:47 PM, Francisco J Ballesteros <nemo@lsub.org> wrote:
> Just to say that we moved the development mailing list.
> Sorry about that.
>
> it's nix at lsub.org
> and you can subscribe by a mail to nix-request at lsub.org,
> should you want to do so.
>
> Sorry again.
>
> On Apr 14, 2012, at 11:02 PM, Nemo wrote:
>
>> Hi,
>>
>> just FYI,
>>
>> http://lsub.org/ls/nix.html
>>
>> has links and pointers for anyone to get the
>> distribution and updates and/or send changes.
>>
>> hth
>>
>>
>
>

Re: [9fans] nix at lsub

[Aram Hăvărneanu]

Noah Evans wrote:
> To clarify, Nix development will be continuing at both
> nix-dev@googlegroups.com and http://code.google.com/p/nix-os as well.
> The project has forked.

I don't understand what is going on. I though some people were very
unsatisfied with the rietveld code review tool offered by Google Code,
and Nemo created some new tools to be used instead of rietveld and
mercurial. Of course Nemo's tools don't work with Google Code hosting
so the project is moved at lsub, and by design the old mailing list,
nix-dev@googlegroups.com, is tied with the Google Code project, so a
new mailing list has to be used instead.

So what's this fork I'm hearing about? Someone wants to maintain the
mercurial repository independent of the work done at lsub? Who? Why?

If this is not the case, and I hope it isn't, destroy the Google Code
project. Delete it, there's no point for this confusion. Personally I
would have preferred that the mercurial repository would have remained
the place where nix development would happen. I believe the problems
people felt with rietveld could be solved by running a private
instance of rietveld, instead of the generic one at Google, but
whatever, I have no say in this. Just keep it in one place if there's
no schism happening.

So what's happening? John's message on nix-dev@ adds more to this confusion...

-- 
Aram Hăvărneanu

Re: [9fans] nix at lsub

[Noah Evans]

There's a bit of drama going on right now. Here's what I wrote in a
private mail to Steve Simon:

I don't think anybody really liked hg from a technical standpoint.

There were two reasons behind choosing it:

1. It would be trivial to get a 9vx nix distro up and running on Macs
and Linux machines.

2. Codereview would ensure a transparent and open development process.

Patch can be used for 1 to some extent (via the tarball) but it fails
for 2. It makes some members of the community "more equal" than
others.

I think those of us sticking with hg are doing so more for social
reasons than technical ones.

Noah



On Mon, Apr 16, 2012 at 7:23 PM, Aram Hăvărneanu <aram.h@mgk.ro> wrote:
> Noah Evans wrote:
>> To clarify, Nix development will be continuing at both
>> nix-dev@googlegroups.com and http://code.google.com/p/nix-os as well.
>> The project has forked.
>
> I don't understand what is going on. I though some people were very
> unsatisfied with the rietveld code review tool offered by Google Code,
> and Nemo created some new tools to be used instead of rietveld and
> mercurial. Of course Nemo's tools don't work with Google Code hosting
> so the project is moved at lsub, and by design the old mailing list,
> nix-dev@googlegroups.com, is tied with the Google Code project, so a
> new mailing list has to be used instead.
>
> So what's this fork I'm hearing about? Someone wants to maintain the
> mercurial repository independent of the work done at lsub? Who? Why?
>
> If this is not the case, and I hope it isn't, destroy the Google Code
> project. Delete it, there's no point for this confusion. Personally I
> would have preferred that the mercurial repository would have remained
> the place where nix development would happen. I believe the problems
> people felt with rietveld could be solved by running a private
> instance of rietveld, instead of the generic one at Google, but
> whatever, I have no say in this. Just keep it in one place if there's
> no schism happening.
>
> So what's happening? John's message on nix-dev@ adds more to this confusion...
>
> --
> Aram Hăvărneanu
>

Re: [9fans] nix at lsub

[Noah Evans]

I'd like to correct one more misunderstanding and expand a bit more.
Nix is not just work done at lsub (although I'll be the first to admit
that most of the recent work has been done at lsub), it was a
collaboration between Bell Labs, Sandia and lsub (of which my
technical contributions have been very small).

One of the goals in using google code and codereview is to establish a
place to collaborate independent of all parties, the codereview
process was established that all parties were represented and there
was a clear and transparent process where *anyone* who wanted to
contribute could and feel that their contributions were being
considered for technical rather than political reasons.

Noah



On Mon, Apr 16, 2012 at 7:32 PM, Noah Evans <noah.evans@gmail.com> wrote:
> There's a bit of drama going on right now. Here's what I wrote in a
> private mail to Steve Simon:
>
> I don't think anybody really liked hg from a technical standpoint.
>
> There were two reasons behind choosing it:
>
> 1. It would be trivial to get a 9vx nix distro up and running on Macs
> and Linux machines.
>
> 2. Codereview would ensure a transparent and open development process.
>
> Patch can be used for 1 to some extent (via the tarball) but it fails
> for 2. It makes some members of the community "more equal" than
> others.
>
> I think those of us sticking with hg are doing so more for social
> reasons than technical ones.
>
> Noah
>
>
>
> On Mon, Apr 16, 2012 at 7:23 PM, Aram Hăvărneanu <aram.h@mgk.ro> wrote:
>> Noah Evans wrote:
>>> To clarify, Nix development will be continuing at both
>>> nix-dev@googlegroups.com and http://code.google.com/p/nix-os as well.
>>> The project has forked.
>>
>> I don't understand what is going on. I though some people were very
>> unsatisfied with the rietveld code review tool offered by Google Code,
>> and Nemo created some new tools to be used instead of rietveld and
>> mercurial. Of course Nemo's tools don't work with Google Code hosting
>> so the project is moved at lsub, and by design the old mailing list,
>> nix-dev@googlegroups.com, is tied with the Google Code project, so a
>> new mailing list has to be used instead.
>>
>> So what's this fork I'm hearing about? Someone wants to maintain the
>> mercurial repository independent of the work done at lsub? Who? Why?
>>
>> If this is not the case, and I hope it isn't, destroy the Google Code
>> project. Delete it, there's no point for this confusion. Personally I
>> would have preferred that the mercurial repository would have remained
>> the place where nix development would happen. I believe the problems
>> people felt with rietveld could be solved by running a private
>> instance of rietveld, instead of the generic one at Google, but
>> whatever, I have no say in this. Just keep it in one place if there's
>> no schism happening.
>>
>> So what's happening? John's message on nix-dev@ adds more to this confusion...
>>
>> --
>> Aram Hăvărneanu
>>

Re: [9fans] nix at lsub

[ron minnich]

On Mon, Apr 16, 2012 at 10:32 AM, Noah Evans <noah.evans@gmail.com> wrote:

> I think those of us sticking with hg are doing so more for social
> reasons than technical ones.

There are technical reasons as well. But, let it suffice to say that
the tree is forked, and let it go at that.

ron

Re: [9fans] nix at lsub

[Andrés Domínguez]

2012/4/16 Noah Evans <noah.evans@gmail.com>:
> There's a bit of drama going on right now. Here's what I wrote in a
> private mail to Steve Simon:
>
> I don't think anybody really liked hg from a technical standpoint.
>
> There were two reasons behind choosing it:

I thoght the disagreement was because a stupid thing like coding style,
glad to know it's something important like code management.

You cannot be serious!

Andrés

Re: [9fans] nix at lsub

[sl]

> So what's this fork I'm hearing about?

http://9front.org/img/nofork.png

-sl

Re: [9fans] nix at lsub

[Christoph Lohmann]

Greetings.

On Mon, 16 Apr 2012 15:22:27 +0200 Francisco J Ballesteros <nemo@lsub.org> wrote:
> Just to say that we moved the development mailing list.
> Sorry about that.
> 
> it's nix at lsub.org
> and you can subscribe by a mail to nix-request at lsub.org,
> should you want to do so.
> 
> Sorry again.

Why is the nix homepage[0] looking strange today?


Sincerely,

Christoph Lohmann

[0] http://i.imgur.com/BFuZb.png

Re: [9fans] nix at lsub

[Lucio De Re]

>
> [0] http://i.imgur.com/BFuZb.png

I hope people's sense of humour is still holding.  _I_ do think it's
funny, but I would not be surprised if some sensitivities were hurt.

++L

Re: [9fans] nix at lsub

[kokamoto]

> http://lsub.org/ls/nix.html

yeah, now I can browse individual files now,
When I tried two days ago, onlt directories can be browsed.

Yes, I downloaded nix.tgz, and running it on my Ubuntu 11.10.
I'm also running 9front here, of course, Plan 9 itself which I'm now
writing this mail.

I retired the univ this March, and have time now.   I'm looking
into codes of Plan 9 for my fun.  I'm looking many to find out
which is most interesting to make me most fun.

Then, I have a question to all working for OS developement.
Developping device drivers, such as 3D mode of nvidia card etc.,
is very difficult now, because there is no documents abailable.
However, if we try to develope OS, we have to meet this difficulty.
How you are trying to solve this?

Kenji

Re: [9fans] nix at lsub

[andy zerger]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

I think a good start would be to establish port-projects for nearly
anything from freedesktop.org, esp nouveau, in your case.

Then, I have a question to all working for OS developement.
> Developping device drivers, such as 3D mode of nvidia card etc.,
> is very difficult now, because there is no documents abailable.
> However, if we try to develope OS, we have to meet this difficulty.
> How you are trying to solve this?
>

[-- Attachment #2: Type: text/html, Size: 638 bytes --]

Re: [9fans] nix at lsub

[andy zerger]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

I mean, a distributed file system on an actually distributed infrastructure
providing a ray-tracing environment across multiple cpu  to a 9fs /dev/draw
has to have some potential use somewhere..

On Mon, Apr 16, 2012 at 11:53 PM, andy zerger <zerger.andy@gmail.com> wrote:

> I think a good start would be to establish port-projects for nearly
> anything from freedesktop.org, esp nouveau, in your case.
>
>
> Then, I have a question to all working for OS developement.
>> Developping device drivers, such as 3D mode of nvidia card etc.,
>> is very difficult now, because there is no documents abailable.
>> However, if we try to develope OS, we have to meet this difficulty.
>> How you are trying to solve this?
>>
>

[-- Attachment #2: Type: text/html, Size: 1215 bytes --]

Re: [9fans] nix at lsub

[Nemo]

I have in the todo yet another
ui system to run on top
of other systems. for terminals.


--
iphone kbd. excuse typos :)


On Apr 17, 2012, at 4:16 AM, kokamoto@hera.eonet.ne.jp wrote:

>> http://lsub.org/ls/nix.html
>
> yeah, now I can browse individual files now,
> When I tried two days ago, onlt directories can be browsed.
>
> Yes, I downloaded nix.tgz, and running it on my Ubuntu 11.10.
> I'm also running 9front here, of course, Plan 9 itself which I'm now
> writing this mail.
>
> I retired the univ this March, and have time now.   I'm looking
> into codes of Plan 9 for my fun.  I'm looking many to find out
> which is most interesting to make me most fun.
>
> Then, I have a question to all working for OS developement.
> Developping device drivers, such as 3D mode of nvidia card etc.,
> is very difficult now, because there is no documents abailable.
> However, if we try to develope OS, we have to meet this difficulty.
> How you are trying to solve this?
>
> Kenji
>

Re: [9fans] nix at lsub

[kokamoto]

> I have in the todo yet another
> ui system to run on top
> of other systems. for terminals.

We have now:
(1) plan9port which is very clear where only
plan9 like user interface would be developed.
(2) inferno approach where proprietary language
	is neccessary, and resists top of another OS.
(3) plan9 or nix or 9front, traditional style of OS
developement

In basic, I like the (3) approarch, but undocumented
device problem.  (1) is clear, however I feel something
unfilled in my heart...

Your intension is to develope two ways, one for
server (nix), and one for terminal (like drawterm?)

Kenji

Re: [9fans] nix at lsub

[Francisco J Ballesteros]

On Apr 17, 2012, at 10:41 AM, kokamoto@hera.eonet.ne.jp wrote:
> 
> Your intension is to develope two ways, one for
> server (nix), and one for terminal (like drawterm?)
> 

Just to let you use your server(s) but assume that
your terminals might be running macos, linux, ios, ...
as their native systems. You could say it´s a drawterm
revisited, but I won´t be just that :)

Of course that´s just one way, and it does not strictly have
to do with nix because nix is mostly a kernel for manycore systems.

Re: [9fans] nix at lsub

[Tristan]

> (3) plan9 or nix or 9front, traditional style of OS developement

> In basic, I like the (3) approarch, but undocumented device problem.

why not start with documented devices?

looks like there is at least some docs for the omap's opengl.

tristan

-- 
All original matter is hereby placed immediately under the public domain.

Re: [9fans] nix at lsub

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 103 bytes --]

I was thinking along the lines of http://lsub.org/ls/octopus.html, myself,
using a child of Inferno.

[-- Attachment #2: Type: text/html, Size: 174 bytes --]

Re: [9fans] nix at lsub

[Nemo]

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

Funny, the "plan" I mentioned about the new window system
was also to provide inferno to some modern UI, retaining a simple
programmatic interface.

Since I don't have even a single line of code for this, I didn't say.
But I'm glad to see you did :)

On Apr 17, 2012, at 8:56 PM, Charles Forsyth wrote:

> I was thinking along the lines of http://lsub.org/ls/octopus.html, myself,
> using a child of Inferno.
>


[-- Attachment #2: Type: text/html, Size: 790 bytes --]

Re: [9fans] nix at lsub

[kokamoto]

> I was thinking along the lines of http://lsub.org/ls/octopus.html, myself,
> using a child of Inferno.

Yeah, sound like interesting.
Can I try this octopus on some of the PC still now?
because I didn't do it, and have no idea of this.

Whe I tried inferno, I god bad feeling of its gui (sorry all).

Kenji

Re: [9fans] nix at lsub

[John Floren]

On Tue, Apr 17, 2012 at 5:26 PM,  <kokamoto@hera.eonet.ne.jp> wrote:
>> I was thinking along the lines of http://lsub.org/ls/octopus.html, myself,
>> using a child of Inferno.
>
> Yeah, sound like interesting.
> Can I try this octopus on some of the PC still now?
> because I didn't do it, and have no idea of this.
>
> Whe I tried inferno, I god bad feeling of its gui (sorry all).
>
> Kenji
>
>

I've run Octopus a little bit. It's got an interesting UI (Omero) and
some of the features are pretty cool--I ended up being able to cite
the Octopus paper in my master's thesis :) I had some trouble with
running it at first (O/mero wouldn't start properly, unfortunately I
can't recall the error, I think it's in the 9fans archive), but the
setup scripts make it pretty simple to configure.

John

Re: [9fans] nix at lsub

[John Floren]

On Tue, Apr 17, 2012 at 9:07 PM, John Floren <john@jfloren.net> wrote:
> On Tue, Apr 17, 2012 at 5:26 PM,  <kokamoto@hera.eonet.ne.jp> wrote:
>>> I was thinking along the lines of http://lsub.org/ls/octopus.html, myself,
>>> using a child of Inferno.
>>
>> Yeah, sound like interesting.
>> Can I try this octopus on some of the PC still now?
>> because I didn't do it, and have no idea of this.
>>
>> Whe I tried inferno, I god bad feeling of its gui (sorry all).
>>
>> Kenji
>>
>>
>
> I've run Octopus a little bit. It's got an interesting UI (Omero) and
> some of the features are pretty cool--I ended up being able to cite
> the Octopus paper in my master's thesis :) I had some trouble with
> running it at first (O/mero wouldn't start properly, unfortunately I
> can't recall the error, I think it's in the 9fans archive), but the
> setup scripts make it pretty simple to configure.
>
> John

I guess the thing I was aiming for but forgot to type was, "Yes, you
can still try out Octopus, I set it up under Linux for fun about a
month ago and it worked just fine"

Re: [9fans] nix at lsub

[Francisco J Ballesteros]

Sure. I'm using it (and nix/plan9) to develop nix.
Drop me a line off-list if you want help, but you should have
everything you need in the web site, including the distribution of the system.


On Apr 18, 2012, at 2:26 AM, kokamoto@hera.eonet.ne.jp wrote:

>> I was thinking along the lines of http://lsub.org/ls/octopus.html, myself,
>> using a child of Inferno.
> 
> Yeah, sound like interesting.
> Can I try this octopus on some of the PC still now?
> because I didn't do it, and have no idea of this.
> 
> Whe I tried inferno, I god bad feeling of its gui (sorry all).
> 
> Kenji
> 

Re: [9fans] nix at lsub

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

I should add that "along the lines" of Octopus meant that,
as often happens, many of the details might change to account
for experience and second thoughts, and for changed technology.
Obvious candidates for the latter would be the increased availability of 3D,
and vastly greater browser capabilities (for good or ill).

[-- Attachment #2: Type: text/html, Size: 389 bytes --]

Re: [9fans] nix at lsub

[Francisco J Ballesteros]

To make it explicit, the plan I have is to
throw away o/live and o/mero and write something native for
macos, linux, and perhaps ios such that the UI widgets are abstract
and handled in a similar way they are handled in o/live.

Only that they'd be native widgets with the look of the native system
(that's not to say you can't implement an editable text-pannel with
the mouse language we all love).

Also, as Forsyth points out, the set of widgets has to be rethought, e.g.,
there should be a web widget.

Then it's a matter of using those files from inferno, and remote systems.

But, as I said, I don't have a single line of code yet for all of this.

On Apr 18, 2012, at 2:27 PM, Charles Forsyth wrote:

> I should add that "along the lines" of Octopus meant that,
> as often happens, many of the details might change to account
> for experience and second thoughts, and for changed technology.
> Obvious candidates for the latter would be the increased availability of 3D,
> and vastly greater browser capabilities (for good or ill).
>