Or from the seventh floor of our 100+ year old building.
sent from my ipad
On Nov 21, 2012, at 1:28 AM, "John Floren" wrote:
> It means that the football hooligans will be out of town rather than
> filling all the hotels and drinking all the beer. I'm told that Athens
> during a college footbal
On Wed, Nov 21, 2012 at 10:14 AM, Brantley Coile wrote:
> Or from the seventh floor of our 100+ year old building.
>
Is that considered old? I mean my house is 100+ year old, but I
consider it newish. I guess it depends on the continent :-).
G.
On Wed Nov 21 01:28:51 EST 2012, j...@jfloren.net wrote:
> It means that the football hooligans will be out of town rather than
> filling all the hotels and drinking all the beer. I'm told that Athens
> during a college football game is truly a sight to see. (From a
> distance. On closed-circuit ca
On Wed Nov 21 07:22:16 EST 2012, pau...@gmail.com wrote:
> On Wed, Nov 21, 2012 at 10:14 AM, Brantley Coile wrote:
> > Or from the seventh floor of our 100+ year old building.
> >
>
> Is that considered old? I mean my house is 100+ year old, but I
> consider it newish. I guess it depends on the c
I'am trying (again) to build svn for plan9 native.
8c is blowing up with the error:
bad in naddr: NAME cache_init_state
the offending like is:
static volatile svn_atomic_t cache_init_state = 0;
Is this legal c code, static and volatile?
if it is anyone any ideas how to fix 8c - comp
static is scope, volatile has dynamic effects, very dynamic. you
should be able to #define volatile
to nothing (-Dvolatile'=') and it will usually work. certainly for
statics and externals.
the one real effect it might have is on automatic variables if the
usage in conjunction
with setjmp is a litt
8c is for Plan9's C dialect.
Look into /sys/doc/ape.ps
2012/11/21 Steve Simon
> I'am trying (again) to build svn for plan9 native.
>
> 8c is blowing up with the error:
>
> bad in naddr: NAME cache_init_state
>
> the offending like is:
>
> static volatile svn_atomic_t cache_init_state
>static volatile svn_atomic_t cache_init_state = 0;
svn_atomic_t? has it got its own thread library? coroutines?
By which I meant that yes, it's legal ANSI C code to combine them. The
strange way the compiler implements volatile references probably led
to that odd diagnostic.
As I said, I'd try nopping the volatile.
On 21 November 2012 13:30, Charles Forsyth wrote:
> static is scope, volatile has dynamic ef
On Wed, Nov 21, 2012 at 8:30 AM, Bence Fábián wrote:
> 8c is for Plan9's C dialect.
> Look into /sys/doc/ape.ps
>
This was not a useful answer to Steve's question.
- Dan C.
yeah i realized since. sorry
2012/11/21 Dan Cross
> On Wed, Nov 21, 2012 at 8:30 AM, Bence Fábián wrote:
>
>> 8c is for Plan9's C dialect.
>> Look into /sys/doc/ape.ps
>>
>
> This was not a useful answer to Steve's question.
>
> - Dan C.
>
>
>
Thanks for the comments,
I dropped the volatile and that bit compiles,
I am getting close I think.
And in answer to charles, there is all sorts going on in there.
counting the semicolons gives:
Apache portable utils 16049
Apache portable runtime 24852
sqlite3
> and for context:
>
> /sys/src/9107216
half of that is for obsolete pc drivers.
- erik
jas has pretty much got this licked. it's good enough for
an alpha release. the known issues now are
- an intermittent deadlock when going into full screen mode
and doing heavy draw i/o.
- i/o to /mnt/term blocks the draw thread so large file transfers
block screen updates.
https://bitbucket.org
works as expected (including the deadlock on fulscreen). a bit
flickery on window swipes, but nothing i can't live without.
it appears that one can enter full-screen but can't exit it?
xscr/vines in benchmark mode: 39fps for the new drawterm, 43fps for the old.
On Wed, Nov 21, 2012 at 9:57 AM,
> it appears that one can enter full-screen but can't exit it?
results may vary. it's a bug.
since both issues can be tracked to a difference in pthreads,
it's likely that's where your 3fps went, too.
- erik
On Nov 21, 2012, at 11:57 AM, andrey mirtchovski wrote:
> works as expected (including the deadlock on fulscreen). a bit
> flickery on window swipes, but nothing i can't live without.
>
> it appears that one can enter full-screen but can't exit it?
if it doesn't deadlock, then the same ctrl-cm
On Nov 21, 2012, at 6:20 AM, Gorka Guardiola wrote:
> On Wed, Nov 21, 2012 at 10:14 AM, Brantley Coile wrote:
>> Or from the seventh floor of our 100+ year old building.
>>
>
> Is that considered old? I mean my house is 100+ year old, but I
> consider it newish. I guess it depends on the cont
On Wed, 2012-11-21 at 13:34 -0600, Jeff Sickel wrote:
> On this continent anything beyond the date of expiration is
> considered old. The typical date of expiration of a house is
> 30yrs (conveniently in line with the typical mortgage on a
> new construction).
Our neighbor's house in New Castle,
hola,
usize, really?
any reason not use this opportunity to join the world and use inttypes.h or
stdint.h format?
On Nov 20, 2012, at 6:49 PM, erik quanstrom wrote:
> i've written a little man page
> /n/sources/contrib/quanstro/types
> http://iwp9.org/magic/man2html/2/types
>
>
On Wed Nov 21 19:19:21 EST 2012, benave...@gmail.com wrote:
> hola,
>
> usize, really?
>
> any reason not use this opportunity to join the world and use inttypes.h or
> stdint.h format?
have you read the opengroup pubs?
http://pubs.opengroup.org/onlinepubs/007904975/basedefs/stdint.h.h
i think that go's scalar types would work better. also usize is a bit
dicky.
brucee
On Nov 22, 2012 12:23 PM, "erik quanstrom" wrote:
> On Wed Nov 21 19:19:21 EST 2012, benave...@gmail.com wrote:
> > hola,
> >
> > usize, really?
> >
> > any reason not use this opportunity to join the world and
I agree with brucee here about the Go type names: I'd rather see uint64,
int64, uint32, int32, etc.
usize doesn't bother me much. New C programmers are often confused by
size_t being unsigned (even experienced ones at times); this makes it clear.
On Wed, Nov 21, 2012 at 8:35 PM, Bruce Ellis wr
uintptr for size_t.
brucee
On Nov 22, 2012 1:10 PM, "Dan Cross" wrote:
> I agree with brucee here about the Go type names: I'd rather see uint64,
> int64, uint32, int32, etc.
>
> usize doesn't bother me much. New C programmers are often confused by
> size_t being unsigned (even experienced ones
That will obviously work, and indeed I use uintmem the same way to
avoid having yet another type,
but that's only because that's specific to the kernel, and of little use.
Otherwise, I think there's a difference between storing a pointer
value in an integer, and storing a size.
For one thing, many
heads up! uintptr in all over the go packages because it is right. i'd like
an example of where usize wins, as it has to be same as uintptr. what is
sizeof(x)?
struct {
char stuff[8 * GB];
} x;
quite a reasonable but rookie decl in 64 bit land.
brucee
On 22 November 2012 13:35, Charles For
26 matches
Mail list logo
