| | Logging Started : Sun May 17 12:21:32 EDT 1998 |
|
Jordy:
|
oh
|
|
Jordy:
|
hey
|
|
graydon:
|
heya. Just waiting around..
|
|
graydon:
|
I'm compiling a new IRC client in the background..
|
|
Jordy:
|
i'm listening to that heresy project report
|
|
graydon:
|
what is that?
|
|
Jordy:
|
c|net trial of linux
|
|
Jordy:
|
for a month
|
|
graydon:
|
which distro are they using?
|
|
Jordy:
|
redhat and caldera
|
|
Jordy:
|
sorta interesting listening to problems they have :)
|
|
Jordy:
|
http://www.news.com/Radio/Features/0,155,205,0.html
|
|
Jordy:
|
16:00?
|
|
Jordy:
|
i thought it was 18:00
|
| | graydon has set the topic: "Berlin development meeting starting at 18:00 today" |
| | graydon has set the topic: Berlin development meeting starting at 18:00 today |
|
graydon:
|
eep
|
|
Jordy:
|
fixed a few problems in that source tree.. sorta forgot to remove some stuff which i had when I made stubs directories
|
|
Jordy:
|
should actually build now :)
|
|
graydon:
|
ok. You're editing the tree in CVS right?
|
|
Jordy:
|
those pdf documents you added to the source tree are huge :)
|
|
Jordy:
|
yeah, just committed it
|
|
Jordy:
|
last night, when you were adding those pdf docs
|
|
graydon:
|
yeah, I know. I was thinking maybe I shouldn't, but then it seems like everyone needs 'em anyway.
|
|
graydon:
|
Maybe I'll make a separate module, so you can ignore 'em at your leisure..
|
|
Jordy:
|
doesn't really bother me... just the people who have a little slower modems
|
|
Jordy:
|
what's this whole cos directory..
|
|
Jordy:
|
looks like program management, execution, destruction, etc
|
|
graydon:
|
cos is corba-services. They're standardized interfaces for doing things that everyone does with distributed objects, so that everyone's implementations can interoperate.
|
|
Jordy:
|
mmm, ok
|
|
graydon:
|
so I am starting to shift our system to use them in places where it's appropriate. Like -- cloneable is much better done as lifeCycleObject, and obtain<> is much better done as genericFactory.
|
|
graydon:
|
It's more verbose, but at least it's a standard.
|
|
graydon:
|
besides, in many cases the corba design is a lot more flexible than ours. They have more brains.
|
| | graydon ;) |
|
Jordy:
|
haha, ok then...
|
|
graydon:
|
blast! I wish gnome would make up their mind where they put things...
|
|
Jordy:
|
my copy still won't run correctly... i should double-check that I compiled everything berlin links against w/ _REENTRANT
|
|
graydon:
|
how do you mean "not correctly"? What kind of error?
|
|
Jordy:
|
it cores.. brings up a window in X... then disapears :)
|
|
graydon:
|
what bpp are you running X in?
|
|
Jordy:
|
i forgot the error exactly
|
|
Jordy:
|
1152x864@16bpp
|
|
graydon:
|
that's why. ggi 0.0.9 considers "default" == "8bpp" and cores in any other depth.
|
| | graydon sighs |
|
Jordy:
|
oh geez
|
|
graydon:
|
it might be something else though. Are you running name service?
|
|
Jordy:
|
of course :)
|
|
graydon:
|
got "export WARSAW=`pwd`" done?
|
|
Jordy:
|
yeah, we should fix that :)
|
|
graydon:
|
yeah I know
|
|
graydon:
|
heh
|
|
Jordy:
|
since I actually have the root path in the make config script
|
|
graydon:
|
I implemented genericFactory last night to do widget loading on demand instead of all at startup.
|
|
graydon:
|
Hope to have it debugged in a few days.
|
|
Jordy:
|
we might actually want to start using the registry
|
|
graydon:
|
yeah
|
|
Jordy:
|
for plugin paths and what not
|
|
graydon:
|
yeah that would be keen. Also, notice in the corba docs there is an exernalization standard as well as a "properties" standard.
|
|
Jordy:
|
that way we can have directories for company names.. clean up namespace a bit... it will get cluttered :)
|
|
Jordy:
|
i did read about that, sort of an introspection thing...
|
|
Jordy:
|
question, when berlin actually runs
|
|
graydon:
|
Partly. Part of that is interface Repo, which is in a HUGE 9 meg pdf I didn't put in cvs.
|
|
Jordy:
|
what is it supposed to do? :)
|
|
graydon:
|
if you're lucky, right now, it'll open up a window and then sit there. There are no widgets. It's waiting for things to do...
|
|
Jordy:
|
i've gotten past all the loading of plugins and init of ggi and what not... just it's always cored when ggi runs :)
|
|
graydon:
|
yeah, the core dump is unfavourable. It's supposed to sit there. A grand accomplishment.
|
| | graydon grins |
|
Jordy:
|
what is the plan, to corba'ize some 2d and 3d routines
|
|
graydon:
|
We gotta write some stupid looking widgets just to make sure it works
|
|
Jordy:
|
or something a bit higher-level
|
|
Jordy:
|
yeah, i can make a button, bout the easiest widget to make :)
|
|
graydon:
|
and then, yeah, export everything from the low level to the very-high-level.
|
|
Jordy:
|
a gray box... not hard :)
|
|
graydon:
|
yeah
|
|
graydon:
|
I'm hoping my new book on postscript will be here by then, and we can make sure there's nothing important left out of the interfaces.
|
|
Jordy:
|
I'd like to move any header files which will be used in other apps to the top level include, since I'm just going to cp -R that to /usr/Berlin/include
|
|
graydon:
|
I got all of fresco yesterday
|
|
graydon:
|
oh, yeah, by all means. I was wondering if the plan to isolate the idl was still real
|
|
Jordy:
|
-rw------- 1 jordy admin 1985294 May 15 11:12 Fresco-980515.tar.gz
|
|
Jordy:
|
that one?
|
|
graydon:
|
mm.. maybe.. lemme see
|
|
Jordy:
|
i was going to isolate the idl, but it turned out to be a bit harder than I thought :)
|
|
graydon:
|
yeah
|
|
graydon:
|
it's slow, but kinda cool
|
|
graydon:
|
you can do nifty things like run the graphics editor recursively.
|
|
graydon:
|
But it's got lots of stable code we can rip off.
|
|
Jordy:
|
I haven't tried it, read about it a while back though
|
|
Jordy:
|
it's all GPL'ed?
|
|
graydon:
|
it's under a "released from research department of big companies" kinda license. It looks to me like it's free, you just have to put their name at the top of the source fiels and promise not to say theie companies are responsible.
|
|
graydon:
|
s/theie/their/
|
|
Jordy:
|
oi, i hate BSD style licenses for that.. clutter the poor source :)
|
|
Jordy:
|
I need to get a syntax highlighting editor which understands IDL
|
| | graydon has set the topic: "Berlin development meeting starting at 18:00 (gmt) today" |
| | graydon has set the topic: Berlin development meeting starting at 18:00 (gmt) today |
|
graydon:
|
mm. you can throw emacs into cc mode and it's pretty close. There's an idl mode floating around but I don't have it.
|
|
Jordy:
|
what are we doing for a string class
|
|
Jordy:
|
i saw some of the unistr stuff you had in text/
|
|
Jordy:
|
we still have the unicode lib from the old source tree.. it works fairly well
|
|
graydon:
|
there's 2 parts to that. There's strings and glyphs themselves, and there's buffers / editor classes
|
|
Jordy:
|
right... but I'm talking more about when we pass strings around applications
|
|
graydon:
|
the buffer class I think anoq is writing.
|
|
graydon:
|
strings are either 16 or 32 bit wide integer sequences. I just put a corba wrapper on them..
|
| | anoq (root@msx-0b-1-18.1033.cybercity.dk) has joined channel #berlin |
|
Jordy:
|
ahh
|
|
anoq:
|
hey Graydon, Jordan - is that you?
|
|
Jordy:
|
we need a way toa ccess the registrar... what do you suggest...
|
|
graydon:
|
yeah. Hey anoq
|
|
anoq:
|
Testing nickname...
|
|
anoq:
|
Do I have a nickname?
|
|
graydon:
|
jordy. I was thinking it's be *real* snazzy if someone opened up the omniNames service and hacked the registrar on the side, so you are just talking about persistent corba names.. that's the simplest I can think of.
|
|
Jordy:
|
ircing as root == bad :)
|
|
Jordy:
|
gray: i was thinking the same thing, because CORBA already has that interface
|
|
graydon:
|
yeah, and omniNames is actually a lousy implementation omho.
|
|
graydon:
|
s/omho/imho/
|
| | groby (gorby@dslip05.canit.se) has joined channel #berlin |
|
Jordy:
|
then we need to start distributing our own OmniNames :)
|
|
graydon:
|
we'll need a small curses client too, in case your video card craps out and you need to edit the registry.
|
| | jones (jones@130.228.228.34) has joined channel #berlin |
|
graydon:
|
jordy: omni is GPL. why not?
|
|
jones:
|
hi all, anoq you made it!
|
|
graydon:
|
hey cool, everyone's an hour early ;) or did I calculate my local clock wrong?
|
|
Jordy:
|
no, it's 1800 GMT now :0
|
|
Jordy:
|
Sun May 17 13:06:04 EDT 1998
|
|
anoq:
|
yup! Just got ircII up and running a few minutes ago...
|
|
Jordy:
|
i'm in GMT-5
|
|
graydon:
|
heh. Ok. score one for linux locales. My machine translates me to GMT-4, but it's 13:06 for me too..
|
|
anoq:
|
Time is 7pm here as planned...
|
|
jones:
|
anoq: ok, I was testing an account on another machine for you, no need for that now. I'll be right back
|
| | Signoff: jones (Leaving) |
|
graydon:
|
oop. no, just my machine at work. Debian gets it right.
|
|
Jordy:
|
alrighty, so where do we start.
|
| | jones_ (jones@pm21-59.image.dk) has joined channel #berlin |
|
Jordy:
|
mmm, i'm the only one with uppercase
|
| | Jordy is now known as jordy |
|
jones_:
|
ok, back
|
| | jones_ is now known as jonas |
|
graydon:
|
ok then I guess we'll get started?
|
|
anoq:
|
go ahead...
|
|
jonas:
|
is anyone logging?
|
|
graydon:
|
The agenda I'm suggesting for today is as follows:
|
|
graydon:
|
(and I'm already logging)
|
|
graydon:
|
1. exceptions
|
|
graydon:
|
2. text layout, especially the recently released libGFH
|
|
graydon:
|
3. double buffering, backing store, and incrimental redisplay
|
|
graydon:
|
4. shared video buffers
|
|
graydon:
|
5. sound
|
|
graydon:
|
6. security
|
|
graydon:
|
7. sessions / contracts / pinging, whatever is needed to identify
|
|
graydon:
|
and recover from network failure or failure of a remote host.
|
|
graydon:
|
8. metrics, paths and geometry abstractions
|
|
graydon:
|
9. deploying "developer" services, like notices of cvs commits and
|
|
graydon:
|
rpms / debs of required software
|
|
graydon:
|
10. integration with Corba Services (if we have time)
|
|
graydon:
|
except I think the order is all screwed up. But those are the issues.
|
|
anoq:
|
where do we start?
|
| | graydon has set the topic: "berlin: administrivia" |
| | graydon has set the topic: berlin: administrivia |
|
jordy:
|
let's head out with exceptions, what exactly is the issue?
|
|
graydon:
|
First of all, has everyone got the new cvs tree?
|
|
jonas:
|
in two secs... :)
|
|
jordy:
|
i should probably be in linux, i'll be back in about, 10 seconds :)
|
|
graydon:
|
nothing much changed, I just want to make sure we're all talking about the same sources
|
|
anoq:
|
Yes - got the CVS, and it looks really good!
|
|
graydon:
|
exceptions and debugging
|
| | graydon has set the topic: "berlin: exceptions and debugging" |
| | graydon has set the topic: berlin: exceptions and debugging |
| | graydon has set the topic: "berlin: exceptions and debugging" |
| | graydon has set the topic: berlin: exceptions and debugging |
|
graydon:
|
I've added a small new class called "debug" which I've put some enumerated categories in
|
|
graydon:
|
it contains a simple debugging-logger. If we all use this instead of cerr, you'll be able to selectively see groups of logically related debugging messages.
|
|
graydon:
|
or compile the behaviour out in a production version
|
|
jordy:
|
there we go :)
|
|
graydon:
|
anyone have a problem with that? We did it at work and it's very handy.
|
|
jordy:
|
mmmm, seems fine to me, what kind of information does it give?
|
|
anoq:
|
I am looking at it now... seems OK
|
|
graydon:
|
jordy: nothing now, it's just a wrapper for cerr. It can do something more advanced in the future maybe
|
|
jonas:
|
ehh, graydon did you put the COSS document in the cvs?!! The 8 megs??
|
|
jordy:
|
looks fine
|
|
graydon:
|
not the whole thing. I left out a couple chapters. I understand it's too big, I'll move it to a new module so you don't have to check it out.
|
|
jonas:
|
graydon: ok, fine
|
| | ixx (ixx@pm3-1-084.lub.arn.net) has joined channel #berlin |
|
graydon:
|
ok. Next then I wanted to make sure everyone knows that corba *has* an exception mechanism, meaning that interfaces can throw exceptions.
|
| | Signoff: ixx (Read error to ixx[pm3-1-084.lub.arn.net]: EOF from client) |
|
graydon:
|
across a network boundary
|
|
jonas:
|
maybe just link from the webpages? anyway offtopic right now
|
|
graydon:
|
that's important, because exceptions are a very good way of handling strange conditions and controlling failures.
|
|
graydon:
|
core-dumping is not really what we're looking for.
|
|
anoq:
|
I think we should have a seperate file for defining berlin-exceptions
|
| | ixx (ixx@pm3-1-084.lub.arn.net) has joined channel #berlin |
|
graydon:
|
anoq: exceptions can be derived from one another, so there should be some intentional design to how they work, yes
|
|
jonas:
|
exceptions are defined in each IDL file, righ?
|
|
anoq:
|
For my string-objects I need (at least) rangeCheckError, textFormatError
|
|
graydon:
|
there are 2 kinds: IDL exceptions and C++ implementation exceptions. We use both.
|
|
anoq:
|
notEnoughMemoryError would also be _very_ handy
|
|
ixx:
|
hello
|
|
jordy:
|
OutOfMemory sounds good
|
|
graydon:
|
IDL exceptions get compiled to C++ exceptions
|
|
jordy:
|
what does new throw when we run out of ram?
|
|
graydon:
|
ixx hi
|
|
anoq:
|
ixx: who are you?
|
|
graydon:
|
jordy: there are a large number of "standard" corba exceptions, which cover the cases mentionned here so far and much more.
|
|
jordy:
|
i'm not used to exceptions under C++, only Java... they look the same
|
|
anoq:
|
jordy: I hope it throws an exception, but not sure...
|
|
smkl:
|
jordy: i guess it just returns 0
|
|
jordy:
|
the only real difference looks to be the catch (...) fallthrough
|
|
graydon:
|
The specs in the "doc" directory outline them.
|
|
ixx:
|
ummm i am taylorcc@arn.net or zeus@tomserver.phys.ttu.edu
|
|
ixx:
|
brb
|
|
graydon:
|
C++ lets you throw anything you like, since it's not a pure O-O language, but normally your exceptions are classes just like java.
|
|
graydon:
|
Also the throw/catch contract is optional -- generates a warning. Unlike java.
|
|
jordy:
|
gotcha...
|
|
graydon:
|
But please, if you know something can throw, obey the warning!
|
|
anoq:
|
Can IDL exceptions be subclassed as in C++?
|
|
jordy:
|
what happens when something throws an exception and it's not caught under C++?
|
|
graydon:
|
anoq: good question. afaik yes but that's just cause it would be stupid otherwise. Not sure.
|
|
anoq:
|
jordy: the app exits...
|
|
graydon:
|
jordy: if it was declared in IDL, it'll propagate through the ORB to the caller, who has the option to catch it there.
|
|
jordy:
|
ooo, that's clean
|
|
graydon:
|
jordy: otherwise the runtime cals abort();
|
|
graydon:
|
abort is less clean.
|
|
jordy:
|
alright... just curious...
|
|
anoq:
|
OK... I was thinking C++ without CORBA... sorry
|
|
graydon:
|
Ok, so the procedure here is, if you're writing a new interface, to declare a new exception if you think it's a special kind, or to declare that your interface throws one of the common corba exceptions if you expect it might.
|
|
jonas:
|
should we not use a special throw, not C++ throw, but a ORB method for throwing, while catching is standard?
|
|
graydon:
|
For instance, out of memory is a corba exception. So is range-error.
|
| | jones (jones@pm21-59.image.dk) has joined channel #berlin |
| | jonas has left channel #berlin |
| | jones is now known as jonas |
|
graydon:
|
jones: no, the orb puts an exception handler in place during the upcall for any IDL-generated exceptions. You do a C++ throw, the C++ ORB which called up catches and returns.
|
|
jordy:
|
can we define a standard way to catch exceptions for things like range-error? So in the future everything generates the same standard looking error message instead of each class having to do it?
|
|
anoq:
|
I could subclass range-error to textRangeError, if possible...
|
|
ixx:
|
anoq, i sent u an email several weeks ago about NSXKit
|
|
graydon:
|
jordy: yeah. I'd like a message catalogue ideally.
|
|
jordy:
|
DisplayException(ExceptionType) sort of thing
|
|
anoq:
|
ixx: I don't think I recieved it then... mail me again...
|
|
graydon:
|
jordy: yeah, it can even go in the debug class, for that matter ;)
|
|
graydon:
|
jordy: use a hugely polymorphic virtual method.
|
|
jordy:
|
hahah.. that would be interesting to say the least
|
|
ixx:
|
anoq, it seems noone is working on it anymore.... that would be nice to have on berlin.... or libGWT
|
|
anoq:
|
jordy and graydon: Sounds good... this is how Delpi does it
|
|
jonas:
|
ixx: what would you like to have in LibGWT?
|
|
graydon:
|
OK. so the other issue is that I want to make sure everyone's been thuroughly lectured on the fact that you don't *have* to catch exceptions at a local level. If there are multiple logically sound ways of handling the problem you'd best leave it up to the caller and just rethrow.
|
|
anoq:
|
ixx: NSXKit is the OpenStep API implemented in XLib. It was meant to be ported as NSXKit backend, so that it's just an XLib backend for GNUStep
|
|
ixx:
|
jonas, i would like the back-end for gnustep-gui to be ported to libGWT
|
| | graydon temporarily becomes a rabid OO-design zealot |
|
jordy:
|
right, we want to delegate the responsibility to the developer's application if possible... since a lot of the time it's their fault :)
|
|
anoq:
|
ixx: We could make a berlin-backend for GNUStep...
|
| | graydon goes back to normal |
|
ixx:
|
anoq, yes it would be nice to have a backend on berlin or libgwt
|
|
jordy:
|
alrighty, i think we've beaten exceptions to death
|
| | graydon has set the topic: "berlin: text layout, especially the recently released libGFH " |
| | graydon has set the topic: berlin: text layout, especially the recently released libGFH |
|
jordy:
|
i say we steal the layout code from netscape :)
|
|
anoq:
|
ixx: Can we discuss GNUStep/NSXKit later?
|
|
graydon:
|
I spent a *long* time this week nattering with a guy at work who is an insane sypography fan, the results of which are now in cvs under /src/berlin/text
|
|
graydon:
|
s/sypography/typography/
|
|
ixx:
|
anoq, yes sorry
|
|
jordy:
|
i read a bit of it
|
|
jonas:
|
are there any reasons for not using libGFH?
|
|
anoq:
|
graydon: the stuff in text looks really good too!
|
|
graydon:
|
It's a little convoluted and I want to make sure people (a) like it, (b) know how it works
|
|
graydon:
|
jonas: oh, we will be using libgfh. I have also been talking to andrew about it (the guy who wrote libgfh)
|
|
jordy:
|
ok, you have three peices it looks like, the font, the glyph and the string
|
|
graydon:
|
It's just that libgfh only handles fonts.
|
|
jordy:
|
you feed the string into the font which gives us a glyph? :)
|
|
graydon:
|
jordy: close. You feel the string through a mapper which makes a glyph sequence. Glyphs are abstract. You feel the glyph through a font mapper and a font cascade, and get a little picture, which you then cache and display.
|
|
graydon:
|
s/feel/feed/
|
| | graydon can't type today |
|
jordy:
|
ok, i've heard about different methods of caching on a character by character basis, or a word by word basis
|
|
graydon:
|
The reason for having a middle level of abstract glyph is that every font indexes using different names of glyphs
|
|
jordy:
|
if we have the word 'the' 5 times, we don't need to feed it through the font mapper 5 times do we?
|
|
anoq:
|
how about support for different colours of font? It doen't seem to support that - or is that just current fg+bg color?
|
|
graydon:
|
jordy: I'm thinking we're doing charcter-by-character caching. You go through the mapper 3 times for the first "the" and then just hit the cache thereafter.
|
| | jonas is amazed by the new repo layout, well done! |
|
jordy:
|
anoq: oh geez... let's stick with b&w for now :)
|
|
graydon:
|
mm. we have to keep color text in mind
|
|
jordy:
|
well, ok
|
|
jordy:
|
let's do it the XML way then
|
|
anoq:
|
current fg+bg would be good... perhaps globally
|
|
jordy:
|
break the document's text away from the document's format
|
|
jonas:
|
I don't think colors are the worst part, probably easy to do, but more about Unicode support and antialiasing
|
|
anoq:
|
jordy: What's XML?
|
|
graydon:
|
we also have to keep in mind a nasty side effect of kerning and subpixel spacing, which is that you need to keep as many cached images as you have grey levels in your anti-aliasing routine, unless you do anti-aliasing after positioning on the screen.
|
|
jordy:
|
XML is a replacement for HTML, you have the text string as one peice, and then you have it's formatting (color, etc) as another peice
|
|
jordy:
|
i'm not saying implement an XML parser.. but more on the lines of, let's render the text first
|
|
jordy:
|
apply the color second
|
|
graydon:
|
jordy: yeah. XML / XSL will likely play a big role in our formatting model
|
|
graydon:
|
jordy: and I totally agree with color being separated
|
|
jordy:
|
gray: yeah..
|
|
jordy:
|
technically it'd be easier to just corba'ize mozilla :)
|
|
jordy:
|
i mean, it has everything we want right?
|
|
graydon:
|
cause otherwise we have to store a separate cache image for each transparency and color combination. Our cache would crash the computer.
|
|
anoq:
|
jordy: less flexible though..
|
|
jordy:
|
it can layout graphics, text, etc
|
|
graydon:
|
jordy: may well do that
|
|
jordy:
|
Mozilla does have an XML parser too
|
|
jordy:
|
it just needs the XSL parser...
|
|
graydon:
|
they have james clar's XML parser. It's freely available, separately.
|
|
jordy:
|
yep...
|
|
jordy:
|
if anyone here has looked at the mozilla source, it's broken down into nice corbafiable peices, the layout engine, the parsers, everything :)
|
|
graydon:
|
jordy: they can already do somepretty advanced stuff. A guy from work was at their conference and they showed stylized XML pages (using CSS1, mind you)
|
|
jordy:
|
hmmmm
|
|
ixx:
|
there will be a new layout engine in the next release though
|
|
jordy:
|
ixx: yeah, raptor.. i've used it
|
|
jordy:
|
it's blindingly fast
|
|
graydon:
|
yeah. I'd like to see raptor.
|
|
anoq:
|
graydon, jordy: We could use code from mozilla, but how about my string APIs?
|
|
graydon:
|
anoq: hrm, it's been a while sorry. Lemme look again.
|
|
jordy:
|
anoq: i don't see it interfering at all
|
|
anoq:
|
Users has to be able to edit the text...
|
|
ixx:
|
off to lunch
|
| | Signoff: ixx (BitchX: the ONLY bug-free client (yeah right).) |
|
graydon:
|
yeah, it looks good.
|
|
jordy:
|
ok... we have a user with a text box open
|
|
jordy:
|
the user types, letters appear
|
| | Signoff: groby (cIRCus 0.43 - http://www.nijenrode.nl/~ivo/circus/) |
|
anoq:
|
graydon: I just enhanced it today, making it even better - not committed to CVS yet..
|
|
graydon:
|
As for rendering glyphs, the suggestion I got was that when an edit takes place, you should run the word beign edited through your mappers again to re-compose combining characters and ligatures and stuff.
|
|
graydon:
|
anoq: you can get a nice fast implementation of a small buffer-gap string editor from libgtk. It's exactly what we should be aiming for.
|
|
graydon:
|
anoq: unless you want to try to extract it from vim or xemacs ;)
|
|
anoq:
|
graydon: I'll have a look... I am still aiming at multi-client text-editing though...
|
|
graydon:
|
that's ok, you can lock down the object during an edit. I have no problem with that.
|
|
jordy:
|
the only problems i see happening are when we render text... that whole left->right right->left thing with different languages still confuses me :)
|
|
anoq:
|
graydon: multi-client displays too...
|
|
graydon:
|
jordy: there's a complete bi-directionality algorithm in the unicode book. I'll implement it if nobody else has the code or the book..
|
|
jordy:
|
that'll work
|
|
graydon:
|
anoq: you might want to look at subj-observer in cvs.
|
|
anoq:
|
graydon: did so, and I intend to use it for the string stuff too...
|
|
graydon:
|
anoq: I put in an "auto-update" method you can flip to turn off updating of an observer during a bulk edit.
|
|
anoq:
|
graydon: cool!
|
|
graydon:
|
ok..
|
|
graydon:
|
we done with text?
|
|
jordy:
|
alright, that'll work.. we can worry about the higher-end stuff of rendering graphics & text together when we are farther along
|
|
graydon:
|
yeah, and we're gonna look at raptor for that too
|
|
jordy:
|
yeah, i'd say so graydon
|
| | graydon has set the topic: "berlin: double buffering, backing store, and incrimental redisplay" |
| | graydon has set the topic: berlin: double buffering, backing store, and incrimental redisplay |
|
jonas:
|
regarding backing store I'm planning on making it much like X in libGWT
|
|
graydon:
|
ok, I"ve been reading up on how the kernel maps memory around, and it is possible to mmap() video memory any old place we like, including into the client's address space (if they're local)
|
|
graydon:
|
but that's skipping ahead to the next issue a little. they're related.
|
|
graydon:
|
Any buffers we have will be in one of four places. Video memory held by the server, video memory held by the client, system memory by the server, and system memory by the client.
|
|
graydon:
|
the question is how to minimize copying
|
|
graydon:
|
while letting the client get whatever they want accomplished
|
|
jordy:
|
well
|
|
jonas:
|
Do we really need direct access to video mem from Berlin? I mean we have ggi libraries for that, right?
|
|
graydon:
|
jonas: yes, directbuffer will be the mechanism because it chields us from byte ordering or memory layout.
|
|
graydon:
|
that's part of libggi
|
|
graydon:
|
s/chields/shields/
|
|
jonas:
|
yes, but with libgwt for window management, libgfh for fonts, and all those other libs, should we not "just" use them?
|
|
graydon:
|
jonas: this is very related to the progress you're making with gwt..
|
|
graydon:
|
jonas: we should when it's possible. You forget they have no network or process transparency
|
|
graydon:
|
jonas: or perhaps they are process transparent. You are the one working on them...
|
|
graydon:
|
jonas: them .. it. GWT.
|
|
graydon:
|
Can multiple processes connect to it right now?
|
|
jonas:
|
The way I see it, every system running Berlin should have GGI (and libs) under it, then the Berlin window object uses a gwt window
|
|
jonas:
|
graydon: no, and that's not quite the way I'm imagining it.
|
|
graydon:
|
jonas: agreed. How does gwt work? I haven't seen it since mentalboy was coding it back in feb.
|
|
jonas:
|
Say a client opens a remote window, it should be the responsibility of the remote Berlin Display Server to create a remote Berlin Window Object, which in turn has a "local" GWT window
|
|
anoq:
|
graydon, jonas: are we sure to have GGI + libs in say BeOS, WinNT etc?
|
|
graydon:
|
anoq: that's the GGI's plan
|
|
anoq:
|
graydon: cool...
|
|
jordy:
|
yeah, libggi is getting ported every which way
|
|
jonas:
|
graydon: I've been a little busy with school work, but I have been working on line-clipping, next thing was Cyrus-beck algo, which allows for polygonal regions
|
|
graydon:
|
jonas: ok, cool. Now how does GWT manage those windows internaly? With callbacks to redraw portions, or with backing store?
|
|
jonas:
|
I'm planning on a X like behaviour, backing-store as an attribute of the window and otherwise an exposure event
|
|
graydon:
|
jonas: it's significant because there will be clients who want direct access to their window's buffer.
|
|
graydon:
|
jonas: ok, that's sane.
|
|
jonas:
|
ok, I guess a byte sequence is going to cut it :)
|
|
graydon:
|
jonas: I didn't want expose events, but I'm beginning to see it as an inevitability for all those wusses with < 64 megs on their video cards.
|
| | graydon grins |
|
jordy:
|
64 meg video cards, geez
|
|
jonas:
|
yeah, why can't we all have 256MB ram and UMA Æ=
|
|
anoq:
|
jonas: fine with me :)
|
|
anoq:
|
I mean - I would like if everybody had :)
|
|
jonas:
|
The main point here is that libgwt is used locally on the Display server, which in turn has Window Objects which are connected to local as well as remote clients
|
|
graydon:
|
jonas: ok, I also want you to keep in mind that mmap()ing part of that memory is a possibility to enhance throughput.
|
|
graydon:
|
although duncan has stated (don't know if you caught it) that there's a shared-memory omni-orb transport floating around too. That might do it.
|
|
jordy:
|
yeah, i think he said it was in development
|
|
jonas:
|
nope, it was internal :)
|
|
jordy:
|
yeah, that's what i meant :)
|
|
jordy:
|
in development @ orl :)
|
|
graydon:
|
we can probably count on that helping though.
|
|
graydon:
|
orl seem like a nice bunch of people
|
|
jonas:
|
not sure, how to do the direct buffer access, but I'm sure it will be solved, at least locally, how can we best do it remote?
|
|
graydon:
|
jonas: if VNC is GPL, I say we look over their protocol. I mean, nobody would seriously run quake in a window on a remote machine and expect it to work fast...
|
|
graydon:
|
QuakeGL, that's another issue.
|
|
jordy:
|
of course not
|
|
jordy:
|
well, if we could port Mesa
|
|
graydon:
|
jordy: I hope that will be the case.
|
|
jordy:
|
even then... i mean, you are talking about a ton of calls per second :)
|
|
graydon:
|
it should fit in nicely with GWT
|
|
graydon:
|
well, yeah, but you'd at least have a chance.
|
|
jordy:
|
you might be able to get away with a slower style game, like tetris however :)
|
|
graydon:
|
I suspect there are fewer GL calls than there are putpixels.
|
|
jordy:
|
but for the most part, people will probably running large things
|
|
jordy:
|
like compilers and web browsers
|
|
graydon:
|
Ok, well I'd like jonas to provide a web page to help people track GWT, and also make some source available soon, but other than that does anyone have any problems with his way of doing windows?
|
|
graydon:
|
jonas: at your leisure, those things. Obviously if you're in school you have other constraints.
|
|
jonas:
|
currently http://lin01.vejlehs.dk/~jones/libgwt.html :)
|
|
jordy:
|
sounds fine and dandy to me... :)
|
|
graydon:
|
sound
|
| | graydon has set the topic: "berlin: sound" |
| | graydon has set the topic: berlin: sound |
|
jonas:
|
I have 5 weeks left in school, and next week another GWT developer returns
|
|
jordy:
|
alright, uhm... what about it? :)
|
|
jordy:
|
are we talking network sound?
|
|
graydon:
|
free for all. Any ideas on the table.
|
|
graydon:
|
we haven't discussed it yet and we'll need it eventually
|
|
jordy:
|
well, basic sound events would be nice
|
|
jonas:
|
Hmm, sound registration (in registrar ala windows) and NAS?
|
|
anoq:
|
ALSA = Advanced Linux Sound Architecture - anybody knows it?
|
|
jordy:
|
something like that, linked into our exception handler for errors :)
|
|
graydon:
|
ok. do we want server-side sound objects for buffering?
|
|
jordy:
|
anoq: i heard of it, they want to replace OSS right?
|
|
anoq:
|
jordy: I think I read so - yes..
|
|
jordy:
|
i think network sound is probably unrealistic for the quality audio people use
|
|
anoq:
|
jordy: How about an mpeg3 stream?
|
|
jordy:
|
well
|
|
jordy:
|
mpeg3 could do it
|
|
graydon:
|
also, you can send a sound to a display server once and then re-trigger it.
|
|
anoq:
|
Except that mpeg3 is _very_ slow to compress (I've heard)
|
|
jordy:
|
make mp3 our official sound format and we won't have to worry about that :)
|
|
graydon:
|
or send load a synthesis package and send it instructions
|
|
anoq:
|
graydon: good idea! - Like reusing an image
|
|
jordy:
|
well
|
|
graydon:
|
midi events, etc.
|
|
jordy:
|
mmmm, maybe we need a sound server :)
|
|
graydon:
|
that's how sound cards work nowadays, they store waves on the card and trigger them with certain parameters
|
|
graydon:
|
using a hardware mixer.
|
|
anoq:
|
graydon: yearh... MIDI is good - but slow IRL...
|
|
jordy:
|
mmm
|
|
jordy:
|
well
|
|
graydon:
|
midi tops out at 33kbps on the wire. So it's quite realistic over a modem.
|
|
anoq:
|
At least MIDI is standard...
|
|
jordy:
|
ok, most sound events will just be events... small 1-2 second clips
|
|
jordy:
|
which will play on whatever machine the user is typing on
|
|
graydon:
|
real-audio... mp3 ... midi ...
|
|
jonas:
|
anoq: but more than one MIDI standard!
|
|
anoq:
|
I think MIDI has a max freq.
|
|
graydon:
|
midi is not a sound transfer spec, it's an event triggering spec.
|
|
anoq:
|
jonas: I don't think so - only different speeds
|
|
graydon:
|
although there's a sample-dump extension to it
|
|
graydon:
|
there are differing standards for the "standard" instrumnt map.
|
|
anoq:
|
graydon: I think it has to have a special frequency - at least for synths
|
|
jonas:
|
anoq: Did Roland not make their "own", standard midi, general midi? Maybe I'm just rambling, but I had problems with keyboards
|
|
graydon:
|
anoq: what do you mean by "special frequency"? It's an async digital protocol that tops out around 30kbps
|
|
jordy:
|
i guess there is a good chance that people are going to want network sound... so they can have their mp3 player on the server and hear it on their workstation... are there any network sound protocols out there?
|
|
graydon:
|
jonas: yeah, there's "general midi" and also yamaha's "XS"...
|
|
jordy:
|
i thought midi was dead :)
|
|
anoq:
|
jonas, graydon: Ohhh stop! You are confusing things... General Midi etc. are only standards for where the instruments are placed - it has nothing to do with the MIDI protocol!
|
|
jonas:
|
jordy: NAS - Network Audio System, the only one I've used
|
|
graydon:
|
jordy: It's got some replacement ideas floating around but it's still the standard.
|
|
jordy:
|
yeah, will CORBA stream? :)
|
|
graydon:
|
anoq: I know, but that's important too.
|
|
jonas:
|
anoq: I rest my case, I just know the problem, not really the reason
|
|
graydon:
|
jordy: not inherently. You'd have to write a streaming system on top of it == slow. Might as well just use corba to negotiate the stream in a standard streaming protocol.
|
|
jordy:
|
because if we just made a CORBA interface... we'd have to send bytes
|
|
jordy:
|
cut up the song
|
|
anoq:
|
graydon: If you send a sample of a scream - which instrument it that?
|
|
jordy:
|
send 30 bytes
|
|
smkl:
|
i have heard NAS for linux doesnt work
|
|
graydon:
|
anoq: in midi, you say "note 32, instrument 44, volume..." .. unless you're talking about sample-dump
|
|
anoq:
|
Btw: MIDI is only for triggering sounds... we need something else to send the samples
|
|
jonas:
|
smkl: I wouldn't really call my experience a success but it "kinda" played .wav but that may be better now
|
|
smkl:
|
there is another one in deveplopment, check http://www.netcom.com/~ericmit/EsounD.html
|
|
smkl:
|
that was on the gnome list also
|
|
graydon:
|
Yeah. Gnome has incorporated a thing called "enlightened sound daemon", I think that's what you're talking about. We should look at it.
|
|
graydon:
|
Ok. So no firm ideas on sound.
|
|
graydon:
|
No religious commitments to any way of doing things.
|
|
anoq:
|
graydon: I think MIDI is a good "trigger" :)
|
|
graydon:
|
anoq: I agree. It's nice and standard.
|
|
graydon:
|
You can feed it straight into /dev/sequencer and your sound card (or synth) takes over.
|
|
anoq:
|
graydon: Yup!
|
|
jonas:
|
we have /dev/sequencer, /dev/audio, I want /dev/mp3 :)
|
|
jordy:
|
hahaha
|
|
jordy:
|
/dev/mp3.. full blown mp3 decoder in the kernel
|
| | graydon knows this because last year he wrote a linux sequencer ;) |
|
graydon:
|
/dev/mp3 isn't too implausible. I bet people sell the chips..
|
|
jordy:
|
i've heard some MPEG decoders can handle MP3...
|
|
jonas:
|
yup, but I'd rather have hardware encoding, decoding is something like 0.9 cpu
|
|
graydon:
|
jordy: didn't even know they used the same technology. mpeg is just the name of the standards group, no?
|
|
jordy:
|
gray: MP3 == MPEG1 layer 3
|
|
jordy:
|
it's part of MPEG 1 "standard"
|
|
graydon:
|
Oh, ok.
|
|
jordy:
|
what i meant to say is that I've heard of some DVD hardware mpeg decoders which can decode MPEG1.3 quite well...
|
|
anoq:
|
jordy: isn't mpg3 also MPEG2 layer 3?
|
|
jordy:
|
anoq: that i wouldn't know :)
|
|
jordy:
|
i do know it's 1.3 tho :)
|
|
jonas:
|
anoq: not in the usual sense,
|
|
anoq:
|
hmmm
|
|
graydon:
|
bah. ok. next topic...
|
|
jonas:
|
ok
|
|
jordy:
|
yeah, whats next
|
| | graydon has set the topic: "berlin: security" |
| | graydon has set the topic: berlin: security |
|
graydon:
|
security
|
|
jordy:
|
ooo, my favorite topic
|
|
graydon:
|
grrrr
|
|
anoq:
|
bring in the cops!
|
| | graydon winces when he considers security systems |
|
jordy:
|
yeah, declare berlin a soverign nation... any security breakin attempts against it will be considered an act of war
|
| | jordy grins |
|
graydon:
|
I've put the document describing how corba thinks security should be done in the /doc/corba-docs directory
|
|
jonas:
|
Anyone know what COSS has to say about this?
|
|
graydon:
|
It's huge and extremely complex
|
|
graydon:
|
10 times the size of any other chapter
|
|
graydon:
|
They just settled on a standard in corba 2.2
|
|
jordy:
|
yeah, well... i've heard NT is going w/ Kerberos for security auth
|
|
graydon:
|
NT uses a kinda hacked up form of kerberos, yeah.
|
|
anoq:
|
Kerberos? Enlighten me....
|
|
jonas:
|
jordy: Is kerberos exportable to outside us?
|
|
graydon:
|
Kerberos is a very powerful security system developed at MIT
|
|
graydon:
|
It's somewhat complex though
|
|
graydon:
|
I've administered it and it's quite paranoid. Doesn't deal well with systems whose clocks are a few minutes out of sync, etc.
|
|
jordy:
|
jonas: should be... otherwise ms is gonna have a hard time selling NT5 :)
|
|
graydon:
|
I'd like to have that level of security possible, but I don't want to force it. It'll confuse too many people.
|
|
jordy:
|
well
|
|
graydon:
|
I mean, kerb is just too much for a home user.
|
|
jordy:
|
we could always go the SSL route
|
|
jordy:
|
very simple authentication using certs
|
|
anoq:
|
graydon: agree
|
|
graydon:
|
I'll be honest and say I haven't even *read* the COSS document yet.
|
|
jordy:
|
i have to boot into windows to read pdf's :)
|
|
graydon:
|
There's many levels to security
|
|
graydon:
|
jordy: get acroread
|
|
jordy:
|
you kidding? fonts under X looks choppy, hurt my eyes to read :)
|
|
anoq:
|
jordy: get xpdf from debian.org - it's faster than acrobat reader!
|
|
graydon:
|
there's "you can't read this", there's "I know who you are", there's "I can prove you did this"... etc.
|
|
graydon:
|
jordy: turn on anti-aliasing. It's fine.
|
|
jordy:
|
mmm
|
|
graydon:
|
jordy: well, for some suitably lax definition of the word "fine"
|
|
jordy:
|
audit trails and authentication
|
|
jordy:
|
audit trails are a bit mmm
|
|
jonas:
|
acroread is very nice, just need 125-150%
|
|
jordy:
|
moer complex than home users care about :)
|
|
jordy:
|
more rather
|
|
graydon:
|
jordy: agreed, and COSS is very concerned about corporate things (they like the word "enterprise")
|
|
anoq:
|
xpdf has ugly fonts too...
|
|
jordy:
|
authentication again can be done one of 800 ways
|
|
jordy:
|
what exactly are we trying to secure against however?
|
|
graydon:
|
Yeah, now what COSS did is break up "compliance" in to multiple levels. Like, if you're a wuss you can just implement "level 1" securty. I don't know what that means but it's promising. I'd like to interoperate if possible.
|
|
jonas:
|
"illegal" object access I guess, What if someone gets a IOR to one of your objects....
|
|
graydon:
|
jordy: people attacking your machine, deleting your files, pretending they're you, reading your mail, intercepting your widgets, you name it.
|
|
jordy:
|
mmmm
|
|
anoq:
|
graydon: intercepting widgets? Sounds fun :)
|
|
jordy:
|
ok, that might be bad :)
|
|
jonas:
|
Changing the NameService!
|
|
anoq:
|
Good way of getting some more widgets on the system :)
|
|
jordy:
|
so we need basic authentication... ip based is out
|
|
graydon:
|
anoq: well, if I intercept your text widget and send every event you type to myself as well as the app, you'll be none too pleased.
|
|
anoq:
|
graydon: I guess not...
|
|
jordy:
|
i'll have to read COSS
|
|
jordy:
|
to see how they implement basic security
|
|
graydon:
|
so I guess I'm recommending that we all get a beer and sit down to read COSS
|
|
graydon:
|
sometime when we don't mind blowing 10 hours reading legalese
|
|
jordy:
|
yeah, it'll take a few hours
|
|
jordy:
|
6 pack
|
|
jordy:
|
:)
|
| | graydon grins |
|
graydon:
|
ok. we'll talk more after having read it.
|
|
jordy:
|
alrighty, what's next
|
| | graydon has set the topic: "berlin: sessions / contracts / pinging" |
| | graydon has set the topic: berlin: sessions / contracts / pinging |
|
jonas:
|
heh, happyli in Denmark we have 12-packs!
|
|
graydon:
|
Again, this might be the sort of thing COSS has something to say about
|
|
jordy:
|
why do we need to ping anything, doesn't the OS take care of socket destruction?
|
|
graydon:
|
but we need a way of knowing when a remote app dies
|
|
graydon:
|
jordy: omni dynamically allocates sockets.
|
|
jordy:
|
it dies when the remote computer tells us that the socket is dead, i'm sure corba must sense that
|
|
graydon:
|
jordy: after 30 seconds idle sockets close.
|
|
jordy:
|
really?
|
|
graydon:
|
yep
|
|
jordy:
|
oh geez
|
|
jordy:
|
well, we need a little echo then :)
|
|
graydon:
|
yeah. I was thinking the app could keep a single object for it's session, to avoid pinging all its widgets.
|
|
jonas:
|
sounds good, I know a DCOM / CORBA comp. that bashed DCOM for pinging, so there must be a CORBA alternative!?
|
|
jordy:
|
gray: right, just a little areYouAlive() method
|
|
graydon:
|
jonas: well, the trick is anything other than a ping assumes the client has a feasable way of telling you it's finished. What if someone just drops a bomb on the client and they are gone from earth?
|
|
jordy:
|
a bomb, geez... how about something a bit more feasible, someone hits the power by accident :)
|
|
graydon:
|
jonas: it's either the client pings the server to update a watchdog timer, or the server pings the client every time it gets curious.
|
|
jordy:
|
we should ask duncan about that
|
|
graydon:
|
jordy: what if the meteor from deep impact lands *RIGHT ON THE CLIENT*?
|
|
jordy:
|
hahaha
|
|
anoq:
|
graydon: amusing :)
|
|
jonas:
|
I guess no insurance will cover it :)
|
|
anoq:
|
Heh - no ;)
|
|
jordy:
|
i think for right now... an areYouThere() method would be the easiest...
|
|
graydon:
|
yeah, ok, so we'll see what duncan has to say about it, and unless he (or COSS) has any better idea we'll make a little session management interface.
|
|
jonas:
|
ok
|
|
jordy:
|
something like that
|
|
jordy:
|
what's next
|
| | graydon has set the topic: "berlin: metrics, paths and geometry abstractions" |
| | graydon has set the topic: berlin: metrics, paths and geometry abstractions |
|
graydon:
|
Any postscript hackers around here?
|
|
jonas:
|
speaking of what about printing
|
|
jordy:
|
see, i don't like postscript because every implementation of it (with the exception of openstep)... looks like shit :)
|
|
jordy:
|
i know it's WYSIWYG
|
|
jonas:
|
jordy: ?? LaserJet 4M handles it just fine :)
|
|
jordy:
|
jonas: haha
|
|
graydon:
|
Metrics have to be available to the client app. Period. The client might be a DTP program which is doing some fierce logic about layout.
|
|
graydon:
|
jordy: on the display, yeah. But the imaging model is pretty good.
|
|
jordy:
|
well i display more things than i print :)
|
|
jonas:
|
we could look at ghostview, nobody is planning on reading anything, right?
|
|
graydon:
|
jordy: me too, but we can't write off printing ;)
|
|
jordy:
|
how does the Mac do it?
|
|
jordy:
|
they supposedly have awesome printing abilities
|
|
jordy:
|
actually, come to think of it
|
|
jordy:
|
how many printers have postscript anyway?
|
|
graydon:
|
jordy: many mac apps take the logic inside themselves. But they do (I think) make metrics available to clients.
|
|
jordy:
|
i know the two i have here don't
|
|
graydon:
|
jordy: fewer and fewer. I don't mean to say we *must* use the postscript imaging model. But we need a few things afaik
|
|
graydon:
|
we need transformation matricies
|
|
graydon:
|
subpixel positioning
|
|
graydon:
|
paths
|
|
graydon:
|
and metrics
|
|
anoq:
|
I don't like using postscript for display - only for printing...
|
|
jonas:
|
pdf printers - yum, cat coss.pdf > /dev/printer :)
|
|
graydon:
|
this sort of thing has to be in our imaging model if we're going to work in print at all, as well as if we want to work with new display technologies.
|
|
jordy:
|
i don't like postscript period.... we will just have to have printer drivers... print everything as graphics save us some time :)
|
|
graydon:
|
The question is does anyone here know a damn thing about these?
|
|
anoq:
|
jordy: agree
|
|
graydon:
|
jordy: not an option
|
|
jordy:
|
not me, i print about two things a month.... i've never been interested in that sort of thing
|
|
graydon:
|
jordy: me neither. My printer is currently in on a bookshelf collecting dust.
|
|
jordy:
|
we are just looking for some way to get our onscreen representation to match our printed version right?
|
|
anoq:
|
my Star LC20 printer needs ink!
|
|
graydon:
|
jordy: not just that. If I take something on the screen and stretch it, it has to do something intelligible other than get big and chunky.
|
|
jonas:
|
no matter where _our_ printers are, printing is one of the most important features we _must_ provide, and do it _much_ better than X
|
| | yusef (yusef@199.1.27.58) has joined channel #berlin |
|
anoq:
|
graydon: scalable fonts? true type etc..
|
|
jordy:
|
well... it's something that none of us have any experience in unfortunatly
|
|
yusef:
|
hello
|
|
graydon:
|
scalable fonts still need transformation matrix support to be able to express stretching, rotating, etc. I just want there to be interfaces to represent this sort of stuff.
|
|
anoq:
|
a bitmap image will always get jagged
|
|
graydon:
|
anoq: but a path won't.
|
|
jordy:
|
graydon: we will probably just need to leave it open for now
|
|
graydon:
|
jordy: Ok, then I'm going to pick up a book on postscript & typography and learn.
|
|
anoq:
|
transformation matrixes etc sounds OK - but bypass 'em for display
|
|
jonas:
|
graydon: that's the spirit!
|
|
graydon:
|
anoq: no, the whole point of using a structured drawing editor is that it's shapes not pixels.
|
|
graydon:
|
anyway it's ok, we'll return to the issue once we've learned about it.
|
|
jordy:
|
shouldn't be too hard to implement in the future
|
|
anoq:
|
graydon: I know - a scalable coord-sys then?
|
|
graydon:
|
yeah.
|
|
graydon:
|
scalable, rotatable, deformable -- i.e. transformation matricies.
|
|
anoq:
|
graydon: ok ok ok
|
| | graydon grins |
| | jordy scratches his head |
| | graydon has set the topic: "berlin: deploying "developer" services" |
| | graydon has set the topic: berlin: deploying "developer" services |
|
jordy:
|
like MSDN sorta stuff? :)
|
|
graydon:
|
like a mailing list for CVS commits
|
|
jordy:
|
ahhh
|
|
jordy:
|
we do need a bugs@berlin-consortium.org
|
|
jordy:
|
not sure if that was ever put in :)
|
|
graydon:
|
like debs / rpms of the most recent working things needed to work on the project
|
|
graydon:
|
also GNATS
|
|
jordy:
|
yeah... mmmm
|
|
jonas:
|
A cvs "announce" with a list of changed files and comments is _very_ usefull!
|
|
jordy:
|
that's easy enough....
|
|
graydon:
|
Yeah. You can sort it in your email, and then read over what's been changing.
|
|
jordy:
|
i still have my cvs log thing
|
|
graydon:
|
do you know how to implement that?
|
|
jordy:
|
one sec
|
|
jordy:
|
i'll show you format
|
|
jordy:
|
ergh
|
|
jordy:
|
pulling down logs
|
|
graydon:
|
ok, does anyone know how to make debs or rpms?
|
|
jordy:
|
Sun May 17 06:43:57 1998 graydon
|
|
jordy:
|
* Berlin/src/berlin/cos/Makefile: tweak
|
|
jordy:
|
* Berlin/src/berlin/cos/InterfaceRepo.idl:
|
|
jordy:
|
the basis of corba introspection, as far as I can tell.
|
|
jordy:
|
only problem is it says @jolt :)
|
|
jordy:
|
which is my box :)
|
|
graydon:
|
what's jolt?
|
|
graydon:
|
aah
|
|
jordy:
|
oh, and it gets a little off on formatting
|
|
jordy:
|
like:
|
|
graydon:
|
well whatever. That looks like a good script. Where does it run?
|
|
jordy:
|
* Berlin/src/berlin/messages/subjectChangedMessage.idl,
|
|
jordy:
|
Berlin/src/berlin/messages/redrawMessage.idl,
|
|
jordy:
|
Berlin/src/berlin/messages/keyEvent.idl:
|
|
jordy:
|
Include problems (stubs dirs never made it into tree)
|
|
jordy:
|
graydon: it's rcs2log... i can give you the params
|
|
jordy:
|
it comes with cvs dist
|
|
jordy:
|
it formats 'cvs log'
|
|
graydon:
|
cool. how do we make it hapen automatically?
|
|
jordy:
|
rcs2log -i 4 -l 76 -r -d \>"last week" Berlin | sed -e "s/.cvs.berlin.//g"
|
|
jordy:
|
well, someone could crontab it and just pipe it to sendmail
|
|
graydon:
|
I'll ask the debian cvs maintainer to do so.
|
| | Signoff: yusef (Leaving) |
|
jonas:
|
I'm pretty sure the system we used, send the mail along with a cvs commit, and only those changes were mentioned, should I ask the maintainer?
|
|
graydon:
|
jonas: that's how the one I have at work happens.. I should really ask the CVS guy there.
|
|
jordy:
|
mmm
|
|
graydon:
|
Of course, you got *lots* of mail.
|
|
graydon:
|
one per day might be nicer. Say, only if something changed.
|
|
graydon:
|
ok, well no obvious solutions there. I'll talk to the cvs maintainer for debian. shall we move to the final topic?
|
|
jordy:
|
yeah, that rcs2log command would be once a week
|
|
jordy:
|
yeah, go ahead
|
| | graydon has set the topic: "berlin: new COSS stuff" |
| | graydon has set the topic: berlin: new COSS stuff |
|
graydon:
|
COSS specifies mechanisms for creating, deleting, relating, embedding, copying, moving, etc. compound objects.
|
|
graydon:
|
I've extracted the IDL and put it in the /src/berlin/cos directory.
|
|
anoq:
|
graydon: That can replace cloneable then?
|
|
graydon:
|
I've also implmented a not-yet-debugged GenericFactory along the lines of the demand loader we were considering
|
|
graydon:
|
anoq: yes, lifeCycleObject will replace cloneable.
|
|
anoq:
|
graydon: does it have autorelease too?
|
|
graydon:
|
anoq: not afaik. It has a destroy method.
|
|
graydon:
|
or maybe a "remove" method. Can't recall the name.
|
|
anoq:
|
we should have autorelease I think
|
|
anoq:
|
DOOH! No - it's a network... :(
|
|
anoq:
|
It won't work right
|
|
graydon:
|
you do have to tell an object when you're done with it, and there's some stickyness having to do with multiple people having references to the object we still need to work out.
|
|
jordy:
|
hmmm
|
|
graydon:
|
Not sure. The specs are all in the corba-docs directory. It's verbose.
|
|
anoq:
|
yearh - like how do we return an object from a method without keeping a ref-count on it, and without having to rely on somebody else to free it?
|
|
graydon:
|
Well, it's basically as complex as you have in C++, having to destroy things yourself, only you can't use variable scope to help you.
|
|
anoq:
|
this sucks...
|
|
|