Re: [9fans] Go Plan 9
the point is that if the linuxemu is provisioned properly (gmake, gcc, bash) to build the Plan 9 $GOBIN from source, then there wont be a need for a linux build box, or porting and maintaining gmake, gcc, bash, etc. one could also build Plan 9 binaries under linuxemu. options as i see them are: 1. a linux build environment for Go which is also a partial dev environment (i.e. where 8g and 8l will run) 2. port (and maintain) all gnu tools needed to build Go from sources under Plan 9 3. a linuxemu build environment that is complete enough to compile Go and serve as Go compilation environment -Skip On Sun, Apr 3, 2011 at 10:46 AM, erik quanstrom quans...@quanstro.net wrote: On Sun Apr 3 12:27:29 EDT 2011, skip.tavakkol...@gmail.com wrote: Why can't we use linuxemu to run the build? sure we could, but then you have to maintain linuxemu, and go. that seems silly. - erik
[9fans] video cards for 1920x1080
From: Tharaneedharan Vilwanathan vdharani@gma... Subject: suggestion for a video card Date: Tue, 18 Aug 2009 11:53:58 -0700 hi, i am looking for a video card for plan9. here are my requirements: - should do 1920x1080 at 60Hz so i can connect to my LCD TV via HDMI - HDMI connector preferable but if the card does 1920x1080, i can use DVI to HDMI adapter - would be nice if it can also do 1920x1200 has anyone played with such a card? is it orderable? any suggestions? any help appreciated. regards dharani This post didn't garner a response. A couple of years later, I have the same question. Is anyone running Plan 9 native at 1920x1080 with an LCD monitor? What video card are you using? What tweaks were necessary to get it to work? The Nvidia card I use with OpenBSD crashes Plan 9 when I attempt xga above 640x480x8. With cinap's realemu I'm able to run at 800x600x32, but the card's VESA bios doesn't report any available modes above 800x600. Some other cards I had sitting around yielded higher resolutions under realemu (VMware even reports 1920x1080 as a valid mode under VESA), but I haven't yet hit upon the right combination to drive my LCD monitor at 1920x1080. -sl
Re: [9fans] video cards for 1920x1080
This post didn't garner a response. A couple of years later, I have the same question. Is anyone running Plan 9 native at 1920x1080 with an LCD monitor? What video card are you using? What tweaks were necessary to get it to work? coraid has a terminal doing this using the on-board video in vesa 16-bit mode; 32-bit vesa has been trouble for me, but that may have been fixed by the realmode stuff. - erik
Re: [9fans] advice and advice
ha ha. i accidentally got some stuff from the attached site (for some reason it's physically impossible to copy and paste the name). the manual is available in japanese only. noah! the best i have here is boyd's dictionary of japanese slang. not many occurences of she has a nice ass in the manual. a serious question. i plan to have fossil in the data collection jeep and am wondering if anyone has experience with a remote venti. well it won't be very remote, it'll be in the support support truck and what i'd like to do is connect via cat5 everynight and do a snap -a, then clean up the fossil for the next day. i think this will work - i'll set up a test rig when i get time but some tips would be handy. i won't go into the pain i had at witch bank today. i was only there an hour. they got toey when i called lloydy to bring me a burger and my dog and sat on the floor with both and my dumbass nintendo game. brucee attachment: hdr_logo.gif
Re: [9fans] advice and advice
On Wed, 6 Apr 2011 23:23:38 +1000, Bruce Ellis wrote: i won't go into the pain i had at witch bank today. i was only there an hour. they got toey when i called lloydy to bring me a burger and my dog and sat on the floor with both and my dumbass nintendo game. I love you man ;-) EBo --
Re: [9fans] Making read(1) an rc(1) builtin?
Yaroslav yari...@gmail.com writes: than appropriate for a line-oriented language like rc(1). As it stands, rc(1) can have it's cake, but it can't eat it without a fork(2). As it was stated earlier, a fork(2) is rather cheap here, so what's your concern then? Maybe it's time to forget the lectures about expensive forks and just cary on? That was supposed to be a joke. Apparently, no body got (or read) it. :( I bet you won't even notice much changes in your stats -c graph. Just moving my mouse causes change in my stats -cs graph, driving both measurements up to 75% or so. When the system is at all loaded, the mouse doesn't respond at all. (Which makes it kind of hard to use the system, given that it's mouse-based!) I wish there were a way to renice usb/kb... -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] Go Plan 9
Sent from my iPhone On Apr 6, 2011, at 1:27 PM, Joel C. Salomon joelcsalo...@gmail.com wrote: On Tuesday, April 5, 2011 1:33:30 PM UTC-4, David Leimbach wrote: What we need is an OS port of Plan 9 to Go that can run hosted on another OS or natively. InfernGo? Fuego. +9! --Joel
Re: [9fans] Making read(1) an rc(1) builtin?
On Tue, 05 Apr 2011 15:53:43 MDT andrey mirtchovski mirtchov...@gmail.com
wrote:
so, an optimized /sys/src/cmd/read.c that doesn't read char-by-char
should give us an improvement, right? right:
9grid% newaread
1.52u 22.56s 15.66rnewaread
and that's just for the silly test string. the improvement would be
bigger for longer strings.
read(1) is allowed to read one line and no more. Given a read
of 1 char, a console device will return a line at most but
other devices can return more than one line, thereby
preventing the next guy from reading it. read(1) has to read
one char at a time.
With a builtin read you don't pay the cost of a fork/exec per
char. And it would be less clunky -- instead of foo=`{read}
you can say read foo. It is not like rc going to get fat by
adding read; it already has to read!
Re: [9fans] Making read(1) an rc(1) builtin?
On 6 April 2011 17:32, Bakul Shah ba...@bitblocks.com wrote:
On Tue, 05 Apr 2011 15:53:43 MDT andrey mirtchovski mirtchov...@gmail.com
wrote:
so, an optimized /sys/src/cmd/read.c that doesn't read char-by-char
should give us an improvement, right? right:
9grid% newaread
1.52u 22.56s 15.66r newaread
and that's just for the silly test string. the improvement would be
bigger for longer strings.
read(1) is allowed to read one line and no more. Given a read
of 1 char, a console device will return a line at most but
other devices can return more than one line, thereby
preventing the next guy from reading it. read(1) has to read
one char at a time.
With a builtin read you don't pay the cost of a fork/exec per
char. And it would be less clunky -- instead of foo=`{read}
you can say read foo. It is not like rc going to get fat by
adding read; it already has to read!
a builtin read would still have to read one character at a time though.
Re: [9fans] Making read(1) an rc(1) builtin?
With a builtin read you don't pay the cost of a fork/exec per
char. And it would be less clunky -- instead of foo=`{read}
you can say read foo. It is not like rc going to get fat by
adding read; it already has to read!
i'd argue that rc shouldn't have any builtins.
and i don't see how that's an improvement to
rc's syntax. all other assignments involve '=',
and can result in command-local variables.
- erik
Re: [9fans] Making read(1) an rc(1) builtin?
a builtin read would still have to read one character at a time though. it's interesting that read breaks with plan 9 message-preserving tradition. - erik
Re: [9fans] Making read(1) an rc(1) builtin?
finally, there are /bin/ape/sh which is a pdksh with its features.
[9fans] Structural Expressions
I've read Rob Pike's paper on structural expressions. Maybe I'm missing
something, but it seems that, the command language of sam (especially
the text-selection mechanism of it; x, y, g chains) could be merged with
expressions in the style of awk actions, and more importantly, added a
functionality we might call subroutines, to create a more elegant and
expressive text processing language.
The idea initially sparked up after looking at the refer database
example given in Pike's paper:
... Consider a refer database, which has multi-line records separated
by blank lines. Each line of a record begins with a percent sign and
a character indicating the type of information on the line: A for
author, T for title, etc. Staying with sam notation, the command to
search a refer database for all papers written by Bimmler is:
x/(.+\n)+/ g/%A.*Bimmler/p
-- break the file into non-empty sequences of non-empty lines and
print any set of lines containing 'Bimmler' on a line after '%A'.
(To be compatible with other tools, a '.' does not match a newline.)
...
What if the structure of the input stream was complex enough to disable
us from relying on a regex feature like the non-newline-matching dot?
It already goes against the whole idea of structural expressions, which
is to rely on the structure of the stream.
We have a structure made of newline-terminated records holding
information. We want to search for a specific piece of information that
could be in any of the records, and when said information is found, act
on the original, whole structure. This means that we have to go back to
a previous selection, in some way. This is probably most cleanly
implemented with the idea of subroutines.
The following expression, written in a hypothetical sam alike syntax
allowing subroutines inside brackets, does the same thing as the sam
expression given in Pike's example:
x/(.+\n)+/ [ x/.*\n/ g/%A.* Bimmler/ R ] p
(R to return true.)
The way in which awk alike syntax would be added to our hypothetical
language is open for discussion. One possibility would be to allow code
blocks that are a subset of awk action blocks, perhaps limited to
variable usage and some comparison operators; guess what this code is
supposed to do:
x/(.+\n)+/ [ x/.*\n/ x/^Age: (.*)/ { $1 17 } ] x/Name: (.*)\n/ y/Name: / p
An alternative would be to make the language awk-based instead of
sam-based, but using sam's text selection commands to populate $0, $1,
etc. (like mentioned by Pike).
Two versions of which one is stream and scripting oriented and leans
more towards awk, and the other buffer and interactive-usage oriented
which leans more towards sam, are perhaps the most likely possibilities.
---
Blergh, now i'm sick of formalism. Disclaimer: I'm 17.
Is this subroutines idea perhaps already implemented in some way?
Taylan Ulrich Bayırlı
[9fans] Busy mouse WAS: Re: Making read(1) an rc(1) builtin?
Jacob Todd jaketodd...@gmail.com writes: What are you running plan 9 on? The mouse shouldn't cause that to happen. IBM ThinkPad T23, PIII, 1100 MHz, P9 4e straight from the ISO. Moving the mouse (USB) generates about 1000 -c/s and about 1300 -s/s. -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] video cards for 1920x1080
This post didn't garner a response. A couple of years later, I have the same question. Is anyone running Plan 9 native at 1920x1080 with an LCD monitor? What video card are you using? What tweaks were necessary to get it to work? coraid has a terminal doing this using the on-board video in vesa 16-bit mode; 32-bit vesa has been trouble for me, but that may have been fixed by the realmode stuff. Whats the hardware? -sl
