[9fans] FAT32 question
I'm mounting a FAT32 flashdrive on a RPi. However, it seems that some sort of legacy 8.3 filename situation is existing. For instance, if I have a directory containing x.c and a23456789.c that the former is taken as X.C and the latter is taken as shown. Therefore, to compile x.c is not possible. So for instance, echo *.c produces a different result than echo *.C. I tried mv'ing the problem files and then back but same results. I do believe that historically there was some sort of interpretations such as this in the evolution from FAT to FAT32, but not sure it should be so in current version, or, at least, other operating systems don't take this interpretation. Is there an option or something I'm missing? How do I get to process x.c as x.c and not X.C. -- 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] FAT32 question
On Wed, Mar 27, 2013 at 8:33 AM, erik quanstrom quans...@quanstro.net wrote: On Wed Mar 27 08:26:04 EDT 2013, comeauat9f...@gmail.com wrote: ... I tried mv'ing the problem files and then back but same results. modulo other bugs, dossrv does something kind of interesting. if you explictly walk to x.c, you will have a match. but it doesn't do this when stating a directory. so if the file lists as x.c you should be able to compile it. ladd# cd /n/9fat ladd# lc 9LOAD 9PCCPU.GZ 9pccpu PLAN9.INI ladd# cat plan9.ini/dev/null lladd# cat PLAN9.ini/dev/null ladd# cat PLAN9.INI/dev/null That seems correct from what I saw. The problem is in globing though, *.c will yield differently than x.c/X.c/x.C/X.C. Anyway, I seem to be past this part of things as I just tried mv'ing on Plan 9 itself rather than the host system and that seems to be letting x.c be seen as itself, or whatever it is that's going on or not is good enough for me now. -- 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] FAT32 question
On Wed, Mar 27, 2013 at 12:02 PM, Nicolas Bercher nberc...@yahoo.fr wrote: On 27/03/2013 15:18, Comeau At9Fans wrote: ... I seem to be past this part of things as I just tried mv'ing on Plan 9 itself rather than the host system and that seems to be letting x.c be seen as itself... Maybe a solution would be do to this in two passes. Since x.c and X.C describe the same file, it is not possible to rename it directly: cpu% touch X.C cpu% mv X.C x.c mv: X.C and ./x.c are the same Just try something like this: cpu% mv X.C _x.c cpu% mv _x.c x.c cpu% ls *.c x.c cpu% That's exactly what I did, however, from what I could see, it only worked if mv'd on Plan 9. -- 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 charles.fors...@gmail.comwrote: On 18 February 2013 13:02, Comeau At9Fans comeauat9f...@gmail.com 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
On Mon, Feb 18, 2013 at 10:02 AM, erik quanstrom quans...@quanstro.netwrote: 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 Thu, Feb 21, 2013 at 1:39 PM, erik quanstrom quans...@quanstro.netwrote: 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] c compiler bug
On Sat, Feb 16, 2013 at 9:38 PM, erik quanstrom quans...@quanstro.netwrote: i don't think this should link, since wrongaddr calls fn with an Outer* not an Inner*. ... Normally in more mainstream C the nested static void fn(Outer*); declaration would produce a diagnostic and instead what it (the compiler and the code) 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. -- 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] Mini PCs
On Mon, Aug 6, 2012 at 7:03 AM, crazyes...@gmail.com wrote: On Monday, June 11, 2012 6:19:20 AM UTC+8, Comeau At9Fans wrote: I preferred android os system, so I brought one piece MK802 mini android pc from http://miniandroidpc.com. It makes my TV to be a Internet/Smart TV. So far it works well and I like it very much! Yes, and they're evolving so it'll be interesting to see how they take shape, get used, etc. We still have a few left (via http://www.EnvyThisStuff.com ) and still have the offer to provide one to somebody who is serious about and capable of porting Plan 9 to it. -- 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] cc nit?
On Sat, Jun 30, 2012 at 5:25 PM, erik quanstrom quans...@quanstro.netwrote:
i haven't tracked down thie issue yet, but it appears that ?c
generate unparsable acid output
; cat void.c
typedef struct PNOTIFY PNOTIFY
struct PNOTIFY {
voidemptiness;
};
eot; 8c -a void.c
void.c:1 not a function
void.c:5 syntax error, last name: emptiness
...
I'm not sure where this is documented, but, isn't the problem (not just
syntactically) with the above the missing semicolon on the typedef line and
not the void'ness issue?
--
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] cc nit?
On Sun, Jul 1, 2012 at 4:39 PM, Charles Forsyth charles.fors...@gmail.comwrote: instead of trying to make void work as a data type declaration, it might be clearer to accept an empty struct. Many compilers do just that, however, that said, unless the compiler is prepared for it, since it effectively yields a struct of zero size which normally is a no-go, it could produce bugs involving sizeof, initializers, pointer addition et al, even some divisions by zero if the compiler is making certain assumptions already, unless it already can have zero length objects of this nature for some other reasons. -- 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] cc nit?
On Sun, Jul 1, 2012 at 6:32 PM, Charles Forsyth charles.fors...@gmail.comwrote: Yes, I was assuming the same approach as for the existing void data declaration, that the structure is given a nominal size, for just the reasons you give. (That's what gcc seems to do.) On 1 July 2012 23:22, Comeau At9Fans comeauat9f...@gmail.com wrote: Many compilers do just that, however, that said, unless the compiler is prepared for it, since it effectively yields a struct of zero size which normally is a no-go, it could produce bugs involving sizeof, initializers, pointer addition et al, even some divisions by zero if the compiler is making certain assumptions already, unless it already can have zero length objects of this nature for some other reasons. Actually gcc gives it (the empty struct) sizeof zero (same as for its zero length arrays). Comeau mimics that behavior in gcc-mode, but used to/still can also generate a dummy internal member too (usually a char bringing forth sizeof 1). -- 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] cc nit?
On Sun, Jul 1, 2012 at 6:34 PM, Charles Forsyth charles.fors...@gmail.comwrote: Even better might be to do neither: eliminate support for void data, and give the declaration a type that doesn't provoke so much discussion. It's just a placeholder. On 1 July 2012 23:32, Charles Forsyth charles.fors...@gmail.com wrote: Yes, I was assuming the same approach as for the existing void data declaration, that the structure is given a nominal size, for just the reasons you give. (That's what gcc seems to do.) I don't know where this will lead for 8c et al, so I'll throw it out there anyway in the spirit of placeholders: int : 0; -- 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] cc nit?
On Sun, Jul 1, 2012 at 6:45 PM, erik quanstrom quans...@quanstro.netwrote:
Many compilers do just that, however, that said, unless the compiler is
prepared for it, since it effectively yields a struct of zero size which
normally is a no-go, it could produce bugs involving sizeof,
initializers,
pointer addition et al, even some divisions by zero if the compiler is
making certain assumptions already, unless it already can have zero
length
objects of this nature for some other reasons.
actually, kenc is pretty good about all these. if you have
struct fu {void x;};
and take sizeof(struct fu), that will give a diagnostic error.
the reason i avoided it was to not mess with the grammer, but if this is a
common thing, maybe it's no big deal.
though as charles points out, it is a bit of a waste of time.
If my memory serves, there is some wiggle room in C89 about how the empty
struct works, though generally it wouldn't fly, and C99 disallows it, while
C++ allows it (but it's sizeof 0). Plus it's a common extension made
prevalent via gcc.
--
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] Mini PCs
On Mon, Jun 11, 2012 at 12:08 PM, Ethan Grammatikidis eeke...@fastmail.fmwrote: On Sun, 10 Jun 2012 18:19:20 -0400 Comeau At9Fans comeauat9f...@gmail.com wrote: Ok, so, unless I was asleep at the wheel following these discussions, there's been a few mini PCs to come about lately: * Raspberry Pi * Cotton Candy * Mele A1000 * MK802 We have a small number of the latter (MK802 running Android 4.0, which claims to have a Allwinner ARM A10 1.5Ghz Cortex-A8 processor) for sale FWIW. I mention this as LINUX is making its way onto some of these devices, er computers, so I expect that Plan 9 has possibilities here too. I'm still waiting for the Zaurus port somebody did last year or so. ;) Well, I'm not exactly waiting. He said something about performance problems which I can believe. Use a couple of pipes (foo|bar|baz) in the Z's native Linux and it about halves the useful performance, so I can't imagine Plan 9 doing well on it. Inferno would probably do better. I'm not trying to compare Plan 9 with LINUX here but saying this, and, I'm still trying to get syncronized on the story, but at least LINUX can survive on the MK802. There has been some complaints about speed, however, I also understand that was with the first generation of them and that the current lot being released this week addressed that. We shall see shortly. -- 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] Mini PCs
On Mon, Jun 11, 2012 at 11:46 AM, erik quanstrom quans...@quanstro.netwrote: I think three including me actually. The drivers factor might only make it a good cpu server methinks. I would totally love one as a terminal though. sadly, the 10/100 ethernet is provided through a flakey usb hub (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28t=7380) for me, that's three strikes (less than gbe, usb, flakey) but in this case the first strike was enough to exclude it from consideration. I think that's a significant point, if similar turns out to be the case with many of these devices, certainly for use with something critical. That said, I also think there's nothing wrong with these kind of stick PC's for lots of purposes, even if for fooling around. That said :), enough stuff is already flakey that has mass appeal/use, etc (not saying these have mass appeal, just just sayin'). -- 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] Mini PCs
On Mon, Jun 11, 2012 at 5:07 PM, John Floren j...@jfloren.net wrote: ...As for anything not based on the supported SoCs, well, until people stop sitting on ass saying boy that would be a nice terminal and actually start PORTING the damn thing, it'll never be more than Yet Another 120-message 9fans Thread. That's not my thing at the moment, but, if anybody is serious AND capable, I'm probably willing to provide an MK802 to that person once our second lot comes in (I hope on Tuesday). -- 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] Mini PCs
On Tue, Jun 12, 2012 at 1:12 AM, Kurt H Maier kh...@intma.in wrote: Evaluations of the Sheevaplug in particular revealed it tended to overheat badly if you put any significant load on the networking components. Heating problems combined with poor quality control would be my guess as to why that whole thing never flew. I also understand some of these other thingies have heating problems too, but that they're being addressed and believe at least in the just sent out batch of MK802's (I said second generation in the other message, that's probably not a fair characterization) it is supposed to be either fixed or at least alleviated. -- 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] Mini PCs
On Tue, Jun 12, 2012 at 1:05 AM, Nick LaForge nicklafo...@gmail.com wrote: Sure. But the Sheevaplug (same SoC) is now 3 years old, and it looks like the whole 'plug-computer' thing never took off. Since phones seem to be the only consistent market for fast Arm SoCs, we're likely to see one with usb3 before gbe. But I'll shut up now in deference to somebody with actual experience. I'm pretty sure what you're saying is at least partially true, if not even more. I'm also still not sure even these current crop will suffice. But if nothing else, there is at least now a springboard, so at least whether it make sense to jump off it will at least be more tested. -- 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?
[9fans] Mini PCs
Ok, so, unless I was asleep at the wheel following these discussions, there's been a few mini PCs to come about lately: * Raspberry Pi * Cotton Candy * Mele A1000 * MK802 We have a small number of the latter (MK802 running Android 4.0, which claims to have a Allwinner ARM A10 1.5Ghz Cortex-A8 processor) for sale FWIW. I mention this as LINUX is making its way onto some of these devices, er computers, so I expect that Plan 9 has possibilities here too. -- 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] 5i floating point?
Anybody with an ARM Plan 9 willing to run a binary for me? It just emits a few lines out of output and I promise it is not a virus. -- 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?
[9fans] 5i floating point?
From 9vx.OSX if I compile this
#include u.h
#include libc.h
void main(void)
{
float f = 99.99;
exits(0);
}
with 5c/5l and then 5i it, it gives:
undefined instruction trap pc #102c inst ed9b0100 class 92
Is floating point supported with 5i?
--
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] 5i floating point?
On Wed, May 9, 2012 at 10:36 AM, cinap_len...@gmx.de wrote: aiju wrote an arm emulator for 9front some time ago and i remember he implemented floating point on it. might have a look there: http://code.google.com/p/plan9front/source/browse/sys/src/cmd/5e Thanks. What's the most sane way of downloading it to 9vx.OSX? -- 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] 5i floating point?
Ok, linking gives: main: undefined: ainc in main Looks to be a function (which also seems to be undeclared in 5e.c), anybody know where it is located? -- 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] 5i floating point?
On Wed, May 9, 2012 at 11:34 AM, David du Colombier 0in...@gmail.comwrote: Ok, linking gives: main: undefined: ainc in main Looks to be a function (which also seems to be undeclared in 5e.c), anybody know where it is located? It's defined in the libc. You can add it to /sys/include/libc.h if you wish. If I nm /386/lib/libc.a | grep ainc it returns nothing. -- 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] 5i floating point?
On Wed, May 9, 2012 at 12:03 PM, David du Colombier 0in...@gmail.comwrote: If I nm /386/lib/libc.a | grep ainc it returns nothing. Your libc is obviously not up-do-date. term% nm /n/sources/plan9/386/lib/libc.a | grep ainc atom.8: T ainc See /n/sources/plan9/sys/src/libc/386/atom.s I have it built and it seems to be working, at least with APE built apps, but I think it's not with non-APE due to something I'm doing. Thanks all. -- 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] integer width on AMD64 (was: Re: AMD64 system)
On Mon, May 7, 2012 at 6:36 AM, dexen deVries dexen.devr...@gmail.comwrote: On Monday 07 of May 2012 11:27:29 Charles Forsyth wrote: The MIPS, PowerPC and SPARC all grew to 64 bits from 32 bits, so 32 bit quantities (and usually but not always 16 bit and 8 bit quantities) have suitable instructions to fetch them. fwiw, back in my uni days we were using some old 64bit Solaris on Sun's UltraSparcs, and those had sizeof(int) == 8. i remember distinctly how my lame programs (developed on x86 and assuming sizeof(int) == 4) tripped on it. can't recall exact versions, but the CPUs were somewhere around 400MHz or so, and GCC was the compiler of choice. I may be recalling this incorrectly, but I think you're right about the 8, but didn't they also eventually bring it to 4 as well (or maybe I'm thinking of Sun C)? -- 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] integer width on AMD64 (was: Re: AMD64 system)
On Mon, May 7, 2012 at 8:44 AM, erik quanstrom quans...@quanstro.netwrote: ... processor bw memory bw == smaller integers faster memory bw processor bw == natural integers faster (this is yet another reason that int_fast* are a half-baked idea. how does the compiler know this relation for the target machine ahead of time?) ... I think that is all so, and I'm not necessarily trying to defend its problems, but on the same note, similar assumptions are also make about int, and it can be argued that int_fast* etc just become par for that course, especially given that there may be command line arguments allowing the user to give some of these things a poke so to speak. And this is not alone in those kinds of things (which are probably not even really engineering compromises), for instance, take malloc. -- 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] integer width on AMD64
On Sat, May 5, 2012 at 10:58 PM, Joel C. Salomon joelcsalo...@gmail.comwrote:
On 05/05/2012 05:06 PM, Comeau At9Fans wrote:
On Sat, May 5, 2012 at 1:48 PM, Charles Forsyth wrote:
if it's performance you're worried about, for programs that don't
care about width, i'd expect 32 bits at least
to match performance with 64 bits (if there's a measurable
difference). for one thing, cache lines will contain
more values, and several will be fetched at once when cache lines
are filled.
And for programs that do care about this, C99 provides things such as
int_fast64_t (which IIRC 8c et al does not currently support).
stdint.h is just a bunch of typedef's, some of which have been
included, under different names (u{8,16,32,64}int), in u.h. Wouldn't
be hard to provide for APE if anyone wants it.
Yes, the u{...}int names are important. Those different names are
normally for other (though obviously related) purposes (conceptually
int_exact_*), and the int_least_* and int_fast_* names, usually are built
from the exact ones. BTW, more generally re the greater issue raised
earlier by an OP, if ones intent is X bits, then int is not expressing that
intent, and even if your assumption happens to be correct, it might also
create a portability faux pas if that is a concern. Also, if int was X
bits underneath, then arrays of int, now in the case of X == 64 effectively
become arrays of long stuff since not only is there now maybe wasted
memory, but cache management and such can be a concern. This all has
architecture dependencies though.
--
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] integer width on AMD64 (was: Re: AMD64 system)
I've heard that 64-bit is not an immediate win over 32 for graphics and such, but then again also heard that 32 bit is not the pits, and that it more or less becomes a wash. So, in your case, what is is about 32 that makes it a *significant* win, given that the space would have been used in either case (I don't know if that's true, but assuming it is)? (And sorry if I've connected graphics and such with image processing since it may be you're doing something I'm not realizing and so we might be talking about different things.) On Sun, May 6, 2012 at 5:20 AM, steve st...@quintile.net wrote: i think this is an often misunderstood fact, 32bit ints are, in my experience, a significant win compared with 64bit when doing memory intensive work - image processing in my case. -Steve On 5 May 2012, at 06:48 PM, Charles Forsyth charles.fors...@gmail.com . if it's performance you're worried about, for programs that don't care about width, i'd expect 32 bits at least to match performance with 64 bits (if there's a measurable difference). for one thing, cache lines will contain more values, and several will be fetched at once when cache lines are filled. -- 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] integer width on AMD64
On Sun, May 6, 2012 at 9:10 AM, erik quanstrom quans...@quanstro.netwrote:
Yes, the u{...}int names are important. Those different names are
normally for other (though obviously related) purposes (conceptually
int_exact_*), and the int_least_* and int_fast_* names, usually are built
the int_least_* names appear to me to be completely wasted, given
this is how the normal types are defined and that you couldn't depend
on the extra bits.
Kind of. The thing is there is the minimums required by the standard and
then there is the minimums provided by the implementation, the latter of
which at least has to match the former. But yes, the least names can be
viewed to just thrown a wrench into it all.
also, how do you debug code written like this?
Not easily especially when you begin to look at its interaction with I/O as
well.
one complete test for each possible definition of int_least_*?
of course, that leads to the question, is that set known?
one also wonders about int_fast_* as well. fast /for what/ exactly?
IIRC the Standard even specifically leaves that question open. I think the
goal was to try to codify/match some existing practice at the time
realizing that it wasn't perfect but at least gave a fight chance in some
situation and in those it couldn't, there was probably going to be bumps in
the road either way. I know it can lead to a why bother situation then.
it seems that all this is in respose to the fact that the c-std version
of u32int is not required.
IIRC the full set is not required but I think say uint32_t is. But it's
been so long you might just be right.
(the names are somewhat offensive to
good taste, so i refer to them as one does carlin's list, by suggestion.)
rather than fix that issue, layering on another set of types was the
solution. really?
IIRC the naming was raised a number of times.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n868.htm :
“ It can also be argued that programmers that use the 'intN_t' more
than
likely really meant to use the 'int_leastN_t' types. Such
programmers
probably want a type with a guaranteed number of bits rather than an
exact number of bits.
It can be argued further that use of the 'intN_t' names is not
portable
because they may not exist in all implementations. (An
implementation
is not required to provide these types.)
unfortunately, there are still programmers who use the definition
more complicated ≡ more better. evidently believing in the
transitive nature of more over false premises.
Personally I could never buy the whole argument for all those names and
such, and probably would be happy with just the exact ones. I'm trying to
recall the exact etymology of it but it's too long ago to recall.
--
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] integer width on AMD64 (was: Re: AMD64 system)
On Sat, May 5, 2012 at 11:33 AM, dexen deVries dexen.devr...@gmail.comwrote: On Wednesday 25 of April 2012 15:32:06 erik quanstrom wrote: also, in case you missed it sizeof(int)==sizeof(long)==4 on both 32 and 64 bit plan 9, so recompiled programs won't get bigger integers just for the recompiling. pardon silly question, but... why, on 64bit machine, P9 uses 32bit ints and longs? my impression is, int was supposed to match machine's preferred (best performance etc.) integeral datatype, and long was supposed to be enough to hold a pointer? (i.e., sizeof(long) = sizeof(void*)) Re supposed if you mean according to say Standard C, no. Even so-called KR C was not black and white regarding this per se. Standard C only provided minimum sizes. Indeed, there is often preferences, but that's usually up to vendors, and lots of it yield *-defined behaviors. As it should. There is also the issue of that, if, you really want a 64-bit integer, then, using int is certainly moving towards a direction of a programming error, since int does not often yield such a beast, even on so-called systems which could provide it. C99 provides for stuff such as int_least64_t for those who really need such. -- 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] integer width on AMD64 (was: Re: AMD64 system)
On Sat, May 5, 2012 at 1:48 PM, Charles Forsyth charles.fors...@gmail.comwrote: if it's performance you're worried about, for programs that don't care about width, i'd expect 32 bits at least to match performance with 64 bits (if there's a measurable difference). for one thing, cache lines will contain more values, and several will be fetched at once when cache lines are filled. And for programs that do care about this, C99 provides things such as int_fast64_t (which IIRC 8c et al does not currently support). In a way, expecting something out of 'int' is sloppy, despite it's wide use. -- 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] some pcc questions
On Fri, Apr 20, 2012 at 12:01 PM, Jens Staal staal1...@gmail.com wrote: The second issue that I have been meaning to ask the list is about pcc and bitfields - are they supported or is this some sort of can of worms I have stepped into? Bitfields are allowed to have lots of *-defined behavior, so often they are cans of worms on many platforms. Don't know if you're referring to this kind of issue or something more specific that you might feel is a limitation on Plan 9. -- 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] nix at lsub
On Thu, Apr 19, 2012 at 1:56 PM, Lucio De Re lu...@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?
Re: [9fans] assembly syntax in plan 9
On Wed, Jan 18, 2012 at 12:48 PM, Bakul Shah ba...@bitblocks.com wrote: On Jan 17, 2012, at 11:21 AM, Comeau At9Fans comeauat9f...@gmail.com wrote: On Mon, Jan 16, 2012 at 2:03 PM, Bakul Shah ba...@bitblocks.com wrote: How do you deal with longjmp? I don't have it in front of me, but I do seem to recall the Standard allows that the VLA might still be around though, believe it has an example with said, for better or worse... Do you have a reference? Ok, so, gunna make me look, let's see, ok: 7.13.2.1p5, note the may's and might's. There should be narrative backing those up. On Jan 16, 2012, at 10:51 AM, Comeau At9Fans comeauat9f...@gmail.com wrote: On Mon, Jan 16, 2012 at 10:41 AM, Bakul Shah ba...@bitblocks.com wrote: A frame pointer is needed for C99's variable length arrays but not otherwise. Only an issue if ever plan9 C is extended to handle C99 or C1x. gcc has to do the right thing even with -fno-frame-pointer. What we do in problematic cases with Comeau is to generate code to arrange for the allocation of the VLA on the heap. I'm not saying this is perfect, but at least it gets the feature implementable and up and running as a portable implementation versus perhaps not being able to implement it at all on some platforms. Seems to me if you can port C, you can use a FP to implement VLAs without alloca games and more efficiently. You can always store the FP in stack local memory if out of registers. I probably overstated the situation by saying not being able to implement it at all... probably should have said I never thought of it beyond the obvious implementations. -- 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] assembly syntax in plan 9
On Mon, Jan 16, 2012 at 2:03 PM, Bakul Shah ba...@bitblocks.com wrote: How do you deal with longjmp? I don't have it in front of me, but I do seem to recall the Standard allows that the VLA might still be around though, believe it has an example with said, for better or worse... Anyway, at some point we're able to detect that the previous VLA(s) is no longer active and toss them. On Jan 16, 2012, at 10:51 AM, Comeau At9Fans comeauat9f...@gmail.com wrote: On Mon, Jan 16, 2012 at 10:41 AM, Bakul Shah ba...@bitblocks.com wrote: A frame pointer is needed for C99's variable length arrays but not otherwise. Only an issue if ever plan9 C is extended to handle C99 or C1x. gcc has to do the right thing even with -fno-frame-pointer. What we do in problematic cases with Comeau is to generate code to arrange for the allocation of the VLA on the heap. I'm not saying this is perfect, but at least it gets the feature implementable and up and running as a portable implementation versus perhaps not being able to implement it at all on some platforms. -- 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] assembly syntax in plan 9
We do allow VLAs in C++ mode as well, but currently keep them separate from EH. On Mon, Jan 16, 2012 at 2:39 PM, Charles Forsyth charles.fors...@gmail.comwrote: They are compiling C++ which has language-visible exception handling instead. On 16 January 2012 19:03, Bakul Shah ba...@bitblocks.com wrote: How do you deal with longjmp? On Jan 16, 2012, at 10:51 AM, Comeau At9Fans comeauat9f...@gmail.com wrote: On Mon, Jan 16, 2012 at 10:41 AM, Bakul Shah ba...@bitblocks.com wrote: A frame pointer is needed for C99's variable length arrays but not otherwise. Only an issue if ever plan9 C is extended to handle C99 or C1x. gcc has to do the right thing even with -fno-frame-pointer. What we do in problematic cases with Comeau is to generate code to arrange for the allocation of the VLA on the heap. I'm not saying this is perfect, but at least it gets the feature implementable and up and running as a portable implementation versus perhaps not being able to implement it at all on some platforms. -- 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] assembly syntax in plan 9
On Mon, Jan 16, 2012 at 2:49 PM, erik quanstrom quans...@quanstro.netwrote: On Mon Jan 16 14:40:41 EST 2012, charles.fors...@gmail.com wrote: They are compiling C++ which has language-visible exception handling instead. On 16 January 2012 19:03, Bakul Shah ba...@bitblocks.com wrote: How do you deal with longjmp? i thought this wasn't entirely supported, see the limitations section. http://drdobbs.com/184401468 (i had a better reference, but can't find it anymore.) My recollection is that that paragraph correctly reflects the situation. -- 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] assembly syntax in plan 9
On Mon, Jan 16, 2012 at 3:11 PM, Joel C. Salomon joelcsalo...@gmail.comwrote: On 01/16/2012 02:03 PM, Bakul Shah wrote: On Jan 16, 2012, at 10:51 AM, Greg Comeau comeauat9f...@gmail.com wrote: What we do in problematic cases with Comeau is to generate code to arrange for the allocation of the VLA on the heap. I'm not saying this is perfect, but at least it gets the feature implementable and up and running as a portable implementation versus perhaps not being able to implement it at all on some platforms. How do you deal with longjmp? I recall reading the source for a (mostly-) portable alloca() that checked where on the call-stack is was invoked from and released memory for any alloca() invocation from lower on the stack. (The allocations themselves were on the heap.) We do some analogous book keeping as well. -- 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] assembly syntax in plan 9
On Mon, Jan 16, 2012 at 10:41 AM, Bakul Shah ba...@bitblocks.com wrote: A frame pointer is needed for C99's variable length arrays but not otherwise. Only an issue if ever plan9 C is extended to handle C99 or C1x. gcc has to do the right thing even with -fno-frame-pointer. What we do in problematic cases with Comeau is to generate code to arrange for the allocation of the VLA on the heap. I'm not saying this is perfect, but at least it gets the feature implementable and up and running as a portable implementation versus perhaps not being able to implement it at all on some platforms.
Re: [9fans] Plan 9/plan9port coding conventions
On Wed, Jan 11, 2012 at 1:41 PM, smi...@icebubble.org wrote:
As readers may remember from a previous thread, I have historically
been, well, less than enamored with some aspects of the coding style
used in Plan 9/plan9port. Now that I'm getting into development, I'd
like to know what coding conventions the Plan 9 community endorses. I
have read the Plan 9 compiler paper, and understand the conventions
described in it. While conventions such as composing variable names
using lower case letters and no underscores do irk me a bit, I can live
with them---because those are the conventions that the community has
adopted. However, there are a number of stylistic features in Plan
9/p9p code which I've noticed (which AREN'T discussed in the compiler
paper) and I'm wondering whether they're intentional conventions or not.
(1) For example, P9 code tends to use variable names like i and j,
where I would typically use self-documenting variable names like row
and col. Variable names like row and col are much easier to
search for (i.e., with a right-click), too. Names like i and j
(which occur in many identifiers) will generate many false positives.
Most stylistic things have both pros and cons. So for instance, you are
correct that i and j *are* hard to grep for. And you are also correct that
one should normally strive for so-called self-documenting names. However,
with that in mind, row and col specifically have their own limitations (for
instance, they don't have much more meaning than i and j and in some ways
can be considered worse). So, as in many disciplines, we're left with a
bunch of engineering compromises to wiggle through. Some of the
compromises will be obvious flaws and mistakes, and then so must be dealt
with accordingly (resistance or learned helplessness :).
(2) In functions, variables are often declared together in one
paragraph, and then, later, initialized in another paragraph, as in:
int i;
char *s;
/* stuff */
i = 0;
s = nil;
rather than something like:
int i = 0;
char *s = nil;
Neither of these is necessarily superior to the other, or other forms.
(3) Lots of global variables are used, without any distinguishing
syntax, i.e. char *f. I prefer to designate global variables with
something like a leading underscore, i.e. char *_filename.
I usually consider this to be putting a set of bad choices into a pot, and
picking from them at will. It also tends to yield exactly the competing
styles you're bumping into.
(4) In ARGBEGIN/ARGEND blocks, boolean switches are often set using the
++ operator rather than |= 1, i.e.:
case 'v':
verbose++;
case 'x':
x++;
as opposed to:
case 'v':
verbose++;
case 'x':
x |= 1;
Again, we have language limitations yielding multiple acceptable'ish
compromises of 6 of one and 1/2 dozen of another.
(5) P9 code tends to repeat constructs such as argv[i] over and over
throughout the code, like:
for(i = 0; i argc; i++){
somestuff(argv[i]);
otherstuff(argv[i]);
}
whereas I would typically use something like:
int argnum;
char *argstr;
for(argnum = 0; argnum argc; argnum++){
argstr = argv[argnum];
somestuff(argstr);
otherstuff(argstr);
}
This one's a mixed bag again. Used to be you may have had to do something
like this in the name of efficiency (of the executable code). There can be
times to prefer the latter, but that said, argstr has it's own issues, so
does creating another variable when just saying what something is in the
first place can be its best name, but repeating complicated dimensions,
struct membership selections, etc. can get messy too. So
Are these practices official/unofficial Plan 9 coding conventions? Are
they used for performance purposes? Are they just poor style? Or has
this kind of style been used for so long that it's BECOME Plan 9's style
of choice? Also, is it considered polite or acceptable coding practice
to alter the style of code written by other contributors? I don't want
to step on anybody's toes by fixing style which other Plan 9
developers consider to be Plan 9 style coding conventions.
Be careful when delving into poor. Some loose thoughts: Beauty is in
the eye of the beholder. There often is not a best, just engineering
compromises. This does not mean one will not run across something horrid.
Continue to question all. Many things are often at odds.
--
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] Plan 9 stack limit?
On Tue, Sep 6, 2011 at 6:39 PM, ron minnich rminn...@gmail.com wrote: the app crashes or 9vx blows up? You might consider ratrace. It helps me a lot with this stuff. 9vx can blow up too but not related to this problem, so in this case it's the app I'm talking about, or at least, appears to be the app. Might get something like 1476 TheApp fault 0x4 no segment Typing ratrace at the command line does not find it. I'll try to locate it on the ISO, or do I need to pick it up online? It's for Plan 9 right, and not to run 9vx under it on OSX? - Greg -- 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] Plan 9 stack limit?
On Tue, Sep 6, 2011 at 7:10 PM, Mathieu Lonjaret mathieu.lonja...@gmail.com wrote: maybe slightly relevant: http://9fans.net/archive/2010/05/446 (see also answers from others as well afterwards). Thanks, I'll take a look. - Greg -- 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] Plan 9 stack limit?
On Tue, Sep 6, 2011 at 8:00 PM, Russ Cox r...@swtch.com wrote: On 9vx the entire address space for a running process is 256 MB. The heap grows up and the stack grows down. It is easy to believe you could have blown out the stack. Ok. Is it just the program you ran that crashed or is it all of 9vx? The app. 9vx will continue to run after it. It give a little dump thing on the screen with 1476 The.App fault 0x4 no segment send to the shell account 9vx was started from. Running acid on the app does not appear to bring up a line of code that should really be having a problem (though of course if it's a bug I could be wrong). The fact that you said '9vx.OSX' makes me think you might be running one of the pre-compiled binaries, which are unfortunately a bit old. If it's not a stack overflow problem, you might have better luck with http://swtch.com/~rsc/9vx.OSX.gz, which I just compiled from the latest sources. I'll give it a try. What will be the difference in this version in regards to a problem like the one I'm seeing? -- 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] Plan 9 stack limit?
On Wed, Sep 7, 2011 at 10:05 AM, Russ Cox r...@swtch.com wrote: On Wed, Sep 7, 2011 at 9:43 AM, Comeau At9Fans comeauat9f...@gmail.com wrote: The app. 9vx will continue to run after it. It give a little dump thing on the screen with 1476 The.App fault 0x4 no segment send to the shell account 9vx was started from. Running acid on the app does not appear to bring up a line of code that should really be having a problem (though of course if it's a bug I could be wrong). regs() might be interesting, along with asm(*PC). If I remember the output format correctly that looks like it faulted accessing 0x4, which seems more likely a null pointer deref than stack overflow. What will be the difference in this version in regards to a problem like the one I'm seeing? Probably nothing at all. If 9vx had been crashing then the difference would hopefully have been '9vx doesn't crash anymore'. :-) huh, oh ok :) I'll be giving it a whirl shortly... -- 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] Plan 9 stack limit?
On Wed, Sep 7, 2011 at 11:46 AM, ron minnich rminn...@gmail.com wrote: OK, you're working from an old root if you can't find ratrace :-) 9fs sources, go grab it in sys/src/cmd, build and install it. ratrace -c your-command-line ron p.s. First thing I do with a new 9vx is get all the sources down and rebuilt all lib/bin from scratch. It's worth it. I think I tried something like that a few months back and could not seem to be successful. No doubt I did something wrong though at the time it was not obvious what. Where is the most current source I should be getting the bytes from? -- 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] Plan 9 stack limit?
On Wed, Sep 7, 2011 at 12:38 PM, Comeau At9Fans comeauat9f...@gmail.comwrote: On Wed, Sep 7, 2011 at 10:05 AM, Russ Cox r...@swtch.com wrote: On Wed, Sep 7, 2011 at 9:43 AM, Comeau At9Fans comeauat9f...@gmail.com wrote: The app. 9vx will continue to run after it. It give a little dump thing on the screen with 1476 The.App fault 0x4 no segment send to the shell account 9vx was started from. Running acid on the app does not appear to bring up a line of code that should really be having a problem (though of course if it's a bug I could be wrong). regs() might be interesting, along with asm(*PC). If I remember the output format correctly that looks like it faulted accessing 0x4, which seems more likely a null pointer deref than stack overflow. What will be the difference in this version in regards to a problem like the one I'm seeing? Probably nothing at all. If 9vx had been crashing then the difference would hopefully have been '9vx doesn't crash anymore'. :-) huh, oh ok :) I'll be giving it a whirl shortly... Hmm, I downloaded the new 9vx.OSX, recompiled the app, and don't seem to be able to get it to fail anymore. Unless this 9vx is known to fix issues such as this, I've been around the block enough to be suspect I may not have really solved the problem, so will do more testing. -- 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] Plan 9 stack limit?
On Wed, Sep 7, 2011 at 4:12 PM, Comeau At9Fans comeauat9f...@gmail.comwrote: Hmm, I downloaded the new 9vx.OSX, recompiled the app, and don't seem to be able to get it to fail anymore. Unless this 9vx is known to fix issues such as this, I've been around the block enough to be suspect I may not have really solved the problem, so will do more testing. Threw a lot more at it and it seemed ok, until just now. This time, for the first time (with this problem) the app did not crash but 9vx.OSX crashed and gave: libvx32/emu.c:1668: failed assertion `(void*)extra (void*)codetab' Any thoughts? -- 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?
[9fans] Plan 9 stack limit?
I have an application that is crashing on Plan 9. Now, it could be a bug in the code, but in the past, similar problems with the same code base on other platforms have always been caused by the system stack being blown out, and in a less rare case, the systems running out of process space. The crashes are happening on 9vx.OSX (which is currently the only place it can be tested on our systems). Does 9vx have any such limitations and/or does Plan 9 in general have any such limits? And if so, can they be changed? I see some of the threading calls have stack size requests possible, but don't see any such concerns as a consequence of a fork, though I'm sure fork is semantically equivalent to some other calls when all is said and done. Like I said, it could be a bug in the code, but I'd like to approach it from this level first assuming there is any such interaction that even exists so any insights would be appreciated. -- 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 code differencing
On Wed, Aug 31, 2011 at 9:01 AM, Steve Simon st...@quintile.net wrote:
Anyone have any pointers to a diff for C code.
I have two libraries, A and B.
B is and expanded and modified version of A and I have been
asked to extract A from B to build two libraries one
built on top of the other.
I'm unclear what you're seeking. For instance, given this:
// original/a.c
// ...mumbly...
void foo()
{
int i;
i = x();
i = y()
}
and
// new/a.c
// ...mumbly...
void foo()
{
int i;
i = y();
i = z();
}
the obvious line of difference is the removal of i = x() and the addition of
i = z(); So what will the diff'd version look like, conceptually would it
be this? :
// diffd/a.c
// ...mumbly...
// ...possible more mumbly...
void foo()
{
int i;
diffd_old();
i = y();
diffd_new();
}
--
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] Hey, new to this. Trying to get plan9 to work in a VM.
On Mon, Jun 6, 2011 at 1:04 AM, David du Colombier 0in...@gmail.com wrote: Ok, I tried running 9vx for my linux install and it dies. Ubuntu 11.04 fully updated x64_86. I don't know what else info will help. Are you sure you tried one of the current 9vx repository ([1] or [2]), and not the old repository [3] (2009-12-27) or a very old binary [4] (2008-07-01)? [1] https://bitbucket.org/yiyus/vx32 [2] https://bitbucket.org/rminnich/vx32 [3] https://bitbucket.org/rsc/vx32 [4] http://pdos.csail.mit.edu/~rsc/9vx-0.12.tar.bz2 Where does http://swtch.com/9vx fit into things these days? -- 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] looking for Virtual Host providers that permit Plan 9
On Mon, May 9, 2011 at 5:57 PM, Skip Tavakkolian skip.tavakkol...@gmail.com wrote: Anyone know of such an animal? I don't recall they specifically list it, but I'd be fairly certain that Panix would allow it. You'd have to check them out panix.com for details. -- 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?
[9fans] Plan 9 IRL
Hi, I've have some curiosity about a few things for a while. The thread about the web and Plan 9 got me rethinking… It's often touted that Plan 9 is a research OS, and I believe that, and I understand some of the implications of that (could swear I went to a NYC USENIX(?) meeting at the foot of the Brooklyn Bridge (Pratt?) to hear Ken and somebody else describe it around what must have been circa 1987?). But I also believe there was also commercial undertones to Plan 9 at some points. Plus, as well, I'm certain that Plan 9 is obviously not just being used by hobbyists and schools and would probably be surprised to here some of the places and some of the things it is being used at/on/with. So, is there is a good sampling provided somewhere of Plan 9 in the real world (commercial or otherwise), notable projects using Plan 9, etc? Although I do see the Bell Labs site mentioning some applications ported to Plan 9 and a short list of organizations using it, I haven't run across much else. For instance, one thing I always like about what Stroustrup did re C++ was to provide a good representational sampling of C++ via say: http://www2.research.att.com/~bs/applications.html and of compilers via say: http://www2.research.att.com/~bs/compilers.html As he writes it is incomplete, but nonetheless still helpful documents IMO. Does something exist to that level in regards to Plan 9? -- 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] Compiling 9atom kernel WAS: Re: spaces in filenames
On Sun, May 8, 2011 at 2:27 PM, tlaro...@polynum.com wrote: On Thu, May 05, 2011 at 09:54:28AM +, Greg Comeau wrote: Some more food for thought: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, definition, not smart enough to debug it. --Brian Kernighan With a caveat: when one is really clever, one finds the shortest path to the truth i.e. the simplicity; this means that really clever guys make programs easy to debug because these are the simplest ones doing the job. In Brian Kernighan's sentence, s/cleverly/sophisticatedly/ (this is probably a barbarism, but in french sophistiqué is pejorative: obfuscation, convoluted etc.). I think one can usually read things into such phrases, sometimes validly sometime invalidly. I also think it is often easy to disprove such phrases, and so to instead to often just try to find the spirit of the phrase even if it is found to be problematic. For instance, easy to debug could mean the program is so riddled with problems just opening to a random part of it will yield a problem with little effort it could also mean to the contrary that it was written so well that any bugs could be easy to find, but equally on the contrary the program could be such a bleeping mess that even though bug riddled getting through the logic etc could be tormenting at best while at the same time a clean program with few bugs can sometimes make finding the long bug harder because it is the lone last one. In the end there is often no pure bug cause or pure bug resolution mechanism but something in the middle that is contextual. All IMO. -- 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] Compiling 9atom kernel WAS: Re: spaces in filenames
On Fri, May 6, 2011 at 8:59 AM, erik quanstrom quans...@quanstro.net wrote: Do you not think it's possible or worthwhile to have a great(er) desktop (or consumer-oriented embedded device) experience built atop Plan 9? i'm not 100% sure what the op ment. but one way one could read it is that plan 9 is for research, it doesn't need to be usable. i don't think that was the point, and i wouldn't sign up for that intpretation. the way i would read that is that since we value clean ideas and orthogonal design more than polish, you get a clean and malleable os, but you don't get this for free. it's not that easy to port stuff to plan 9, and it's hard to get folks interested in certain boil-the- oceans projects like building a full html 5 web browser. Let's say for argument's sake that errno pulls this off. Let's say he manages to get something like FireFox working on Plan 9. Let's say that the executable is fully functional (don't know if that's possible but let's assume it is). How does this change things literally, conceptually and philosophically? Consider this question across the board, for instance, can Plan 9 handle it (whatever that means)? How does it change Plan 9's future? What I'm getting at is that I'm hearing things about it being a research OS, so what would it mean for a research OS to have a full fledged browser available for it? -- 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] Compiling 9atom kernel WAS: Re: spaces in filenames
On Fri, May 6, 2011 at 7:18 PM, errno er...@cox.net wrote: Quick attempt at damage control, hope it's not too late: On Friday, May 06, 2011 03:32:26 PM Comeau At9Fans wrote: [...] errno pulls this off. [...] something like FireFox working on Plan 9. Let's say that the executable is fully functional People may take it you literally mean: Firefox-on-Plan-9. nonono I tried real hard to avoid that misunderstanding. Yes, sorry about that. I did not mean to imply it literally, just took it to the next step so to speak -- 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] Compiling 9atom kernel WAS: Re: spaces in filenames
On Fri, May 6, 2011 at 7:47 PM, errno er...@cox.net wrote: On Friday, May 06, 2011 03:32:26 PM Comeau At9Fans wrote: How does this change things literally, conceptually and philosophically? Consider this question across the board, for instance, can Plan 9 handle it (whatever that means)? How does it change Plan 9's future? What I'm getting at is that I'm hearing things about it being a research OS, so what would it mean for a research OS to have a full fledged browser available for it? A veneer of html + css + javascript over the intrinsically distributed foundations of Plan 9, would provide the bridge for an entire class of use-cases currently out of reach: When friends and family can comfortably use it, for activities other than data-archival, then I can deploy it for uses beyond my own limited, personal learning projects. The benefit I intend to receive for this is the freedom to enjoy Plan 9 more often, while reducing linux dependency, and reducing overall costs: both in hardware requirements, and in maintenance time/effort. ... How and/or why do you feel it would reduce the hardware requirements of friends and family? And especially so versus linux? -- 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?
