Menu
▾
▴
mesa3d-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(10) |
Apr
(28) |
May
(41) |
Jun
(91) |
Jul
(63) |
Aug
(45) |
Sep
(37) |
Oct
(80) |
Nov
(91) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(48) |
Feb
(121) |
Mar
(126) |
Apr
(16) |
May
(85) |
Jun
(84) |
Jul
(115) |
Aug
(71) |
Sep
(27) |
Oct
(33) |
Nov
(15) |
Dec
(71) |
| 2002 |
Jan
(73) |
Feb
(34) |
Mar
(39) |
Apr
(135) |
May
(59) |
Jun
(116) |
Jul
(93) |
Aug
(40) |
Sep
(50) |
Oct
(87) |
Nov
(90) |
Dec
(32) |
| 2003 |
Jan
(181) |
Feb
(101) |
Mar
(231) |
Apr
(240) |
May
(148) |
Jun
(228) |
Jul
(156) |
Aug
(49) |
Sep
(173) |
Oct
(169) |
Nov
(137) |
Dec
(163) |
| 2004 |
Jan
(243) |
Feb
(141) |
Mar
(183) |
Apr
(364) |
May
(369) |
Jun
(251) |
Jul
(194) |
Aug
(140) |
Sep
(154) |
Oct
(167) |
Nov
(86) |
Dec
(109) |
| 2005 |
Jan
(176) |
Feb
(140) |
Mar
(112) |
Apr
(158) |
May
(140) |
Jun
(201) |
Jul
(123) |
Aug
(196) |
Sep
(143) |
Oct
(165) |
Nov
(158) |
Dec
(79) |
| 2006 |
Jan
(90) |
Feb
(156) |
Mar
(125) |
Apr
(146) |
May
(169) |
Jun
(146) |
Jul
(150) |
Aug
(176) |
Sep
(156) |
Oct
(237) |
Nov
(179) |
Dec
(140) |
| 2007 |
Jan
(144) |
Feb
(116) |
Mar
(261) |
Apr
(279) |
May
(222) |
Jun
(103) |
Jul
(237) |
Aug
(191) |
Sep
(113) |
Oct
(129) |
Nov
(141) |
Dec
(165) |
| 2008 |
Jan
(152) |
Feb
(195) |
Mar
(242) |
Apr
(146) |
May
(151) |
Jun
(172) |
Jul
(123) |
Aug
(195) |
Sep
(195) |
Oct
(138) |
Nov
(183) |
Dec
(125) |
| 2009 |
Jan
(268) |
Feb
(281) |
Mar
(295) |
Apr
(293) |
May
(273) |
Jun
(265) |
Jul
(406) |
Aug
(679) |
Sep
(434) |
Oct
(357) |
Nov
(306) |
Dec
(478) |
| 2010 |
Jan
(856) |
Feb
(668) |
Mar
(927) |
Apr
(269) |
May
(12) |
Jun
(13) |
Jul
(6) |
Aug
(8) |
Sep
(23) |
Oct
(4) |
Nov
(8) |
Dec
(11) |
| 2011 |
Jan
(4) |
Feb
(2) |
Mar
(3) |
Apr
(9) |
May
(6) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(1) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Brian P. <br...@pr...> - 2000-05-19 13:17:17
|
"Jacob (=Jouk) Jansen" wrote: > > Hi all, > > compiling Mesa from today's CVS I get > > tons of errors in dispatch like: > > cc /include=([-.include],[])/define=(FBIND=1) DISPATCH.C > > KEYWORD1 void KEYWORD2 NAME(CompressedTexImage3DARB)(GLenum target, GLint level, > GLint internalformat, GLsizei width, GLsizei height, GLsizei depth, GLint borde > r, GLsizei imageSize, GLvoid *data) > .......................^ > %CC-W-MISMATPARAM, In this declaration, parameter 9 has a different type than sp > ecified in an earlier declaration of this function. > at line number 3377 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20000519.MESA.SRC]G > LAPITEMP.H;1 > > Has someone forgotten to update dispatch.c ?????? I've checked in some more updates. Please try again. -Brian |
|
From: <jo...@du...> - 2000-05-19 06:54:09
|
Hi all,
compiling Mesa from today's CVS I get
tons of errors in dispatch like:
cc /include=([-.include],[])/define=(FBIND=1) DISPATCH.C
KEYWORD1 void KEYWORD2 NAME(CompressedTexImage3DARB)(GLenum target, GLint level,
GLint internalformat, GLsizei width, GLsizei height, GLsizei depth, GLint borde
r, GLsizei imageSize, GLvoid *data)
.......................^
%CC-W-MISMATPARAM, In this declaration, parameter 9 has a different type than sp
ecified in an earlier declaration of this function.
at line number 3377 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20000519.MESA.SRC]G
LAPITEMP.H;1
Has someone forgotten to update dispatch.c ??????
Jouk
Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse
>------------------------------------------------------------------------------<
Jouk Jansen
jo...@hr...
Technische Universiteit Delft tttttttttt uu uu ddddddd
Nationaal centrum voor HREM tttttttttt uu uu dd dd
Rotterdamseweg 137 tt uu uu dd dd
2628 AL Delft tt uu uu dd dd
Nederland tt uu uu dd dd
tel. 31-15-2781536 tt uuuuuuu ddddddd
>------------------------------------------------------------------------------<
|
|
From: Brian P. <br...@pr...> - 2000-05-18 22:49:09
|
Howard wrote: > > Brian Paul wrote: > > > > > Do you think this will happen? Now that we have a robust libGLU, the > > > only obstacle to writing a single port for all platforms is the addition > > > of the OSMesa enhancements to standard OpenGL. Are you planning to add > > > the libOSMesa.so you describe to XFree86 4.0? > > > > Yes. I got it up and working on Friday. I've been out of town > > since then and have a little bit of clean up left to do. > > > Beautiful. Let us know as soon as we can try it. If you download and build the glxmisc-3-0-0-branch from the DRI CVS tree you'll get it. Simply relink your app with -lOSMesa -lGL. -Brian |
|
From: Brian P. <br...@pr...> - 2000-05-18 18:35:01
|
"Suhaib M. Siddiqi" wrote: > > I ported a SGI 3D software to Linux using Mesa 3.0 a while ago. The > original author of the code > now has a newer version fo source code and had been struggling to get > binaries working with > libGLw.so on RedHat Linux 6.2. Since I was the one who originally > ported code, he asked for help. > > It lloks like problem is in libGLw. It does a core dump. Here is the > cut and paste. He and I used > widgets-sgi. Any suggestions? > > Regards > Suhaib > > Your data initialized ok, building X/Motif widgets ... > trying to create GlGeomWidgetSB > created GlGeomWidgetSB > trying to create GlGeomWidgetSB > ribbons: GLwDrawA.c:411: createAttribList: Assertion > `(ptr-w->glwDrawingArea.attribList)<30' failed. > Aborted (core dumped) It looks like the interger attribute array might be one element too small to accomodate all possible GLX options that the widget might specify. In widgets-sgi/GLwDrawA.c try changing the value of ATTRIBLIST_SIZE to a value larger than 30, even 31 might be sufficient. -Brian |
|
From: Howard <ho...@me...> - 2000-05-18 17:46:54
|
Brian Paul wrote: > > > Do you think this will happen? Now that we have a robust libGLU, the > > only obstacle to writing a single port for all platforms is the addition > > of the OSMesa enhancements to standard OpenGL. Are you planning to add > > the libOSMesa.so you describe to XFree86 4.0? > > Yes. I got it up and working on Friday. I've been out of town > since then and have a little bit of clean up left to do. > Beautiful. Let us know as soon as we can try it. Thanks, -- Howard Luby ho...@me..., Ph:(248)540-2251, Fax:(248)540-3138 Mediascape Corporation http://www.mediascape.com |
|
From: Brian P. <br...@pr...> - 2000-05-18 14:39:58
|
Howard wrote: > > > Brian Paul wrote: > > > > OS/Mesa is not in XFree86 4.0 in any form. However, this is something > > I was thinking about yesterday and I think it would be possible to add > > this feature to XFree86's libGL. Basically, I'd provide a new library, > > libOSMesa.so which you'd have to link with. It would patch into the > > libGL.so dispatcher and work like stand-alone Mesa. > > > Brian, > > Do you think this will happen? Now that we have a robust libGLU, the > only obstacle to writing a single port for all platforms is the addition > of the OSMesa enhancements to standard OpenGL. Are you planning to add > the libOSMesa.so you describe to XFree86 4.0? Yes. I got it up and working on Friday. I've been out of town since then and have a little bit of clean up left to do. -Brian |
|
From: Howard <ho...@me...> - 2000-05-16 01:19:10
|
> Brian Paul wrote: > > OS/Mesa is not in XFree86 4.0 in any form. However, this is something > I was thinking about yesterday and I think it would be possible to add > this feature to XFree86's libGL. Basically, I'd provide a new library, > libOSMesa.so which you'd have to link with. It would patch into the > libGL.so dispatcher and work like stand-alone Mesa. > Brian, Do you think this will happen? Now that we have a robust libGLU, the only obstacle to writing a single port for all platforms is the addition of the OSMesa enhancements to standard OpenGL. Are you planning to add the libOSMesa.so you describe to XFree86 4.0? Thanks, -- Howard Luby ho...@me..., Ph:(248)540-2251, Fax:(248)540-3138 Mediascape Corporation http://www.mediascape.com |
|
From: Suhaib M. S. <ssi...@in...> - 2000-05-15 23:50:10
|
I ported a SGI 3D software to Linux using Mesa 3.0 a while ago. The original author of the code now has a newer version fo source code and had been struggling to get binaries working with libGLw.so on RedHat Linux 6.2. Since I was the one who originally ported code, he asked for help. It lloks like problem is in libGLw. It does a core dump. Here is the cut and paste. He and I used widgets-sgi. Any suggestions? Regards Suhaib Your data initialized ok, building X/Motif widgets ... trying to create GlGeomWidgetSB created GlGeomWidgetSB trying to create GlGeomWidgetSB ribbons: GLwDrawA.c:411: createAttribList: Assertion `(ptr-w->glwDrawingArea.attribList)<30' failed. Aborted (core dumped) |
|
From: Howard <ho...@me...> - 2000-05-10 17:28:06
|
Harry Overs wrote: > > My guess is that because you are using geforce mesa is replaced by the UTAH > GLX which is based on SGI's OpenGL ??? > This seems to be the case. It looks like X 4.0 uses the SGI based glX, which therefore excludes the OSMesa functions. We will need a hack in this glX. Brian Paul wrote: > > OS/Mesa is not in XFree86 4.0 in any form. However, this is something > I was thinking about yesterday and I think it would be possible to add > this feature to XFree86's libGL. Basically, I'd provide a new library, > libOSMesa.so which you'd have to link with. It would patch into the > libGL.so dispatcher and work like stand-alone Mesa. > This would be ideal! Otherwise we would need a wrapper around the glX dispatcher that would not be nearly as efficient. > > Also, is there any known reason why glXChooseVisual in XFree86 4.0 Mesa > > would not find an XPixmap with RGB, depth and stencil? > ^^^^^^^ > You mean a GLXVisual, I think. > Yes, right. It turns out that the request is sensitive to the single or double buffer parameter, and it's only available in a double buffer for some reason. > Use glxinfo to list your GLX visuals. You might not have a stencil > buffer, I'd guess. > It seems odd, but apparently our board only has stencils in double buffer mode, according to glxinfo, or the current GeForce drivers only support double buffered stencils. > > We are on a Linux x86 libc6 based system, using a GForce 256 AGP card. > > Using NVIDIA or the UtathGLX drivers? > We are the drivers that are packaged with the current (March) distribution of XFree86 4.0. So I think that means the UtahGLX. -- Howard Luby ho...@me..., Ph:(248)540-2251, Fax:(248)540-3138 Mediascape Corporation http://www.mediascape.com |
|
From: Brian P. <br...@pr...> - 2000-05-10 16:56:14
|
Howard wrote:
>
> Are OSMesaCreateContext, OSMesaDestroyContext and other OSMesa functions
> intentionally excluded from the Mesa version included with XFree86 4.0?
> The offscreen functions in general appear to be missing from XFree86 4.0
> Mesa. Was this a design decision, or is this 4.0 release incomplete?
OS/Mesa is not in XFree86 4.0 in any form. However, this is something
I was thinking about yesterday and I think it would be possible to add
this feature to XFree86's libGL. Basically, I'd provide a new library,
libOSMesa.so which you'd have to link with. It would patch into the
libGL.so dispatcher and work like stand-alone Mesa.
> Also, is there any known reason why glXChooseVisual in XFree86 4.0 Mesa
> would not find an XPixmap with RGB, depth and stencil?
^^^^^^^
You mean a GLXVisual, I think.
Use glxinfo to list your GLX visuals. You might not have a stencil
buffer, I'd guess.
> We are on a Linux x86 libc6 based system, using a GForce 256 AGP card.
Using NVIDIA or the UtathGLX drivers?
In either case, your libGL doesn't have the OS/Mesa functionality.
-Brian
|
|
From: Harry O. <ho...@de...> - 2000-05-10 16:36:02
|
My guess is that because you are using geforce mesa is replaced by the UTAH GLX which is based on SGI's OpenGL ??? So new Mesa extra stuff correct me if i'm wrong ----- Original Message ----- From: "Howard" <ho...@me...> To: "Brian Paul" <br...@pr...> Cc: <MES...@li...>; <MES...@me...>; <XF...@XF...> Sent: Wednesday, May 10, 2000 5:26 PM Subject: [Mesa-dev] OSMesaCreateContext missing in XFree86 4.0 > Are OSMesaCreateContext, OSMesaDestroyContext and other OSMesa functions > intentionally excluded from the Mesa version included with XFree86 4.0? > The offscreen functions in general appear to be missing from XFree86 4.0 > Mesa. Was this a design decision, or is this 4.0 release incomplete? > > Also, is there any known reason why glXChooseVisual in XFree86 4.0 Mesa > would not find an XPixmap with RGB, depth and stencil? > > We are on a Linux x86 libc6 based system, using a GForce 256 AGP card. > > Thanks, > -- > Howard Luby ho...@me..., Ph:(248)540-2251, Fax:(248)540-3138 > Mediascape Corporation http://www.mediascape.com > > > _______________________________________________ > Mesa-dev maillist - Mes...@li... > http://lists.mesa3d.org/mailman/listinfo/mesa-dev |
|
From: Howard <ho...@me...> - 2000-05-10 16:22:32
|
Are OSMesaCreateContext, OSMesaDestroyContext and other OSMesa functions intentionally excluded from the Mesa version included with XFree86 4.0? The offscreen functions in general appear to be missing from XFree86 4.0 Mesa. Was this a design decision, or is this 4.0 release incomplete? Also, is there any known reason why glXChooseVisual in XFree86 4.0 Mesa would not find an XPixmap with RGB, depth and stencil? We are on a Linux x86 libc6 based system, using a GForce 256 AGP card. Thanks, -- Howard Luby ho...@me..., Ph:(248)540-2251, Fax:(248)540-3138 Mediascape Corporation http://www.mediascape.com |
|
From: Keith W. <kei...@ya...> - 2000-05-09 23:13:12
|
--- Brian Paul <br...@pr...> wrote: > "Jacob (=Jouk) Jansen" wrote: > > > > Hi all, > > > > I did not get any answers to my last posts over the last weeks concerning > > an initialization problem on VMS systems and my proposed solution. (the trafic > > on Mesa3d-dev is very low last weeks anyway). So > > -Is nobody (except me) getting my mails from the list? > > -Is nobody reading them? > > -Is nobody sending any answers to the list? > > -Do I have problems getting mails from the list? > > The whole PI team was out of town for a company meeting. It'll be > a few days before I'm caught up on email. I've read your email & will look at it when I get back from holidays (next week). In the meantime I don't have access to a computer to do any real work on. Keith __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ |
|
From: <jo...@du...> - 2000-05-02 14:30:29
|
b_...@gm... wrote on 2-MAY-2000 14:28:36.21 >"Jacob (=Jouk) Jansen" wrote: >> [snip] >-Is anyone besides me got an Alpha ? :> Sure: even one of the major sides for "free" VMS-software http://www2.cenaath.cena.dgac.fr/ftp/index.html picked a version of Mesa from somewhere. I also got some E-mails from people asking questions on the VMS-port of Mesa since they wanted to incorporate it in their projects. And finally comp.os.vms is one of the most frequent used news-groups on a single operating system. >anyway.. i thought memory is cleared when allocated (security). seems not the case on VMS. Maybe it should be checked also on True64(=DigitalUnix/OSF) with the Compaq-DEC C-compiler. >make it an #ifdef VMS and with + instead of - in front of the lines. >shouldnt brake anything, just a slowdown. OK I'll commit it with #ifdef VMS for now. Jouk Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse >------------------------------------------------------------------------------< Jouk Jansen jo...@hr... Technische Universiteit Delft tttttttttt uu uu ddddddd Nationaal centrum voor HREM tttttttttt uu uu dd dd Rotterdamseweg 137 tt uu uu dd dd 2628 AL Delft tt uu uu dd dd Nederland tt uu uu dd dd tel. 31-15-2781536 tt uuuuuuu ddddddd >------------------------------------------------------------------------------< |
|
From: Brian P. <br...@pr...> - 2000-05-02 14:17:10
|
"Jacob (=Jouk) Jansen" wrote: > > Hi all, > > I did not get any answers to my last posts over the last weeks concerning > an initialization problem on VMS systems and my proposed solution. (the trafic > on Mesa3d-dev is very low last weeks anyway). So > -Is nobody (except me) getting my mails from the list? > -Is nobody reading them? > -Is nobody sending any answers to the list? > -Do I have problems getting mails from the list? The whole PI team was out of town for a company meeting. It'll be a few days before I'm caught up on email. -Brian |
|
From: ralf w. <b_...@gm...> - 2000-05-02 12:36:35
|
"Jacob (=Jouk) Jansen" wrote: > > Hi all, > > I did not get any answers to my last posts over the last weeks concerning > an initialization problem on VMS systems and my proposed solution. (the trafic > on Mesa3d-dev is very low last weeks anyway). So > -Is nobody (except me) getting my mails from the list? > -Is nobody reading them? > -Is nobody sending any answers to the list? > -Do I have problems getting mails from the list? > > Jouk -Is anyone besides me got an Alpha ? :> anyway.. i thought memory is cleared when allocated (security). make it an #ifdef VMS and with + instead of - in front of the lines. shouldnt brake anything, just a slowdown. -- ralf willenbacher (bj...@oc...) |
|
From: <jo...@du...> - 2000-05-02 11:04:51
|
Hi all,
I did not get any answers to my last posts over the last weeks concerning
an initialization problem on VMS systems and my proposed solution. (the trafic
on Mesa3d-dev is very low last weeks anyway). So
-Is nobody (except me) getting my mails from the list?
-Is nobody reading them?
-Is nobody sending any answers to the list?
-Do I have problems getting mails from the list?
Jouk
Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse
>------------------------------------------------------------------------------<
Jouk Jansen
jo...@hr...
Technische Universiteit Delft tttttttttt uu uu ddddddd
Nationaal centrum voor HREM tttttttttt uu uu dd dd
Rotterdamseweg 137 tt uu uu dd dd
2628 AL Delft tt uu uu dd dd
Nederland tt uu uu dd dd
tel. 31-15-2781536 tt uuuuuuu ddddddd
>------------------------------------------------------------------------------<
|
|
From: Brian P. <br...@pr...> - 2000-05-02 03:49:44
|
io...@cr... wrote: > > Hi everybody! > > I'm doing this question in this list because nobody else could > answer me in a way I can understand it. Sorry if this is off- > topic, but my project REALLY needs an answer to this question. > Hope you, Brian, or any other GL expert, can finally tell me > about it. > > What happens to a stencil index value in the stencil buffer > when I specify GL_INCR or GL_DECR as the stencil operations > to do with glStencilOp() for any of the stencil tests, if I > call glStencilMask() with a mask value different than all 1's? > Does the stencil index gets just incremented/decremented? Or > the value is gathered, incremented/decremented, and then masked > to be written again to the stencil buffer? The later, I believe. In pseudo-code: Read stencil value, call it v. Apply stencil op to v, such as increment/decrement. Write v to the stencil buffer with write masking. Masking is only applied upon writes. -Brian |
|
From: <io...@cr...> - 2000-05-02 03:37:12
|
>> >> Hi everybody! >> >> I'm doing this question in this list because nobody else could >> answer me in a way I can understand it. Sorry if this is off- >> topic, but my project REALLY needs an answer to this question. >> Hope you, Brian, or any other GL expert, can finally tell me >> about it. >> >> What happens to a stencil index value in the stencil buffer >> when I specify GL_INCR or GL_DECR as the stencil operations >> to do with glStencilOp() for any of the stencil tests, if I >> call glStencilMask() with a mask value different than all 1's? >> Does the stencil index gets just incremented/decremented? Or >> the value is gathered, incremented/decremented, and then masked >> to be written again to the stencil buffer? > >The later, I believe. In pseudo-code: > > Read stencil value, call it v. > Apply stencil op to v, such as increment/decrement. > Write v to the stencil buffer with write masking. > >Masking is only applied upon writes. > >-Brian Thanks for your quick response! Ok... then, in the example, since the mask is 0xFFEA and the original value is 0x003E, the stencil value will be probably unaffected by the operation, and thus never incremented, right? Well, I think this means "back to the blueprints" for me, but well... thanks anyway! - Heriberto Delgado (io...@cr..., her...@su...) |
|
From: <io...@cr...> - 2000-05-02 02:16:39
|
Hi everybody! I'm doing this question in this list because nobody else could answer me in a way I can understand it. Sorry if this is off- topic, but my project REALLY needs an answer to this question. Hope you, Brian, or any other GL expert, can finally tell me about it. What happens to a stencil index value in the stencil buffer when I specify GL_INCR or GL_DECR as the stencil operations to do with glStencilOp() for any of the stencil tests, if I call glStencilMask() with a mask value different than all 1's? Does the stencil index gets just incremented/decremented? Or the value is gathered, incremented/decremented, and then masked to be written again to the stencil buffer? An example: A fragment at (xw = 50, yw = 50) is about to be renderized at the framebuffer. The 16-bit stencil buffer value at (50,50) is 0x003E. The GL is told to GL_INCR the stencil values when the depth test fails. Additionally, glStencilMask(0xFFEA) was called. The depth test fails for the fragment at (50,50). What will be the new value of the stencil buffer at (50,50) (assuming there are no more operations applied to the stencil buffer)? The OpenGL specification is not very clear, at least for me, on this subject, so I hope anyone of you can answer me that. Thanks in advance. - Heriberto Delgado (io...@cr..., her...@su...) |
|
From: <jo...@du...> - 2000-04-28 13:25:36
|
Hi All,
I finally found the problem on my VMS/Alpha system when running some of
the modes of xlockmore. It appered that the Normal field of the Immediate IM
in VB.C contained rubish after allocation of the immediate. I propose the
following patch to vb.c (Not yet committed since I want your comments first)
*** vb.c;2 Fri Apr 28 16:06:10 2000
--- vb.c;1 Fri Apr 14 07:43:16 2000
***************
*** 272,279 ****
IM->Start = VB_START;
IM->Material = 0;
IM->MaterialMask = 0;
- for (j=0; j<VB_SIZE ; j++ )
- IM->Normal[j][0] = IM->Normal[j][1] = IM->Normal[j][2] = 0.0;
if (MESA_VERBOSE&VERBOSE_IMMEDIATE)
fprintf(stderr, "alloc immediate %d\n", id);
--- 272,277 ----
Maybe the same problem occurs on True64(DECUnix/OSF) on Alpha. Since in
principle the same compiler (but for another OS) is used.
Questions:
-Should I commit this fix for all systems or should I #ifdef VMS it?
-What about the other data-fields in the Immediate. Can they be corrupt too?
Jouk
Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse
>------------------------------------------------------------------------------<
Jouk Jansen
jo...@hr...
Technische Universiteit Delft tttttttttt uu uu ddddddd
Nationaal centrum voor HREM tttttttttt uu uu dd dd
Rotterdamseweg 137 tt uu uu dd dd
2628 AL Delft tt uu uu dd dd
Nederland tt uu uu dd dd
tel. 31-15-2781536 tt uuuuuuu ddddddd
>------------------------------------------------------------------------------<
|
|
From: physic <ph...@te...> - 2000-04-26 16:38:36
|
In that case, you probably want non anonymous access but you didnt get a sourceforge account and submit you name to brian when he moved it. He sent you the email last week or so. Just drop him a line and he'll set you up after he gets back grom the PI meeting next week. On Thu, 27 Apr 2000, Stephen Hocking wrote: > > its moved to cvs.mesa3d.sourceforge.net:/cvsroot/mesa3d > > > > as noted on the webpage > > > Yup - tried that as well, and other sourceforge cvs archives don't seem to > object to me. > > > Stephen > -- > The views expressed above are not those of PGS Tensor. > > "We've heard that a million monkeys at a million keyboards could produce > the Complete Works of Shakespeare; now, thanks to the Internet, we know > this is not true." Robert Wilensky, University of California > > --physic ph...@te... |
|
From: Stephen H. <sho...@pr...> - 2000-04-26 16:37:48
|
> its moved to cvs.mesa3d.sourceforge.net:/cvsroot/mesa3d > > as noted on the webpage > Aaack - was old CVS/ pollution. Thanks anyway. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California |
|
From: Stephen H. <sho...@pr...> - 2000-04-26 16:34:28
|
> its moved to cvs.mesa3d.sourceforge.net:/cvsroot/mesa3d > > as noted on the webpage > Yup - tried that as well, and other sourceforge cvs archives don't seem to object to me. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California |
|
From: physic <ph...@te...> - 2000-04-26 16:30:14
|
its moved to cvs.mesa3d.sourceforge.net:/cvsroot/mesa3d as noted on the webpage On Thu, 27 Apr 2000, Stephen Hocking wrote: > When trying to get an update from cvs.mesa3d.org, I keep on getting a > "connection refused" message - has the CVS archive moved? > > > Stephen > -- > The views expressed above are not those of PGS Tensor. > > "We've heard that a million monkeys at a million keyboards could produce > the Complete Works of Shakespeare; now, thanks to the Internet, we know > this is not true." Robert Wilensky, University of California > > > > _______________________________________________ > Mesa3d-dev mailing list > Mes...@li... > http://lists.sourceforge.net/mailman/listinfo/mesa3d-dev > --physic ph...@te... |
102 messages has been excluded from this view by a project administrator.
