[9fans] new home for 9atom
this should be quite a bit faster. http://newftp.9atom.org/9atom.iso.bz2 the address is temporary, while the site transitions. i hope to expand on this soon. it's an all plan 9 setup running nix and ken's file server kernel with aoe storage. - erik
Re: [9fans] arcnet
On 21 Feb 2013, at 17:36, lu...@proxima.alt.za wrote: >> Not sure what you mean, but we run arcnet in bus mode (no central hub), on >> 75 ohm coax with modified PCI cards using 75ohm terminations - 75ohm coax >> abounds in TV stations. > > The cost of maintaining such a system must look prohibitive when > compared with off-the-shelf products. And then you need device > drivers for every generation of OS that comes along. I'd be at least > curious as to how these costs are justified. not really. contemporary controls, who manufacture the pci arcnet cards supply the drivers for windows. we have drivers for the com20020 NIC for our embedded os, and the chips a as cheap as... well, old chips. our bridge and cards are just a different software on a fairly standard modular card which fits in our 3u rack system. if anyone wants detail contact me off-list, this is already creating too much noise. my real reason for asking was to gauge interest in a plan9 arcnet driver as i am perfectly placed to write one, but it seems there is no interest at all. this is a problem thought, i have plenty else to do :-) > I mean, I have tens of kilograms of dated network equipment, including > the odd lumps of coax cabling, but no ways could I find a practical > use for it, much as the community I'm in has no funds for more modern > stuff, so we just do without :-( > > ++L >
Re: [9fans] c compiler bug
no, but drawterm will (i believe). On 21 Feb 2013, at 20:27, David Leimbach wrote: > Can I run it on my iPhone? > > Sent from my iPhone > > On Feb 21, 2013, at 11:58 AM, andrey mirtchovski > wrote: > >> good day. is this the p9p on osx help forum? >>
Re: [9fans] c compiler bug
Can I run it on my iPhone? Sent from my iPhone On Feb 21, 2013, at 11:58 AM, andrey mirtchovski wrote: > good day. is this the p9p on osx help forum? >
Re: [9fans] c compiler bug
No. On Feb 21, 2013, at 14:58, andrey mirtchovski wrote: > good day. is this the p9p on osx help forum? >
Re: [9fans] arcnet
On 21 February 2013 14:39, hiro <23h...@gmail.com> wrote: > yeah, an other quote from that website: > > Designers write their own application layer to meet their particular > needs and frequently do not advertise the fact that ARCNET is being > used in their product. ARCNET receives no name recognition, but is > frequently the network of choice in embedded applications. It is > hidden from the user, but with over 22 million ARCNET nodes sold gives > credibility that ARCNET is indeed popular. > It makes me think that it might be congruent to unix in this fashion. Every day users have no idea what unix servers are, but the internet runs on it. Apparently ARCNET used so much, but we never even hear about it! The silent hero...
Re: [9fans] c compiler bug
Sorry, google's inconsistent mail interface made me post to the list instead of private. I didn't mean to make this a discussion of google's web technolgy, I just want to promote the sending of certain compatible formats that everyone can read without problems. My gmail only sends Content-Type: text/plain; charset=UTF-8 Your's can, too.
Re: [9fans] arcnet
On 21 February 2013 14:26, Jeff Sickel wrote: > > On Feb 21, 2013, at 12:44 PM, erik quanstrom wrote: > However, because of its simple, robust nature, ARCNET controllers are still sold and used in industrial, embedded, and automotive applications. >>> >>> Sounds positively anachronistic. Thanks for the clarification. >> >> and so is rs-232. usb is the way of the future. :-) i say this with >> toungue in cheek, of course. old does not lie along the useful >> axis. > > rs-232/422/485 has a lot going for it, more so than usb. Well, at least > until usb-optical cables become cheaper than copper, and even then you've > got component costs that are more expensive. Moving to ethernet at least > opens up the ability to use MODBUS TCP. > > -jas > > > Anyone look at the website? Kinda cool http://www.arcnet.com/
Re: [9fans] arcnet
On Feb 21, 2013, at 12:44 PM, erik quanstrom wrote: >>> However, because of its simple, robust nature, ARCNET controllers are >>> still sold and used in industrial, embedded, and automotive >>> applications. >> >> Sounds positively anachronistic. Thanks for the clarification. > > and so is rs-232. usb is the way of the future. :-) i say this with > toungue in cheek, of course. old does not lie along the useful > axis. rs-232/422/485 has a lot going for it, more so than usb. Well, at least until usb-optical cables become cheaper than copper, and even then you've got component costs that are more expensive. Moving to ethernet at least opens up the ability to use MODBUS TCP. -jas
Re: [9fans] c compiler bug
On Thu, Feb 21, 2013 at 10:46 AM, Comeau At9Fans wrote: > On Thu, Feb 21, 2013 at 1:39 PM, erik quanstrom > wrote: >> >> On Thu Feb 21 13:23:26 EST 2013, j...@jfloren.net wrote: >> > I think his mail client is just too world-class, breathtaking, >> > amazing, and fabulous--have you tried it? >> > >> > On Thu, Feb 21, 2013 at 10:13 AM, hiro <23h...@gmail.com> wrote: >> > > can you please stop sending html mails? thanks >> >> why does this bother anybody? i hadn't even noticed, and i >> use nedmail to read my mail. which is somewhat of an >> admission of failure. i used to just bring up my mail box in >> acme until google started base64ing heavily. which is oddly >> another admission of defeat. after 40 years of trying, we still don't >> have 8-bit clean email. > > > It's "just" gmail, perhaps my own admission of failure? :) > Gmail has interesting ideas sometimes about when it should send HTML. I seem to have figured out how to make it always send plain-text, but unfortunately I can't remember how exactly I did that. john
Re: [9fans] c compiler bug
On Thu, Feb 21, 2013 at 01:39:14PM -0500, erik quanstrom wrote: > On Thu Feb 21 13:23:26 EST 2013, j...@jfloren.net wrote: > > I think his mail client is just too world-class, breathtaking, > > amazing, and fabulous--have you tried it? > > > > On Thu, Feb 21, 2013 at 10:13 AM, hiro <23h...@gmail.com> wrote: > > > can you please stop sending html mails? thanks > > why does this bother anybody? i hadn't even noticed, and i > use nedmail to read my mail. which is somewhat of an > admission of failure. i used to just bring up my mail box in > acme until google started base64ing heavily. which is oddly > another admission of defeat. after 40 years of trying, we still don't > have 8-bit clean email. > > - erik > Are you seriously marking this request WORKSFORME
Re: [9fans] c compiler bug
On Thu, Feb 21, 2013 at 1:39 PM, erik quanstrom wrote: > On Thu Feb 21 13:23:26 EST 2013, j...@jfloren.net wrote: > > I think his mail client is just too world-class, breathtaking, > > amazing, and fabulous--have you tried it? > > > > On Thu, Feb 21, 2013 at 10:13 AM, hiro <23h...@gmail.com> wrote: > > > can you please stop sending html mails? thanks > > why does this bother anybody? i hadn't even noticed, and i > use nedmail to read my mail. which is somewhat of an > admission of failure. i used to just bring up my mail box in > acme until google started base64ing heavily. which is oddly > another admission of defeat. after 40 years of trying, we still don't > have 8-bit clean email. It's "just" gmail, perhaps my own admission of failure? :) -- 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?
Re: [9fans] arcnet
> > However, because of its simple, robust nature, ARCNET controllers are > > still sold and used in industrial, embedded, and automotive > > applications. > > Sounds positively anachronistic. Thanks for the clarification. and so is rs-232. usb is the way of the future. :-) i say this with toungue in cheek, of course. old does not lie along the useful axis. - erik
Re: [9fans] c compiler bug
On Thu Feb 21 13:23:26 EST 2013, j...@jfloren.net wrote: > I think his mail client is just too world-class, breathtaking, > amazing, and fabulous--have you tried it? > > On Thu, Feb 21, 2013 at 10:13 AM, hiro <23h...@gmail.com> wrote: > > can you please stop sending html mails? thanks why does this bother anybody? i hadn't even noticed, and i use nedmail to read my mail. which is somewhat of an admission of failure. i used to just bring up my mail box in acme until google started base64ing heavily. which is oddly another admission of defeat. after 40 years of trying, we still don't have 8-bit clean email. - erik
Re: [9fans] c compiler bug
I think his mail client is just too world-class, breathtaking, amazing, and fabulous--have you tried it? On Thu, Feb 21, 2013 at 10:13 AM, hiro <23h...@gmail.com> wrote: > can you please stop sending html mails? thanks > > On 2/21/13, Comeau At9Fans wrote: >> On Mon, Feb 18, 2013 at 9:38 AM, Charles Forsyth >> wrote: >> >>> On 18 February 2013 13:02, Comeau At9Fans >>> wrote: >>> seems to be doing is setting up allowing the call to compile and once that is satisfied then the subsequent definition "has" to match it, as perhaps a way to do type punning. >>> >>> >>> No, the compiler is simply applying scope rules. Without that inner >>> declaration explicitly overriding the outer declaration--whether static >>> or >>> extern is used-- >>> it will not compile (eg, if you put "static void fn(Outer*);" or "extern >>> void fn(Outer*);" and remove static from fn in the file scope). >>> >>> The behaviour is undefined in ANSI C if two declarations that refer to >>> the >>> same object or function do not have compatible types >>> (normally, you're protected by another rule that you can't have >>> incompatible declarations *in the same scope*). >>> >>> ANSI C does, however, forbid the inner static declaration (which >>> surprised >>> me) >>> "The declaration of an identifier for a function that has block scope >>> shall have no explicit storage-class specifier other than extern." >>> (6.7.1) >>> >> >> We're probably saying the same thing. As you say ANSI C forbids it hence >> my comment about normally a diagnostic from a so-called mainstream >> compiler. And as you say without a declaration it would not compile >> either. The declaration should normally be in global scope (it could have >> been), which would have also produced a diagnostic since Inner/Outer don't >> match. That leaves the declaration where Eric showed it, which the Plan 9 >> compiler obviously allowed. As you note the net effect is it's undefined >> (if we're using ANSI C as the metric) hence created a kind of type pun >> (even if the original code did it as a mistake). >> >> -- >> 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? >> >
Re: [9fans] c compiler bug
can you please stop sending html mails? thanks On 2/21/13, Comeau At9Fans wrote: > On Mon, Feb 18, 2013 at 9:38 AM, Charles Forsyth > wrote: > >> On 18 February 2013 13:02, Comeau At9Fans >> wrote: >> >>> seems to be doing is setting up allowing the call to compile and once >>> that is satisfied then the subsequent definition "has" to match it, as >>> perhaps a way to do type punning. >> >> >> No, the compiler is simply applying scope rules. Without that inner >> declaration explicitly overriding the outer declaration--whether static >> or >> extern is used-- >> it will not compile (eg, if you put "static void fn(Outer*);" or "extern >> void fn(Outer*);" and remove static from fn in the file scope). >> >> The behaviour is undefined in ANSI C if two declarations that refer to >> the >> same object or function do not have compatible types >> (normally, you're protected by another rule that you can't have >> incompatible declarations *in the same scope*). >> >> ANSI C does, however, forbid the inner static declaration (which >> surprised >> me) >> "The declaration of an identifier for a function that has block scope >> shall have no explicit storage-class specifier other than extern." >> (6.7.1) >> > > We're probably saying the same thing. As you say ANSI C forbids it hence > my comment about normally a diagnostic from a so-called mainstream > compiler. And as you say without a declaration it would not compile > either. The declaration should normally be in global scope (it could have > been), which would have also produced a diagnostic since Inner/Outer don't > match. That leaves the declaration where Eric showed it, which the Plan 9 > compiler obviously allowed. As you note the net effect is it's undefined > (if we're using ANSI C as the metric) hence created a kind of type pun > (even if the original code did it as a mistake). > > -- > 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? >
Re: [9fans] arcnet
> However, because of its simple, robust nature, ARCNET controllers are > still sold and used in industrial, embedded, and automotive > applications. Sounds positively anachronistic. Thanks for the clarification. ++L
Re: [9fans] arcnet
> Not sure what you mean, but we run arcnet in bus mode (no central hub), on > 75 ohm coax with modified PCI cards using 75ohm terminations - 75ohm coax > abounds in TV stations. The cost of maintaining such a system must look prohibitive when compared with off-the-shelf products. And then you need device drivers for every generation of OS that comes along. I'd be at least curious as to how these costs are justified. I mean, I have tens of kilograms of dated network equipment, including the odd lumps of coax cabling, but no ways could I find a practical use for it, much as the community I'm in has no funds for more modern stuff, so we just do without :-( ++L
Re: [9fans] c compiler bug
On Mon, Feb 18, 2013 at 10:02 AM, erik quanstrom wrote: > > No, the compiler is simply applying scope rules. Without that inner > > declaration explicitly overriding the outer declaration--whether > > static or extern is used-- it will not compile (eg, if you put "static > > void fn(Outer*);" or "extern void fn(Outer*);" and remove static from > > fn in the file scope). > > since nested functions are not allowed, applying nested scope seems > a bit odd. anyway, ... > It's often to be refrained from even if it were extern and not static. > if the declaration were in the same place but the referenced > function were in another file, the -T would have prevented the > link. my question is, why doesn't the c compiler internally > apply the same rule? > Wild guessing that it's probably an oversight that it got allowed. -- 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?
Re: [9fans] c compiler bug
On Mon, Feb 18, 2013 at 9:38 AM, Charles Forsyth wrote: > On 18 February 2013 13:02, Comeau At9Fans wrote: > >> seems to be doing is setting up allowing the call to compile and once >> that is satisfied then the subsequent definition "has" to match it, as >> perhaps a way to do type punning. > > > No, the compiler is simply applying scope rules. Without that inner > declaration explicitly overriding the outer declaration--whether static or > extern is used-- > it will not compile (eg, if you put "static void fn(Outer*);" or "extern > void fn(Outer*);" and remove static from fn in the file scope). > > The behaviour is undefined in ANSI C if two declarations that refer to the > same object or function do not have compatible types > (normally, you're protected by another rule that you can't have > incompatible declarations *in the same scope*). > > ANSI C does, however, forbid the inner static declaration (which surprised > me) > "The declaration of an identifier for a function that has block scope > shall have no explicit storage-class specifier other than extern." (6.7.1) > We're probably saying the same thing. As you say ANSI C forbids it hence my comment about normally a diagnostic from a so-called mainstream compiler. And as you say without a declaration it would not compile either. The declaration should normally be in global scope (it could have been), which would have also produced a diagnostic since Inner/Outer don't match. That leaves the declaration where Eric showed it, which the Plan 9 compiler obviously allowed. As you note the net effect is it's undefined (if we're using ANSI C as the metric) hence created a kind of type pun (even if the original code did it as a mistake). -- 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?
Re: [9fans] netif stat bug
On Thu Feb 21 10:41:55 EST 2013, cinap_len...@gmx.de wrote: > stating the "stats" and "ifstats" files in a ethernet tree > that has no active connections can cause the kernel to > go into endless loop or returns wrong stat data. > > the bug is in port/netif.c in the netifgen() function: > > - if(t == N2ndqid || t == Ncloneqid || t == Naddrqid){ > + if(t == N2ndqid || t == Ncloneqid || t == Naddrqid || t == Nstatqid || > t == Nifstatqid){ > yes, the dump says we fixed this 3 may 2010. it probablly got lost in the discussion about Nmtuqid. - erik
[9fans] netif stat bug
stating the "stats" and "ifstats" files in a ethernet tree that has no active connections can cause the kernel to go into endless loop or returns wrong stat data. the bug is in port/netif.c in the netifgen() function: - if(t == N2ndqid || t == Ncloneqid || t == Naddrqid){ + if(t == N2ndqid || t == Ncloneqid || t == Naddrqid || t == Nstatqid || t == Nifstatqid){ the problem is subtile and comes from the dual use of the gen functions for generating tree enumeration and stating. maybe it would be a good idea to make devstat() error out after a million iterations just instead of looping forever to make this easier to diagnose? this is the same class of bug that was discovered in the devdraw device some time ago. it would be a good idea to audit other devices for these kind of bugs while being at it. -- cinap
[9fans] 6c bug
uncomment the prints, and the function will return the correct value. it looks like the compiler is aliasing n and m, from 6c -S: TEXTlog2ceil+0(SB),0,$16 MOVQBP,SI MOVQBP,AX DECQ,AX MOVQBP,CX ANDQAX,CX CMPQCX,$0 JEQ ,3(PC) MOVL$1,AX JMP ,2(PC) MOVL$0,AX MOVLAX,BX MOVLSI,DX JMP ,2(PC) JMP ,3(PC) >> CMPQSI,SI JNE ,2(PC) JMP ,5(PC) MOVQSI,AX SHRQ$32,AX MOVLAX,DX ADDL$32,BX [etc]. - erik #include #include typedef u64int uintmem; static uchar log2v[256]; void log2init(void) { int i; for(i=2; i round up */ n = (uint)m; //print("%llux %ux\n", m, n); if(sizeof(uintmem)>sizeof(uint) && n != m){ n = (u64int)m>>32; r += 32; } //print("r = %d\n", r); if((n>>8) == 0) return log2v[n] + r; if((n>>16) == 0) return 8 + log2v[n>>8] + r; if((n>>24) == 0) return 16 + log2v[n>>16] + r; return 24 + log2v[n>>24] + r; } void main(void) { log2init(); print("%d\n", log2ceil(0x43000ull)); exits(""); }
Re: [9fans] arcnet
Sent from my iPhone On Feb 21, 2013, at 6:16 AM, Charles Forsyth wrote: > > On 21 February 2013 12:54, hiro <23h...@gmail.com> wrote: >> they say it's pretty deterministic. good read from wikipedia. > > I was disappointed to discover that ARCNET did not, in fact, send packets by > shooting huge electrical arcs from sender to receiver, in the manner of a > proper science fiction film. Teslanet?
[9fans] fortune nomination
> Too many renames; must be X source! from output of p9p `acid -q', ran on basically any GNU software. the offending code: $PLAN9/src/cmd/acid/util.c:/must.be.X.source if(renamed > 5 && !quiet) { print("Too many renames; must be X source!\n"); -- dexen deVries [[[↓][→]]]
Re: [9fans] cold boot installation of Plan 9 on a eeepc 701 :(
> 497M memory: 497M kernel data, 0M user, 18M swap > found partition #S/sdD0/data 0 7,815,024 > disks: sdD0 > trying sdD0...dosinit: can´t open #S/sdD0/9fat > dosint #S/sdD0/9fat failed iirc, 9boot doesn't use floppy emulation, but it might then need cdfs. i haven't tried this, so someone who has should speak up. :-) - erik
Re: [9fans] Mouse inverted Y-axis
Hi all, was not something changed in Plan9 kernel(?) in the near past related to the mouse wheel scrolling direction? I still have opposite scrolling direction when scrolling my mouse wheel (even with my patched kb.c). :( Thanks for any help. Pavel
Re: [9fans] multi-processor support
> Also, is there a way to mount the plan9 internal partitions (9fat, fossil > etc) on Linux? if you just want to rescue your plan9.ini, then boot the cd in that image and edit it directly. you can toss in new kernels that way, too. if you get one kernel limping along in one vm and set up a nat for your vms, you can pxe boot test kernels. it makes life quite a bit nicer. i know that this works for vmware fusion. should probablly work for workstation, too. > I tried *nomp=0, but still only saw one CPU. I removed the line altogether, > now the kernel panics (see attachment). Any way to override the kernel > params in plan9.ini? it appears that the lapic clock is reasonable, but what is not reasonable is the cpu clock is 1/10th the frequency printed on the cpu0 line. i think this may be because the emulation is confusing the 8253 timing. if this is true, then the solution is to change this line archmp.c:79:if(cpuserver && m->havetsc) to remove the cpu server bit. i removed this test from 9atom kernels, since i didn't understand how the distinction could be helpful, and it seemed like the seed of a very long debugging session starting with the puzzle "why does the cpu kernel work on this hardware, but the terminal not?" - erik
Re: [9fans] multi-processor support
> Also, is there a way to mount the plan9 internal partitions > (9fat, fossil etc) on Linux? You could do it easily, using 9vx: % disk/partfs plan9.img % disk/fdisk -p /dev/sdXX/data >/dev/sdXX/ctl % disk/prep -p /dev/sdXX/plan9 >/dev/sd00/ctl % fossil/fossil -m 20 -f /dev/sdXX/fossil -c 'srv -AWP fossil' -c 'srv -p fscons' % mount /srv/fossil /n/fossil
Re: [9fans] arcnet
> How do they propose to maintain it when the equipment starts failing? Not sure what you mean, but we run arcnet in bus mode (no central hub), on 75 ohm coax with modified PCI cards using 75ohm terminations - 75ohm coax abounds in TV stations. The advantage of this is we can use existing Video wiring for control systems, and there is no single point of failure. -Steve
Re: [9fans] multi-processor support
Have you ticked? Enable the IO APIC