[GEM-dev] CVS: checkins and notifications

[IOhannes m zmoelnig]

James Tittle II wrote:
> On Aug 17, 2004, at 10:08 AM, IOhannes m zmoelnig wrote:

>> 1x) *stupidity*: while branching seems simple, i have experienced that 
>> it is a bit beyond my reach. i have done a lot of really stupid 
>> things, namely:
> 
> 
> ...this is what I'm afraid of:  many different versions going out in 
> different directions, each with some small "stupidity" mistake, making 
> for a fool's errand to find out if it's even worthwhile...

> ...I'm sure we're all going to make mistakes for awhile...

absolutely.
but what i can i do know ?
the biggest problem with me using the CVS is, that i need it not only 
for sharing code with other people (e.g.: you) but also to have a 
code-base that i can work on from several machines under several 
operating systems both at work and at home.
this is why i tend to check in things that are not running at all.


>> 1a) "SIMD":
>>     i have tested it under linux and windows and it works (although i 
>> SSE2 machine at hand so i haven't tried this yet); however, i have not 
>> tried to compile it under osX yet.

> ...why would you try to compile it under OSX?  Are you writing altivec? 
no i am not writing altivec.
however, the altivec functions were not named uniformly and me (in my 
"facist" way of thinking) have just changed this.
and i have thought that each and every change to the code-base - no 
matter how well tested on one platform - *might* break compilation on 
another system.

>  What is it a branch of?
v0.90 (if this answers your question)
for now i have branched (at least) the whole Gem/src folder.

> 
>> 1b) "multiple_window": (there is also a TAG with this name, so beware!)
> 
> ...this sounds vaguely interesting, but I have no way of testing against 
> multiple video cards (I just have a laptop)...again, what is this a 
> branch off of?  
again v0.90; everything is branched

the point is not necessarily about having multiple video-cards in one 
machine. i have neither (and if i would this won't matter to me as
	a] X could create one big desktop; and
	b] i can already do rendering to remote Xs for a while (this is: run 2 
machines with X and do the Gem-output on one machine; or run 2 X servers 
on one machine and re-direct the rendering from the "patching" X to the 
other one))

while i don't think that their are similar mechanisms like X-forwarding 
on osX and win23 (as long as you don't run X of course), i think that 
spanning across multiple gfx-cards should not be an issue today. (ok, i 
have never actually used this...)

Does it seem to have conflicts with the vertex array
no, why should it ?

> stuff?  I'm also working on changing rendering in GemMan, but my 
> solution is not necessarily just to move it to a new object...

so why do i think we need multiple windows ? people keep bothering me 
with feature-requests like "i have a dual-head gfx-card and want to do a 
performance; the second head goes to the video-beam while i am 
controlling on the first head. unfortunately i cannot see the beam from 
where i am and they have no video-splitter for me to monitor what i am 
actually producing. wouldn't it be possible to display the "output" on a 
small monitoring window ?

the other thing is, that we (the iem) are currently working on a 
pd-plugin for webbrowsers. it is important (for whatever reasons) that 
Gem is included and that rendering is done to an "embedded window" (e.g. 
like with movie-player-plugins the rendering-window should be bound to 
the browser (scrollable and everything) and not pop-up "somewhere" on 
the desktop and vanish behind other windows as soon as i change some 
parameters on the plugin-GUI in the browser)

there *is* a lot of code in GemMan that is specific to the operating 
systems window handling, and even worse, there is code in there that 
depends on certain graphics-servers.

furthermore, a lot of code in GemMan is declared "static" (like the 
viewpoint).
now *if* i want the ability to render to several independent windows, 
then i also want to be able to set different viewpoints for each window.
or lighting, or background-color, or dimensions, or whatever...

how are we supposed to ever drive a cave with Gem otherwise.

> ...have no idea what an /src/Output directory would be good 
on the long run i would like to remove the dependency on X from Gem. 
(e.g. if only output to an aa-terminal is needed).
then there might be output-modules that only make sense for a special 
hardware. i have thought to isolate such objects and make them as 
externals to Gem.


> ...are we going to be auto-subscribed like last time?  I'm interested in 
> staying abreast of commits...
even i am able to learn.
nobody will be subscribed automatically.

> manage this?  Check out multiple copies of Gem, each with it's own 
> branch/tag/whatever?
hmm. supposed your local copy is up-to-date.
then you could just update your whole source-tree to the tip of a 
certain branch; that's it. you are there. edit. commit. then update to 
another branch. edit. commit. then go back to HEAD. and so on.
the only problem arise, when your local copies are modified and you 
don't want to check them in.

mfg.a.sdr
IOhannes